《大规模分布式存储系统》第7章 分布式数据库【7.1】

javazx

第7章　分布式数据库
) e% O# G: c$ s3 `关系数据库理论汇集了计算机科学家几十年的智慧，Oracle、Microsoft SQL
- H; t) P" H7 ^7 sServer、MySQL等关系数据库系统广泛应用在各行各业中。可以说，没有关系数据
库，就没有今天的IT或者互联网行业。然而，关系数据库设计之初并没有预见到IT行
; h. F! z! g3 H( r业发展如此之快，总是假设系统运行在单机这一封闭系统上。
有很多思路可以实现关系数据库的可扩展性。例如，在应用层划分数据，将不
- G4 |, x) K( t8 G1 o同的数据分片划分到不同的关系数据库上，如MySQL Sharding；或者在关系数据库内
1 T* l3 X* Q8 T  Q* u8 c, E2 O7 r! U0 [部支持数据自动分片，如Microsoft SQL Azure；或者干脆从存储引擎开始重写一个全
新的分布式数据库，如Google Spanner以及Alibaba OceanBase。
本章首先介绍数据库中间层架构，接着介绍Microsoft SQL Azure，最后介绍
Google Spanner。
, c  h: i+ w) T$ h0 C$ O' v3 o7.1　数据库中间层
, k) a, s! v8 ~/ \2 ]为了扩展关系数据库，最简单也是最为常见的做法就是应用层按照规则将数据
拆分为多个分片，分布到多个数据库节点，并引入一个中间层来对应用屏蔽后端的
数据库拆分细节。
7.1.1　架构
( z. h1 k' C% O/ r6 F以MySQL Sharding架构为例，分为几个部分：中间层dbproxy集群、数据库组、
$ c; T3 L1 c$ m  w, H# b元数据服务器、常驻进程，如图7-1所示。
图　7-1　数据库中间层架构
; [6 a8 o2 }  p$ f9 h6 h（1）MySQL客户端库
应用程序通过MySQL原生的客户端与系统交互，支持JDBC，原有的单机访问数
据库程序可以无缝迁移。
（2）中间层dbproxy
7 I& _1 _9 U9 l! V, E9 H/ |& h/ v中间层解析客户端SQL请求并转发到后端的数据库。具体来讲，它解析MySQL
协议，执行SQL路由，SQL过滤，读写分离，结果归并，排序以及分组，等等。中间
层由多个无状态的dbproxy进程组成，不存在单点的情况。另外，可以在客户端与中
间层之间引入LVS（Linux Virtual Server）对客户端请求进行负载均衡。需要注意的
. f8 o5 ~; l& i- H2 Y! {是，引入LVS后，客户端请求需要额外增加一层通信开销，因此，常见的做法是直接
在客户端配置中间层服务器列表，由客户端处理请求负载均衡以及中间层服务器故
8 B$ q; i7 G2 x& n6 K4 x障等情况。
（3）数据库组dbgroup
每个dbgroup由N台数据库机器组成，其中一台为主机（Master），另外N-1台为
/ r2 b/ B( S! s7 I/ b3 D备机（Slave）。主机负责所有的写事务及强一致读事务，并将操作以binlog的形式复
制到备机，备机可以支持有一定延迟的读事务。
. ~1 P& C" h8 _) x+ r（4）元数据服务器
元数据服务器主要负责维护dbgroup拆分规则并用于dbgroup选主。dbproxy通过元
; N# @# j: C' p2 L5 w2 m数据服务器获取拆分规则从而确定SQL语句的执行计划。另外，如果dbgroup的主机
0 d# c& a% P7 Y, U( `* y5 z9 h出现故障，需要通过元数据服务器选主。元数据服务器本身也需要多个副本实现
HA，一种常见的方式是采用Zookeeper实现。
（5）常驻进程agents
: Z+ {. v: p' ?( Q6 @部署在每台数据库服务器上的常驻进程，用于实现监控，单点切换，安装，卸
1 x/ a) L; Z) I载程序等。dbgroup中的数据库需要进行主备切换，软件升级等，这些控制逻辑需要
与数据库读写事务处理逻辑隔离开来。
. o+ V" p6 V- `7 ~9 Y/ b假设数据库按照用户哈希分区，同一个用户的数据分布在一个数据库组上。如
果SQL请求只涉及同一个用户（这对于大多数应用都是成立的），那么，中间层将请
' O7 [( v* e$ S8 u1 }求转发给相应的数据库组，等待返回结果并将结果返回给客户端；如果SQL请求涉及
3 r7 p4 S& K, ~" E& I/ X. \多个用户，那么中间层需要转发给多个数据库组，等待返回结果并将结果执行合
并、分组、排序等操作后返回客户端。由于中间层的协议与MySQL兼容，客户端完
- _4 R  o, V5 T  s0 `& e/ F0 H全感受不到与访问单台MySQL机器之间的差别。
; s* d6 }; S% S8 c* c+ o8 W; ^7.1.2　扩容
/ T0 R; s- B6 Z5 M* jMySQL Sharding集群一般按照用户id进行哈希分区，这里面存在两个问题：
7 o! J9 E4 f' N: @8 n! H/ o& w" y1）集群的容量不够怎么办？
2）单个用户的数据量太大怎么办？
对于第1个问题，MySQL Sharding集群往往会采用双倍扩容的方案，即从2台服务
& o) [! H* J1 P* @器扩到4台，接着再扩到8台……，依次类推。
假设原来有2个dbgroup，第一个dbgroup的主机为A0，备机为A1，第二个dbgroup
3 G5 J5 A6 W. B) {; D6 H& Q' H# w2 ?的主机为B0，备机为B1。按照用户id哈希取模，结果为奇数的用户分布在第一个
5 I% c' k- y4 Z- ]5 P& E* rdbgroup，结果为偶数的用户分布在第二个dbgroup。常见的一种扩容方式如下：
1）等待A0和B0的数据同步到其备服务器，即A1和B1。
+ h  e1 B8 E* c" `# @) F2）停止写服务，等待主备完全同步后解除A0与A1、B0与B1之间的主备关系。
9 j  E/ \9 a6 e0 H* J3）修改中间层的映射规则，将哈希值模4等于1的用户数据映射到A1，哈希值模
  y3 s! y3 v( n& E5 F$ j4等于3的用户数据映射到B1。
4）开启写服务，用户id哈希值模4等于0、1、2、3的数据将分别写入到A0、
A1、B0、B1。这就相当于有一半的数据分别从A0、B0迁移到A1、B1。
5）分别给A0、A1、B0、B1增加一台备机。
! N7 ^4 u! I$ o7 A! Q7 f最终，集群由2个dbgroup变为4个dbgroup。可以看到，扩容过程需要停一小会儿
服务，另外，扩容进行过程中如果再次发生服务器故障，将使扩容变得非常复杂，
很难做到完全自动化。
7 ^' X- {8 F% A3 Y2 y对于第2个问题，可以在应用层定期统计大用户，并且将这些用户的数据按照数
据量拆分到多个dbgroup。当然，定期维护这些信息对应用层是一个很大的代价。
7.1.3　讨论
7 c3 {1 d4 `& e+ L引入数据库中间层将后端分库分表对应用透明化在大型互联网公司内部很常
3 u# T8 s+ l' B/ U见。这种做法实现简单，对应用友好，但也面临一些问题：
$ v4 E. l7 P; T( Z' c, K- b●数据库复制：MySQL主备之间只支持异步复制，而且主库压力较大时可能产生
很大的延迟，因此，主备切换可能会丢失最后一部分更新事务，这时往往需要人工
$ [  J% \3 s& E0 ~/ B) z% N/ L介入。
; P$ S% F2 O* L. `# W! s8 n3 I( \  N●扩容问题：如果系统压力过大需要增加新的机器，这个过程涉及数据重新划
' U6 ~( Y' G& s) s) I# {分，整个过程比较复杂，且容易出错。
●动态数据迁移问题：如果某个数据库组压力过大，需要将其中部分数据迁移出
去，迁移过程需要总控节点整体协调，以及数据库节点的配合。这个过程很难做到
0 T2 M/ p8 i2 Y" W: Y: g自动化。
% j0 {) _3 H) x% T, u3 w2 ]
/ k7 M# j6 d. Y9 c" {
, u1 P; B" N+ x$ d