《大规模分布式存储系统》 第5章 分布式键值系统【5.1】

javazx

第5章　分布式键值系统
分布式键值模型可以看成是分布式表格模型的一种特例。然而，由于它只支持
针对单个key-value的增、删、查、改操作，因此，适用3.3.1节提到的哈希分布算
法。
* L( g: {' o0 \. ], QAmazon Dynamo是分布式键值系统，最初用于支持购物车应用。Dynamo将很多
- N6 ?* M7 \  J: |+ F分布式技术融合到一个系统内，学习Dynamo的设计对理解分布式系统的理论很有帮
2 A* i9 c! `9 g* b8 L, |助。当然，这个系统的主要价值在于学术层面，从工程的角度看，Dynamo牺牲了一
4 s) [: V" K$ i7 C9 B$ `# X$ r致性，却没有换来什么好处，不适合直接模仿。
6 w: `/ r) k: K) U1 WTair是淘宝网开发的分布式键值系统，它借鉴了Dynamo系统的一些设计思路并
做了一些创新，其中最大的变化就是从P2P架构修改为带有中心节点的架构，笔者认
/ [  ?6 o9 I  H* x$ e0 O为，这种思路在大方向上是正确的。
" ^7 D2 Q, p! H5 o- j本章首先详细介绍Amazon Dynamo的设计思路，接着介绍淘宝网的Tair系统。
+ t! p  S" h' C1 P* `5.1　Amazon Dynamo
) Z+ e# H" g* ~' dDynamo以很简单的键值方式存储数据，不支持复杂的查询。Dynamo中存储的是
) Z' z- [2 c7 J# _! R: q1 _0 Q数据值的原始形式，不解析数据的具体内容。Dynamo主要用于Amazon的购物车及S3
云存储服务。
Dynamo通过组合P2P的各种技术打造了线上可运行的分布式键值系统，表5-1中
列出了Dynamo设计时面临的问题及最终采取的解决方案。
& v( `; G4 ~5 N+ W( m  G5.1.1　数据分布
$ f2 [% I9 M- ^& ~' t: I8 Z' U" qDynamo系统采用3.3.1节（见图3-2）中介绍的一致性哈希算法将数据分布到多个
存储节点中。一致性哈希算法思想如下：给系统中每个节点分配一个随机token，这
) |) o) J' k. t3 t0 Q些token构成一个哈希环。执行数据存放操作时，先计算主键的哈希值，然后存放到
( o" K' b2 I. E/ i0 T+ Q; i顺时针方向第一个大于或者等于该哈希值的token所在的节点。一致性哈希的优点在
! }1 u5 m" h; c9 N+ H于节点加入/删除时只会影响到在哈希环中相邻的节点，而对其他节点没影响。
考虑到节点的异构性，不同节点的处理能力差别可能很大，Dynamo使用了改进
7 Z( J8 q  O( r2 O的一致性哈希算法：每个物理节点根据其性能的差异分配多个token，每个token对应
一个“虚拟节点”。每个虚拟节点的处理能力基本相当，并随机分布在哈希空间中。
8 Q, S2 w& C9 m. _$ N- f9 s1 x存储时，数据按照哈希值落到某个虚拟节点负责的区域，然后被存储在该虚拟节点
- y/ |1 y/ B4 J4 r; g* l所对应的物理节点中。
如图5-1所示，某Dynamo集群中原来有3个节点，每个节点分配了3个token：节点
' E( E2 [, q9 B/ S  k7 F' I1（1，4，7），节点2（2，3，8），节点3（0，5，6）。存放数据时，首先计算主
键的哈希值，并根据哈希值将数据存放到对应token所在的节点。假设增加节点4，
Dynamo集群可能会分别将节点1和节点3的token 1和token 5迁移到节点4，节点token分
, V+ E  {) C; ?, l配情况变为：节点1（4，7），节点2（2，3，8），节点3（0，6）以及节点4（1，
5 o& t' y; {. e% \1 c5）。这样就实现了自动负载均衡。
图　5-1　Dynamo虚拟节点
8 v9 E6 X$ ^* n& U' L+ U为了找到数据所属的节点，要求每个节点维护一定的集群信息用于定位。
Dynamo系统中每个节点维护整个集群的信息，客户端也缓存整个集群的信息，因
此，绝大部分请求能够一次定位到目标节点。
* U' T+ k* W" m由于机器或者人为的因素，系统中的节点成员加入或者删除经常发生，为了保
! f& p5 B) x2 ?( l3 P0 r证每个节点缓存的都是Dynamo集群中最新的成员信息，所有节点每隔固定时间（比
. d7 L; G6 @; m4 E& X4 _如1s）通过Gossip协议的方式从其他节点中任意选择一个与之通信的节点。如果连接
" M. V5 E) F2 K0 Z, H8 J成功，双方交换各自保存的集群信息。
$ J; n* E6 x8 X! O2 V* |6 EGossip协议用于P2P系统中自治的节点协调对整个集群的认识，比如集群的节点
  Y2 F6 ~' p2 ^( J9 l- O  @状态、负载情况。我们先看看两个节点A和B是如何交换对世界的认识的：
1）A告诉B其管理的所有节点的版本（包括Down状态和Up状态的节点）；
  c1 C4 A" v2 ]: @1 O1 K2）B告诉A哪些版本它比较旧了，哪些版本它有最新的，然后把最新的那些节
' {) o0 E9 O& x# G+ J) T点发给A（处于Down状态的节点由于版本没有发生更新所以不会被关注）；
$ }, D) @& o0 ^( k& Q6 v& h3）A将B中比较旧的节点发送给B，同时将B发送来的最新节点信息做本地更
5 j" C7 u9 M* H7 H: T0 [0 T. c" ?新；
4）B收到A发来的最新节点信息后，对本地缓存的比较旧的节点做更新。
由于种子节点的存在，新节点加入可以做得比较简单。新节点加入时首先与种
9 V% b) g: O) i1 r# s9 |子节点交换集群信息，从而对集群有了认识。DHT（Distributed Hash Table，也称为
一致性哈希表）环中原有的其他节点也会定期和种子节点交换集群信息，从而发现
# B  f" \, |% I/ |) q( r新节点的加入。
( ^- ]1 K2 B! W$ _0 W集群不断变化，可能随时有机器下线，因此，每个节点还需要定期通过Gossip协
议同其他节点交换集群信息。如果发现某个节点很长时间状态都没有更新，比如距
7 @1 |: H+ c6 C7 @离上次更新的时间间隔超过一定的阈值，则认为该节点已经下线了。
5.1.2　一致性与复制
为了处理节点失效的情况（DHT环中删除节点），需要对节点的数据进行复
& u7 u* C5 ^- W! o制。思路如下：假设数据存储N份，DHT定位到的数据所属节点为K，则数据存储在
节点K，K+1，……，K+N-1上。如果第K+i（0≤i≤N-1）台机器宕机，则往后找一台
机器K+N临时替代。如果第K+i台机器重启，临时替代的机器K+N能够通过Gossip协
( b# S+ f9 @) \) Z, H议发现，它会将这些临时数据归还K+i，这个过程在Dynamo中叫做数据回传（Hinted
Handoff）。机器K+i宕机的这段时间内，所有的读写均落入到机器[K，K+i-1]和
[K+i+1，K+N]中。如果机器K+i永久失效，机器K+N需要进行数据同步操作。一般来
% A# j7 ]' @/ q说，从机器K+i宕机开始到被认定为永久失效的时间不会太长，积累的写操作也不会
太多，可以利用Merkle树对机器的数据文件进行快速同步（参见下一小节）。
& }5 {7 r: R# v* e) B3 JNWR是Dynamo中的一个亮点，其中N表示复制的备份数，R指成功读操作的最
' M$ P/ D0 h/ r: S6 i少节点数，W指成功写操作的最少节点数。只要满足W+R＞N，就可以保证当存在不
$ k; M' l& T  p& V超过一台机器故障的时候，至少能够读到一份有效的数据。如果应用重视读效率，
可以设置W=N，R=1；如果应用需要在读/写之间权衡，一般可设置N=3，W=2，
R=2；当然，如果丢失最后的一些更新也不会有影响的话，也可以选择W=1，R=1，
N=3。
5 k: X' F4 ~7 z' eNWR看似很完美，其实不然。在Dynamo这样的P2P集群中，由于每个节点存储
  X2 I3 F: n0 l) o6 g的集群信息有所不同，可能出现同一条记录被多个节点同时更新的情况，无法保证
多个节点之间的更新顺序。为此Dynamo引入向量时钟（Vector Clock）的技术手段来
尝试解决冲突，如图5-2所示。
' O& Q& s9 y; c/ s1 |* ?  ^图　5-2　向量时钟
Dynamo中的向量时钟用一个[nodes,counter]对表示。其中，nodes表示节点，
counter是一个计数器，初始为0，节点每次更新操作加1。首先，Sx对某个对象进行
一次写操作，产生一个对象版本D1（[Sx，1]），接着Sx再次操作，counter值更新为
2，产生第二个版本D2（[Sx，2]）；之后，Sy和Sz同时对该对象进行写操作，Sy将
自身的信息加入向量时钟产生了新的版本D3（[Sx，2]，[Sy，1]），Sz同样产生了新
的版本信息D4（[Sx，2]，[Sz，1]），这时系统中就有了两个冲突的版本。最常见的
冲突解决方法有两种：一种是通过客户端逻辑来解决，比如购物车应用；另外一种
1 ~$ i% F& a7 `* U9 F常见的策略是"last write wins"，即选择时间戳最新的副本，然而，这个策略依赖集群
% e: b1 }  J, A内节点之间的时钟同步算法，不能完全保证准确性。
向量时钟不能完美解决冲突，即使N+W＞R,Dynamo也只能保证每个读取操作能
3 V9 V2 G. b" O1 @6 l; ~4 P读到所有的更新版本，这些版本可能冲突，需要进行版本合并。Dynamo只保证最终
一致性，如果多个节点之间的更新顺序不一致，客户端可能读取不到期望的结果。
# V8 ]+ W8 W% [  I. C1 `这个不一致问题需要注意，因为影响到了应用程序的设计和对整个系统的测试工
作。
, a- |* i3 L% s2 m0 G6 @5.1.3　容错
Dynamo把异常分为两种类型：临时性的异常和永久性异常。有一些异常是临时
6 R6 g. K5 H) C8 B性的，比如机器假死；其他异常，如硬盘报修或机器报废等，由于其持续时间太
9 f0 n# j! _, ~: C4 L4 s长，称为永久性的。下面解释Dynamo的容错机制：
' u& S+ n6 J, K1 x9 B●数据回传　在Dynamo设计中，一份数据被写到K，K+1，……，K+N-1这N台
+ s- x- A. \6 y7 X- w: o2 ?机器上，如果机器K+i（0≤i≤N-1）宕机，原本写入该机器的数据转移到机器K+N，
如果在指定的时间T内K+i重新提供服务，机器K+N将通过Gossip协议发现，并将启
动传输任务将暂存的数据回传给机器K+i。
/ O8 X* D: k0 |0 \●Merkle树同步　如果超过了时间T机器K+i还是处于宕机状态，这种异常被认为
( p- j" u; K% u/ s0 ^' j是永久性的。这时需要借助Merkle树机制从其他副本进行数据同步。Merkle树同步的
原理很简单，每个非叶子节点对应多个文件，为其所有子节点值组合以后的哈希
值；叶子节点对应单个数据文件，为文件内容的哈希值。这样，任何一个数据文件
* z- ?8 i* S; j不匹配都将导致从该文件对应的叶子节点到根节点的所有节点值不同。每台机器对
3 s+ }: L7 Z$ q2 J7 q! L9 c, m' r" }( }每一段范围的数据维护一颗Merkle树，机器同步时首先传输Merkle树信息，并且只需
6 C& O5 t/ R' P要同步从根到叶子的所有节点值均不相同的文件。
  E# b+ A4 S, ^●读取修复　假设N=3，W=2，R=2，机器K宕机，可能有部分写操作已经返回客
户端成功了但是没有完全同步到所有的副本，如果机器K出现永久性异常，比如磁盘
故障，三个副本之间的数据一直都不一致。客户端的读取操作如果发现了某些副本
5 ]9 x8 P) {* a! V版本太老，则启动异步的读取修复任务。该任务会合并多个副本的数据，并使用合
并后的结果更新过期的副本，从而使得副本之间保持一致。
% N# ~8 G# ]6 H  u% r5.1.4　负载均衡
. q' K/ Z: y% z" l( fDynamo的负载均衡取决于如何给每台机器分配虚拟节点号，即token。由于集群
环境的异构性，每台物理机器包含多个虚拟节点。一般有如下两种分配节点号的方
法。
●随机分配。每台物理节点加入时根据其配置情况随机分配S个Token。这种方法
. m: {: N) C& f* Z+ N1 w的负载平衡效果还是不错的，因为自然界的数据大致是比较随机的，虽然可能出现
某段范围的数据特别多的情况（如baidu、sina等域名下的网页特别多），但是只要切
2 ^: O3 C, T; Q2 d/ w8 l6 X4 B分足够细，即S足够大，负载还是比较均衡的。这个方法的问题是可控性较差，新节
+ z- P4 h" B1 O点加入/离开系统时，集群中的原有节点都需要扫描所有的数据从而找出属于新节点
的数据，Merkle树也需要全部更新；另外，增量归档/备份变得几乎不可能。
●数据范围等分+随机分配。为了解决上种方法的问题，首先将数据的哈希空间
: D* }* M  |: k; E  K/ l+ g等分为Q=N×S份（N=机器个数，S=每台机器的虚拟节点数），然后每台机器随机选
# L2 U9 T7 I% ?: `5 X; o8 w0 t择S个分割点作为Token。和上种方法一样，这种方法的负载也比较均衡，并且每台
机器都可以对属于每个范围的数据维护一颗逻辑上的Merkle树，新节点加入/离开时
* r6 Q. e5 T/ d只需扫描部分数据进行同步，并更新这部分数据对应的逻辑Merkle树，增量归档也
变得简单。
- l" p  q1 J# a6 I另外，Dynamo对单机的前后台任务资源分配也做了一些工作。Dynamo中同步操
( F2 J0 E- C8 t- K& k" d作、写操作重试等后台任务较多。为了不影响正常的读写服务，需要对后台任务能
6 T# G8 Q, C5 f6 ?9 u. l, p# K0 k" o够使用的资源做出限制。Dynamo中维护一个资源授权系统。该系统将整个机器的资
& i7 w+ r! B$ t源切分成多个片，监控60秒内的磁盘读写响应时间，事务超时时间及锁冲突情况，
+ e4 g) [$ h8 g# C6 a2 W根据监控信息算出机器负载从而动态调整分配给后台任务的资源片个数。
- v- t( k3 g# ]0 ?9 i$ F5.1.5　读写流程
Dynamo的读写流程如图5-3和图5-4所示。
( W6 [) D, Q, \0 V图　5-3　Dynamo写入流程
图　5-4　Dynamo读取流程
Dynamo写入数据时，首先，根据一致性哈希算法计算出每个数据副本所在的存
9 x* L+ |! N8 M* s) t储节点，其中一个副本作为本次写操作的协调者。接着，协调者并发地往所有其他
副本发送写请求，每个副本将接收到的数据写入本地，协调者也将数据写入本地。
# R* W; L0 m6 x1 T  W当某个副本写入成功后，回复协调者。如果发给某个副本的写请求失败，协调者会
将它加入重试列表不断重试。等到W-1个副本回复写入成功后（即加上协调者共W个
1 H$ l4 u  D, A" v副本写入成功），协调者可以回复客户端写入成功。协调者回复客户端成功后，还
% W7 ~, |5 [% g! O: R) n: D  G/ u会继续等待或者重试，直到所有的副本都写入成功。
+ f4 f! a) s2 _6 {3 O: R# dDynamo读取数据时，首先，根据一致性哈希算法计算出每个副本所在的存储节
9 J# M1 Q9 \, w1 X点，其中一个副本作为本次读操作的协调者。接着，协调者根据负载策略选择R个副
& \! n, y) A, M本，并发地向它们发送读请求。每个副本读取本地数据，协调者也读取本地数据。
当某个副本读取成功后，回复协调者读取结果。等到R-1个副本回复读取成功后（即
) @- W3 B% V- P' E& d加上协调者共R个副本读取成功），协调者可以回复客户端。这里分为两种情况：如
果R个副本返回的数据完全一致，将某个副本的读取结果回复客户端；否则，需要根
据冲突处理规则合并多个副本的读取结果。Dynamo系统默认的策略是根据修改时间
戳选择最新的数据，当然用户也可以自定义冲突处理方法。读取过程中如果发现某
  n- S9 A  Y0 E3 v些副本上的数据版本太旧，Dynamo内部会异步发起一次读取修复操作，使用冲突解
决后的结果修正错误的副本。
3 m2 ?* v0 z$ D" ~5.1.6　单机实现
Dynamo的存储节点包含三个组件：请求协调、成员和故障检测、存储引擎。
1 S3 I( k6 ]: |! S; o0 ]2 RDynamo设计支持可插拔的存储引擎，比如Berkerly DB（BDB），MySQL InnoDB
7 n' a/ c* g% s* {) _; J' S5 O等。存储的需求很多，设计成可插拔的形式允许用户根据应用特点选择合适的存储
引擎，比如BDB存储的对象大小一般在几十KB之内，而MySQL可以处理更大的对
象。用户会根据应用对象大小选择存储引擎，默认为BDB。
请求协调组件采用基于事件驱动的设计，每个客户端的读写请求对应一个状态
* k$ z' h8 X+ a# Q机，系统根据发生的事件及状态机中的状态决定下一步的操作。比如读取操作对应
4 A2 W% o! a8 }; a的状态包括：
( u( [4 r$ G# S# D●协调者发送读请求到其他节点；
●等待其他节点返回读取结果，最少需要R-1个；
●如果请求其他节点返回失败，需要按照一定的策略重试；
) G: y8 k2 k3 @  q7 ?9 A$ H; E●如果到达时间限制成功的节点仍然小于R-1个，返回客户端请求超时；
- O7 N5 S0 t9 y●合并协调者及其他R-1个节点的读取结果，并返回客户端，合并的结果可能包
* r% |% y- Y! ?6 o含多个冲突版本；如果设置了冲突解决方法，协调者还需要解决冲突。
读操作成功返回客户端以后对应的状态机不会立即被销毁，而是等待一小段时
, u0 F7 _/ T0 A+ u% d, q间，这段时间内可能还有一些节点会返回过期的数据，协调者将更新这些节点的数
据到最新版本，这个过程称为读取修复。
6 Z4 }9 h! }- N5.1.7　讨论
Dynamo采用无中心节点的P2P设计，增加了系统可扩展性，但同时带来了一致
9 w% ?  Q1 d- \$ Y性问题，影响上层应用。另外，一致性问题也使得异常情况下的测试变得更加困
难，由于Dynamo只保证最基本的最终一致性，多客户端并发操作的时候很难预测操
作结果，也很难预测不一致的时间窗口，影响测试用例设计。
总体上看，Dynamo在Amazon的使用场景有限，后续的很多系统，如Simpledb，
' D4 y0 b% f1 D7 T5 e采用其他设计思路以提供更好的一致性。主流的分布式系统一般都带有中心节点，
这样能够简化设计，而且中心节点只维护少量元数据，一般不会成为性能瓶颈。
从Amazon、Facebook等公司的实践经验可以得出，Dynamo及其开源实现
Cassandra在实践中受到的关注逐渐减少，无中心节点的设计短期之内难以成为主
流。另一方面，Dynamo综合使用了各种分布式技术，在实践过程中可以选择性借
鉴。


3 N( o! p( f9 G( }; n7 @