Dynamo: Amazon’s Highly Available Key-value Store

论文报告

林丹

报告内容SYSTEM ARCHITECTURESystem InterfacePartitioningReplicationData versioningHandling Failures: Hinted Handoff Handling permanent failures: Replica synchronizationMembership and Failure Detection

System Interface

将对象与 key 相关联Get() 定位与 key 关联的对象副本，并返回一个对象或一个包含冲突版本

和对应上下文的对象列表

Put() 基于对象的 key 决定将对象的副本放在哪，并将副本写入到磁盘。

Partitioning增量可扩展性 , 将数据动态划分到系统中的节点上去通过 hash算法将对象映射到节点中单调性

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。即能够尽可能小的改变已存在 key 映射关系。平衡性  平衡性是指哈希的结果能够尽可能分布到所有的缓

冲中去，这样可以使得所有的缓冲空间都得到利用。

Partitioning  基本场景 N 个服务器，将对象映射到这 N 个服务器上 hash(key)%N 一切都运行正常，再考虑如下的两种情况；• 1 一个 cache 服务器 m down 掉了（在实际应用中必须要考虑

这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把 cache m 从 cache 中移除，这时候 cache 是 N-1 台，映射公式变成了 hash(key)%(N-1) ；

• 2 由于访问加重，需要添加 cache ，这时候 cache 是 N+1 台，映射公式变成了 hash(key)%(N+1) ；

意味着突然之间几乎所有的映射都失效了，服务器出现大量的读写访问。

3 硬件能力越来越强，想让后面添加的节点多做点活。有什么方法可以改变这个状况呢，这就是 consistent hashing...

Partitioning         构造 hash空间        用 hash 算法将 value 映射到一个 32 位

的 key 值，也即是 0~2^32-1 次方的数值空间； 我们可以将这个空间想象成一个首（ 0 ）尾

（ 2^32-1 ）相接的圆环

把对象映射到 hash 空间接下来考虑 4 个对象 object1~object4 ，通过 hash 函数计算出的 hash 值 key 在环上的分布如图 2 所示。hash(object1) = key1;… …hash(object4) = key4;

Partitioning        把服务器 映射到 hash 空间 假设当前有 A,B 和 C 共 3 台 cache ，那么其映

射结果将如图 3 所示，他们在 hash 空间中，以对应的 hash 值排列。

hash(cache A) = key A;… …hash(cache C) = key C;

服务器 的 hash 计算，一般的方法可以使用 cache 机器的 IP 地址或者机器名作为 hash 输入。把对象映射到 cache

在这个环形空间中，沿着顺时针方向从对象的 key 值出发，直到遇见一个 cache ，那么就将该对象存储在这个 cache 上。

Partitioning考察 cache 的变动移除 cache 添加 cache

Partitioning为了解决平衡性 -------虚拟节点

不使用虚拟节点 使用虚拟节点点 cache A1 和 cache A2 的 hash 值：Hash(“202.168.14.241#1”); // cache A1Hash(“202.168.14.241#2”); // cache A2

A 的 hash 值：Hash(“202.168.14.241”);

Replication为了实现高可用性和耐用性， Dynamo 将数据复制到多台主机上。

假设每个数据项被复制到 N 台主机上，

Coordinator对管理范围内的对象进行读写复制这些 key 到环上顺时针方向的 N-1后继节点。这样的结果是，系统中每个节点负责环上的从其自己到第 N 个前继节点间的一段区域。

Preference list: the list of the nodes that is responsible for storing a particular key.对于 key K : B, C,D

Replication

• 出于对节点故障的考虑 preference list 可以包含超过 N

个节点。其他的节点可以是这个环上的，也可以时其他数据中心的，可以根据需要配置。

• 出于虚拟节点的考虑 由于使用了虚拟节点，对于 key 的后

面的前 N 个后继位置可能少于 N 个物理节点。为了解决这个问题，首先列表的将跳过这个虚拟节点位置，也就是保证列表中只包含不同的物理节点。

数据版本 强一致性：假如 A先写入了一个值到存储系统，存储系统

保证后续 A,B,C 的读取操作都将返回最新值。如果不能保证，写操作就会失败。

Amazon: 在任何时刻用户都可以进行写操作，根据 CAP 原理，在一致性上做出让步。

最终一致性：过程松，结果紧，最终结果必须保持一致性

数据版本 最终一致性允许更新操作可以异步地传播

到所有副本。 问题： 更新的数据还没来得及传播到所有的副本节点，就返回数据给调用者。导

致 get()操作返回一个不是最新的对象。 如果没有失败，那么更新操作的传播时间将有一个上限。但是，在某些故障

情况下，更新操作可能在一个较长时间内无法到达所有的副本。

在 Amazon 的平台，有一种类型的应用可以容忍这种不一致。。。

数据版本

Most recent cart unavailable

购物车应用程序要求一个“添加到购物车“动作从来没有被忘记或拒绝 .

Make change to old version cart

当客户希望增加一个项目到购物车 ( 或从购物车删除 )但最新的版本不可用时，该项目将被添加到旧版本 ( 或从旧版本中删除 ) 。在 Dynamo 中“添加到购物车“和”从购物车删除项目“这两个操作被转成 put请求。

不可用的新版本和变化后的旧版本中的信息都需要保留，因此不同版本将在后面进行协调 (reconciled) 。

数据版本 为了提供这种保证（保留所有版本的信息）， Dynamo 将每次数据修改的结果当作一个新的且不可改变的数据版本。

结果：造成了一份数据会存在多个版本，分布在不同的节点上。这种情况类似于版本管理中的多份副本同时有多人在修改。

多数情况下，系统会自动合并这些版本，一旦合并尝试失败，那么冲突的解决就交给应用层来解决。

这时系统表现出来的现象就是，一个 GET(KEY)操作，返回的不是单一的数据，而是一个多版本的数据列表，由用户决定如何合并。这其中的关键技术就是 Vector Clock 。

一个 Vector Clock 可以理解为一个 < 节点编号，计数器 > 对的列表。每一个版本的数据都会带上一个 Vector Clock 。通过对比两份不同数据的 Vector Clock 就能发现他们的关系。

数据版本假设该商城有 A 、 B 、 C三个 node ，则我们的 N 是 3 。W=1, 根据 W+R>N 有 R=3 。那么就有如下场景：

Write by A, iphone 4000

A: 4000[A:1]

在数据被复制到 B ， C 之前Write by A, iphone 4500

A: 4500[A:2] 4500[A:2],它覆盖了之前的 [A:1], 并复制到 B,C 4500[A:2],

Write by B, iphone 5000

B 5000[A:2,B:1]

在 B 上这个价格被复制到 A ， C 之前， written by C,3000

C 3000[A:2,C:1],

C: 3000[A:2,C:1] A: 4500[A:2] 5000[A:2,B:1] 。最坏的情况，这时有人询问 iphone 的价格。 R =3, 读到所有的数据，

数据版本

最坏的情况，这时有人询问 iphone 的价格。 R =3, 读到所有的节点，系统应该返回哪个？

C: 3000[A:2,C:1] A: 4500[A:2] B : 5000[A:2,B:1] 。

显而易见， A 上的版本最低，应被舍弃，那么 B 和 C 呢？

客户端拿到 3000[A:2,C:1] 和 5000[A:2,B:1]确实有点手足无措，但我们可以让它有个判断依据——比如时间戳——现在客户端看到 C 上的数据是最新的，那么结论就是 3000.

数据版本

Write by A, iphone 4000

A ： 4000[A:1] B ： 4000[A:1]

在数据被复制到 C 之前Write by A, iphone 4500

4500[A:2],它覆盖了之前的 [A:1], 并复制到 C 4500[A:2],

Write by B, iphone 5000

B ：5000[A:2,B:1]C: 5000[A:2,B:1]

复制到 A 之前， written by C,3000

C: 3000[A:2,B:1,C:1] A: 3000[A:2,B:1,C:1] B: 5000[A:2,B:1]

W=2,R=2

A ： 4500[A:2] B ： 4500[A:2]

C: 3000[A:2,B:1,C:1]A: 3000[A:2,B:1,C:1]

数据版本• C: 3000[A:2,B:1,C:1] A: 3000[A:2,B:1,C:1] B: 5000[A:2,B:1]• R=2 ，由于 B 的版本低，所以，无论读哪两个，都会返回 3000,无需客户端做出协调

由此我们也可以看出提高 W 可以降低冲突，提高一致性。但代价也是显然的：写两份显然比写一份要慢，并且同时能写成功的概率也变低了——也就是 Availability降低。这跟 CAP理论也是吻合的。

数据版本• 关于向量时钟一个可能的问题是，如果许多服务器协调对一个对象的

写，向量时钟的大小可能会增长。实际上，这是不太可能的，因为写入通常是由 Coordinator （也就是 Preference list 的第一个节点）执行的。

• 在网络分裂或多个服务器故障时，写请求可能会被不是 coordinator的节点执行，因此会导致矢量时钟的大小增长。在这种情况下，值得限制向量时钟的大小。为此， Dynamo采用了以下时钟截断方案：伴随着每个 ( 节点，计数器 ) 对， Dynamo 存储一个时间戳表示最后一次更新的时间。当向量时钟中 ( 节点，计数器 ) 对的数目达到一个阈值 ( 如 10) ，最早的一对将从时钟中删除。显然，这个截断方案会导至在协调时效率低下，因为后代关系不能准确得到。不过，这个问题还没有出现在生产环境，因此这个问题没有得到彻底研究。

Handling Failures: Hinted Handoff

给定 N=3 。在这个例子中，如果写操作过程中节点 A暂时 Down 或无法连接，然后通常本来在 A 上的一个副本现在将发送到节点 D 。这样做是为了保持期待的可用性和耐用性。发送到 D 的副本在其原数据中将有一个暗示，表明哪个节点才是在副本预期的接收者 ( 在这种情况下Ａ ) 。

D 节点将数据保存在一个单独的本地存储中，他们被定期扫描。在检测到了 A 已经复苏， D 会尝试发送副本到 A 。一旦传送成功，D 可将数据从本地存储中删除而不会降低系统中的副本总数。

Handling Failures: Hinted Handoff“马虎仲裁” (“sloppy quorum”) ：所有的读，写操作是由首选列表上的前 N 个健康的节点执行的，它们可能不总是在散列环上遇到的那前Ｎ个节点。

优点：确保读取和写入操作不会因为节点临时或网络故障而失败。如果你的应用程序需用的可用性很高很高，可以将 W 设置为 1 ，这个时候，只要这个环上还有一个节点是可用的，就可以进行写操作。

甚至整个数据中心宕掉也不怕 Dynamo 可以配置成跨多个数据中心地对每个对象进行复制。

也就是说，一个 key 的 preference list 的构造是基于跨多个数据中心的节点的。这些数据中心通过高速网络连接。这种跨多个数据中心的复制方案使我们能够处理整个数据中心故障。

Handling permanent failures: Replica synchronization

“Hinted Handoff” 的方式在少量的或是短暂的机器故障中表现很好，但是在某些情况下仍然会导致数据丢失。

如上所说，如果节点 D 发现 A 重新上线了，会将本应该属于 A 的副本回传过去，这期间 D 发生故障就会导致副本丢失。

Handling permanent failures: Replica synchronization

Dynamo 中用了 anti-entropy协议来保持副本同步 . anti-entropy: comparing all the replicas of each piece

of data that exist (or are supposed to) and updating each replica to the newest version.

为了更快地检测副本之间的不一致性，并且减少传输的数据量， Dynamo采用 MerkleTree 。

MerkleTree 是一个哈希树 (Hash Tree) ，其叶子是各个 key 的哈希值。树中较高的父节点均为其各自孩子节点的哈希。

Handling permanent failures: Replica synchronization

Dynamo 中，每个节点为它承载的每个 key范围维护一个单独的 MerkleTree 。

D 除了承载 c-d 上的 key范围，由于副本原因，还承载了 B-C,A-B 上的 key范围。这种情况下就维护 3 个 Merkle Tree.

当两个节点的 merkel tree进行比较时，只针对共同承载的 key范围上的 merkle tree进行比较。也就是对副本进行比较。

Handling permanent failures: Replica synchronization

• 1 从根节点开始，• 2 原来的节点将 merket tree 当前层次的 hash 列表传递给其他应

该有副本的节点（目标节点）• 3目标节点接受到这个列表以后，就把这个列表与本身merkel

tree 的同一层次的 hash 列表做比较。如果都相同，说明不用同步。如果不同，找出不同 hash 值的子树。并向原节点发出请求，告诉原节点哪些子树是不同的。

• 4 重复 2 ， 3步骤，直到找到叶子节点。这样就可以找出哪些key 是不同的。

• 5 源节点将不同的 keys 的值传给目标节点。优点：从时间上： MT 利用树形结构避免了可能出现的线性时间比较，迅速定位到差异的 key 值，时间复杂度为 O （ lgn ）；

从空间上：在分布式情况下，空间可以理解为相应的网络传输数据量。不必传输所有的节点，只需传输不同的节点。

Membership and Failure Detection

Ring Membership: 由于各种各样的原因，暂时性的节点掉线是时有发生的。如果因

为一个节点暂时性的掉线，而导致副本迁移等代价高昂的操作显然是不合适的。所以 Dynamo提供了一组命令行接口和 HTTP 接口供管理员手工添加，删除节点。

一旦一个节点的角色发生改变（上线或下线等），它都会将这个改变和发生的时间存储到一个持久的数据库中，这些数据构成了一个节点的状态变迁历史。

通过一个 Gossip-Based Protocol 将这个消息传递出去。每个节点

每间隔一秒随机选择随机的对等节点，两个节点有效地协调他们的状态变迁历史。最后每个节点都会得到整个集群的信息。

Membership and Failure Detection

一个节点对应一个 token 集，也就是在虚拟节点。

该映射被持久到磁盘上，当一个节点第一次启动时，最初只包含本地节点和 Token 集。

这种节点和 token 集的映射，在协调历史通信过程中一同被协调。也就是说划分和布局信息也是基于 gossip协议传播的。此每个存储节点都了解对等节点所处理的标记范围。这使得每个节点可以直接转发一个 key 的读 / 写操作到正确的数据集节点。

Membership and Failure Detection 上述机制可能会暂时导致 logically partition.

例如，管理员可以将节点 A 加入到环，然后将节点 B 加入环。在这种情况下，节点 A 和 B各自都将认为自己是环的一员，但都不会立即了解到其他的节点 (也就是Ａ不知道 B的存在， B也不知道 A的存在，这叫逻辑分裂 ) 。

解决方法：使用种子节点将他们连接起来。 有些 Dynamo 节点扮演种子节点的角色。种子的发现 (discovered) 是

通过外部机制来实现的并且所有其他节点都知道 ( 实现中可能直接在配置文件中指定 seed node 的 IP ，或者实现一个动态配置服务 ,seed register) 。

因为所有的节点，最终都会和种子节点协调成员关系，逻辑分裂是极不可能的。

Membership and Failure Detection节点被永久性地删除 使用 gossip协议，当节点退出时，持久化这个节点的状态变迁历史，并进

行传播。最后换上所有节点都会知道该节点退出， unvailable 。

节点暂时失效 失效检测：如果节点 B 不对节点 A 的信息进行响应 ( 即使 B响应节点 C

的消息 ) ，节点 A 可能会认为节点 B 失败。

只有在有客户端请求推动两个节点进行交流时，才进行检测。一般情况下， 节点双方并不真正需要知道对方是否可以访问或可以响应。

谢谢！