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

javazx

7.2　Microsoft SQL Azure
Microsoft SQL Azure是微软的云关系型数据库，后端存储又称为云SQL
- ?# v, w% |/ @- m# z1 jServer（Cloud SQL Server）。它构建在SQL Server之上，通过分布式技术提升传统关
* ~; t- B* r0 G' p系型数据库的可扩展性和容错能力。
7.2.1　数据模型
' q1 C% ?; x1 ?' _# C+ e$ U1.逻辑模型
( V8 Q% ^) ]0 t- k) f/ N云SQL Server将数据划分为多个分区，通过限制事务只能在一个分区执行来规避
+ _$ O7 V4 F! J  k" l# D分布式事务。另外，它通过主备复制（Primary-Copy）协议将数据复制到多个副本，
保证高可用性。
4 K; C. L6 o- X$ I+ Y% z5 W8 P2 I5 e云SQL Server中一个逻辑数据库称为一个表格组（table group），它既可以是有
主键的，也可以是无主键的，本节只讨论有主键的表格组。如果一个表格组是有主
3 F& t2 g/ q5 k" C7 P: R键的，要求表格组中所有的表格都有一个相同的列，称为划分主键（partitioning
key）。图中的表格组包含两个表格，顾客表（Customers）和订单表（Orders），划
- M" d9 C$ V7 L" s8 C4 ~5 [, g0 X分主键为顾客ID（Customers表中的Id列）。如图7-2所示。
: i6 ]) {! l1 ]0 J# l9 U' v' l# q图　7-2　云SQL Server数据模型
) P+ o1 i  c8 a' X. F划分主键不需要是表格组中每个表格的唯一主键。图7-2中，顾客ID是顾客表的
唯一主键，但不是订单表的唯一主键。同样，划分主键也不需要是每个表格的聚集
8 w$ T( }8 ]6 Z4 |7 K7 ~索引，订单表的聚集索引为组合主键＜顾客ID，订单ID＞（＜Id,Oid＞）。
0 I9 n& N! k# `- @% W7 q表格组中所有划分主键相同的行集合称为行组（row group）。顾客表的第一行
以及订单表的前两行的划分主键均为34，构成一个行组。云SQL Server只支持同一个
& ^$ l% _" q' W( Q行组内的事务，这就意味着，同一个行组的数据逻辑上会分布到一台服务器。
如果表格组是有主键的，云SQL Server支持自动地水平拆分表格组并分散到整个
集群。同一个行组总是被一台物理的SQL Server服务，从而避免了分布式事务。这样
3 {+ H* r  L2 A4 }7 }$ b! K( J- t" D的好处是避免了分布式事务的两个问题：阻塞及性能，当然，也限制了用户的使用
$ U  o0 O  ^, a4 ~6 S模式。
只读事务可以跨多个行组，但事务隔离级别最多支持读取已提交（read-
9 }" [; s/ `1 e! @% W; G% B. Dcommitted）。
2.物理模型
4 F" u7 }) J1 M! _; k在物理层面，每个有主键的表格组根据划分主键列有序地分成多个数据分区
5 d( q! F- i- u# ?% x- G  ~) z（partition）。这些分区之间互相不重叠，并且覆盖了所有的划分主键值。这就确保
了每个行组属于一个唯一的分区。
( p) u$ @7 c1 e+ C# w: V  L8 o9 `分区是云SQL Server复制、迁移、负载均衡的基本单位。每个分区包含多个副本
' a: ^3 ~  z) H0 ]+ a2 n: x. l9 l（默认为3），每个副本存储在一台物理的SQL Server上。由于每个行组属于一个分
1 ]: w* y3 K1 U8 g- E: c区，这也就意味着每个行组的数据量不能超过分区允许的最大值，也就是单台SQL
# B7 i; \9 q# |) _4 L' H3 nServer的容量上限。
# W, q+ A% N0 N% m7 n# I6 s3 G一般来说，同一个交换机或者同一个机架的机器同时出现故障的概率较大，因
而它们属于同一个故障域（failure domain）。云SQL Server保证每个分区的多个副本
分布到不同的故障域。每个分区有一个副本为主副本（Primary），其他副本为备副
' ^- P. D: h. ?+ P本（Secondary）。主副本处理所有的查询，更新事务并以操作日志的形式将事务同
1 Z* E. r$ }: H5 U步到备副本，备副本接收主副本发送的事务日志并应用到本地数据库。目前，备副
本不支持读操作，当然，这是很容易实现的，只是可能读取到过期的数据。
3 l& N& ]% v) K9 h+ N如图7-3所示，有四个逻辑分区PA、PB、PC、PD，每个分区有一个主副本和两
* @( V0 t& l9 X! ]' k个备副本。例如，PA有一个主副本PA P 以及两个备副本PA S1 和PA S2 。每台物理SQL
& ~7 m& A1 j. ?6 s7 jServer数据库混合存放了主副本和备副本。如果某台机器发生故障，它上面的分区能
够很快分散到其他活着的机器上。
图　7-3　云SQL Server物理模型
3 \) h/ L4 l0 x分区划分是动态的，如果某个分区超过了允许的最大分区大小或者负载太高，
这个分区将分裂为两个分区。假设分区A的主副本在机器X，它的备副本在机器Y和
Z。如果分区A分裂为A1和A2，每个副本都需要相应地分裂为两段。为了更好地进行
负载均衡，每个副本分裂前后的角色可能不尽相同。例如，A1的主副本仍然在机器
  T" n( W1 a, PX，备副本在机器Y和机器Z；而A2的主副本可能在机器Y，备副本在机器X和机器
+ O" r) l! g6 R0 F- U/ vZ。
: y! A  V  X: b" L( |$ b7 A: n8 y7.2.2　架构
云SQL Server分为四个主要部分：SQL Server实例、全局分区管理、协议网关、
3 L2 o0 x6 G* W5 Z# w" \分布式基础部件，如图7-4所示。
图　7-4　云SQL Server的分层架构
下面分别介绍这几个部分：
$ \" s' j" N) J, Z2 ~/ J●每个SQL Server实例是一个运行着SQL Server的物理进程。每个物理数据库包
" v. ^& `4 C0 H  e含多个子数据库，它们之间互相隔离。子数据库是一个分区，包含用户的数据以及
schema信息。
●全局分区管理器（Global Partition Mana- ger）维护分区映射表信息，包括每个
" Z) D; M: _9 B分区的主键范围，每个副本所在的服务器，以及每个副本的状态，包括副本当前是
1 q7 w& ?- e( K* D$ m" p主还是备，前一次是主还是备，正在变成主，正在被拷贝或者正在被追赶。当服务
/ y0 @6 G' e) d器发生故障时，分布式基础部件检测并确保服务器故障后通知全局分区管理器。全
局分区管理器接着执行重新配置操作。另外，全局分区管理器监控集群中的SQL
9 M/ A+ v- q8 @- M. HServer工作机，执行负载均衡，副本拷贝等管理操作。
, |% A3 |' f2 g" E●协议网关（Protocol Gateway）负责将用户的数据库连接请求转发到相应的主分
区上。协议网关通过全局分区管理器获取分区所在的SQL Server实例，后续的读写事
% b7 g9 e2 \8 T务操作都在网关与SQL Server实例之间进行。
●分布式基础部件（Distributed Fabric）用于维护机器上下线状态，检测服务器
! b' Q) p1 d3 n2 t6 U7 S故障并为集群中的各种角色执行选举主节点操作。它在每台服务器上都运行了一个
5 N" H% W+ I% }2 L守护进程。
7.2.3　复制与一致性
$ R: N9 _2 u+ R/ f; G4 y云SQL Server采用"Quorum Commit"的复制协议，用户数据存储三个副本，至少
# [* o& b3 I5 s写成功两个副本才可以返回客户端成功。如图7-5所示，事务T的主副本分区生成操
作日志并发送到备副本。如果事务T回滚，主副本会发送一个ABORT消息给备副
8 r: @. ]' w+ j% J4 ]9 \  U7 V- z本，备副本将删除接收到的T事务包含的修改操作。如果事务T提交，主副本会发送
8 R3 N4 q( A0 E$ I; UCOMMIT消息给备副本，并带上事务提交顺序号（Commit Sequence Number,CSN），
& f3 E; C  o9 V" a4 W- A; e每个备副本会把事务T的修改操作应用到本地数据库并发送ACK消息回复主副本。如
' @; M& X; ?/ D" z: h! `' S- P* H& V( Y果主副本接收到一半以上的成功ACK（包含主副本自身），它将在本地提交事务并
2 k# q7 {! [) F, [成功返回客户端。
% o' t& p  H5 o: ]图　7-5　云SQL Server主备同步
7 f+ B8 `) {9 Q8 u% l. Z某些备副本可能出现故障，恢复后将往主副本发送本地已经提交的最后一个事
" y% Z- p5 d; a8 G. I: r务的提交顺序号。如果两者相差不多，主副本将直接发送操作日志给备副本；如果
两者相差太多，主副本将首先把数据库快照传给备副本，再把快照点之后的操作日
志传给备副本。
主副本与备副本之间传送逻辑操作日志，而不是对磁盘物理页的redo＆undo日
: z+ I: g( F. y- F3 e. E! p! |' |% i志。数据库索引及schema相关操作（如创建，删除表格）也通过操作日志发送。实
践过程中发现了一些硬件问题，比如某些网卡会表现出错误的行为，因此对主备之
间的所有消息都会做校验（checksum）。同样，某些磁盘会出现“位翻转”错误，因
$ Z9 v5 m# L# w此，对写入到磁盘的数据也做校验。
7.2.4　容错
9 t% s* d( \) d& m0 u  x: g% _如果数据节点发生了故障，需要启动宕机恢复过程。每个SQL Server实例最多服
务650个逻辑分区，这些分区可能是主副本，也可能是备副本。全局分区管理器统一
; ^5 Q9 j+ X7 c5 ?* Q" m& P调度，每次选择一个分区执行重新配置（Reconfiguration）。如果出现故障的分区是
备副本，全局分区管理器首先选择一台负载较轻的服务器，接着从相应的主副本分
9 t" E' d9 k* D9 Z# G区拷贝数据来增加副本；如果出现故障的分区是主副本，首先需要从其他副本中选
择一个最新的备副本作为新的主副本，接着选择一台负载较轻的机器增加备副本。
由于云SQL Server采用"Quorum Commit"复制协议，如果每个分区有三个副本，至少
保证两个副本写入成功，主副本出现故障后选择最新的备副本可以保证不丢数据。
全局分区管理器控制重新配置任务的优先级，否则，用户的服务会受到影响。
比如某个数据分片的主副本出现故障，需要尽快从其他副本中选择备副本切换为主
副本；某个数据分片只有一个副本，需要优先复制。另外，某些服务器可能下线很
短一段时间后重新上线，为了避免过多无用的数据拷贝，这里还需要配置一些策
1 t& `3 w+ U$ _% M% A* R! ?略：比如只有两个副本的状态持续较长一段时间（SQL Azure默认配置为两小时）才
开始复制第三个副本。
全局分区管理器也采用"Quorum Commit"实现高可用性。它包含七个副本，同一
. h) @5 F( u, H4 c5 K时刻只有一个副本为主，分区相关的元数据操作至少需要在四个副本上成功。如果
$ T2 _, n/ q9 i. q8 }全局分区管理器主副本出现故障，分布式基础部件将负责从其他副本中选择一个最
0 d( t3 i/ P! P4 `4 T" S( ]" h) e新的副本作为新的主副本。
5 R( z0 B( ^) j$ O4 O* q7.2.5　负载均衡
" I# u$ k  k, k7 K负载均衡相关的操作包含三种：副本迁移以及主备副本切换。新的服务器节点
5 p. P4 A0 j! b" h加入时，系统内的分区会逐步地迁移到新节点，这里需要注意的是，为了避免过多
的分区同时迁入新节点，全局分区管理器需要控制迁移的频率，否则系统整体性能
可能会下降。另外，如果主副本所在服务器负载过高，可以选择负载较低的备副本
替换为主副本提供读写服务。这个过程称为主备副本切换，不涉及数据拷贝。
' n0 L/ w4 P/ ^( R1 a6 r7 q$ Q影响服务器节点负载的因素包括：读写次数，磁盘/内存/CPU/IO使用量等。全局
8 I7 L5 M* Y' \$ p分区管理器会根据这些因素计算每个分区及每个SQL Server实例的负载。
& y' [3 D/ C9 u9 P( |/ I' w/ Q7.2.6　多租户
7 o! x# }3 |! s( V, k云存储系统中多个用户的操作相互干扰，因此需要限制每个SQL Azure逻辑实例
, p4 b3 ]. ~6 b: U) G0 \* q* D  F9 A使用的系统资源：
1）操作系统资源限制，比如CPU、内存、写入速度，等等。如果超过限制，将
1 z* f- \# u: [/ O0 c' F* w4 V在10秒内拒绝相应的用户请求；
2）SQL Azure逻辑数据库容量限制。每个逻辑数据库都预先设置了最大的容
$ g+ Z) u- a  @+ w; ^  e量，超过限制时拒绝更新请求，但允许删除操作；
- b& X# w5 R* C  f+ G3 |3）SQL Server物理数据库数据大小限制。超过该限制时返回客户端系统错误，
此时需要人工介入。
7.2.7　讨论
# |4 u' b* x9 o) g* dMicrosoft SQL Azure将传统的关系型数据库SQL Server搬到云环境中，比较符合
& I# Q( K3 d" d/ d用户过去的使用习惯。当然，云SQL Server与单机SQL Server还是有一些区别：
●不支持的操作：Microsoft Azure作为一个针对企业级应用的平台，尽管尝试支
持尽量多的SQL特性，仍然有一些特性无法支持。比如USE操作：SQL Server可以通
过USE切换数据库，不过在SQL Azure不支持，这是因为不同的逻辑数据库可能位于
不同的物理机器。
●观念转变：对于开发人员，需要用分布式系统的思维开发程序，比如一个连接
除了成功、失败还有第三种不确定状态：云端没有返回操作结果，操作是否成功我
们无从得知；对于DBA，数据库的日常维护，比如升级、数据备份等工作都移交给
了微软，可能会有更多的精力关注业务系统架构。
相比Azure Table Storage,SQL Azure在扩展性上有一些劣势，例如，单个SQL
& s. ]- \5 ?9 Q' _Azure实例大小限制。Azure Table Storage单个用户表格的数据可以分布到多个存储节
点，数据总量几乎没有限制；而单个SQL Azure实例最大限制为50GB，如果用户的数
据量大于最大值，需要用户在应用层对数据库进行水平或者垂直拆分，使用起来比
) z( _4 _. u3 F. D8 ]! S6 ^/ ^% J较麻烦。
: U: E: p- D9 Y

" Y2 k  H% C; ~$ X5 Y; H- u1 x: h2 W