Dynamo数据库论文小结

论文链接：

http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

Dynamo数据库提供了一个key-value的高可用性的数据库。它更是直接启发了Cassandra数据库的存储模式。总结来说，这个数据库的目的是为了高可用和可拓展，为了这两个目标，它采用了最终一致性的模型。这篇总结很简略地描述了Dynamo在设计时候考虑的重点和对应的技术选择。

首先，什么是Dynamo数据库？这个数据库的目的是什么？

这个是数据库是Amazon为了实现高可用和可拓展而开发的，是一个key-value数据库。加入我们要设计这个数据库，从哪里入手呢？

如何在集群中分发数据和如何备份数据？

在去中心化的集群里分发数据，采用一致性哈希算法。而备份数据，也是在一致性哈希算法的基础上采用多个节点存储。

接下来，如何副本之间的一致性？

Dynamo为了维护高可用（尤其是“写”可用）采取了最终一致性的模型。如何读？如何写？ 这个要用到经典的三元组 (N, R, W)，分别代表副本数目，读成功所需最少返回书，写成功需要最少执行数。而既然允许不一致的存在，必然要找到解决的办法，所以

如何解决副本之间不一致？

试想一下，遇到网络分区，不同分区的写操作如何保证？读数据时遇到不同的数据如何取舍？为了解决这些不一致，Dynamo采用了Vector Clock来处理不一致。

正常的情况都考虑完了，我们知道了怎么存储数据，怎么备份数据，怎么解决数据不一致，假设系统出现错误，该怎么办呢？

如何错误探测？

简单一点说，Dynamo使用gossip协议，利用心跳机制来进行错误探测。

节点暂时失效怎么办？

Hinted handoff来解决。比如A出现故障，先把A的数据“暂存”到其他节点X并且告诉X: “这些数据是A的”。X会在之后的过程中定期扫描这个区域，一旦发现A“复活”了，马上把数据换回去。

节点永久失效怎么办？

用anti-entropy协议来解决。

一下是关于论文的总结：

1 诞生的背景

亚马逊的业务要求有两个重点：

• Reliability: outage是不可忍受的（用户体验）

• Scalable：数据量巨大，增长迅速 （数据增长）

在这个基础之上，亚马逊需要开发一个新的数据库模型，用来增强可用性（尤其是“写”的可用用）和可拓展性。

在亚马逊的业务里，有许多主键访问（primary-key access）的数据，比如购物车，seesion management等等。Dynamo也正是针对这些数据，设计出了key-value的数据库存储模式（没有向传统数据库那样提供复杂的查询和事务）。

2  Dynamo的技术选择

很总结的说，Dynamo应用如下技术：

• Data is partitioned and replicated usingconsistent hashing

• Consistency is facilitated by object versioning

• The consistency among replicas during updates is maintained by aquorum-like technique and a

• Dynamo employs a gossip based distributed failure detection and membership protocol

简单来说, consistent hashing分配数据，数据版本号进行一致性管理，quorum-like用来进行数据更新，gossip协议用来错误探测和membership。

Dynamo设计的初衷就是为了那些不需要复杂查询的key-value型数据。因此Dynamo的设计没有考虑ACID中的“C”和“I”，所以并没有对transaction的支持。总的来说，在Dynamo的设计过程中，需要考虑许多问题，比如：

• Partitioning

• Load balancing

• Membership

• Failure detection

• Failure recovery

• Replica synchronization

• Overload handling

• State transfer

• Concurrency and job scheduling

• Request marshalling

• Request routing

• System monitoring

• Alarming

• Configuration management

而这篇论文中讨论的问题是:

i) Partitioning algorithm：使用virtual consistent hashing

ii) Replication：在consistent hashing之后的N-1个节点里保存副本

iii) Data versioning: 对一个object的不同副本使用vector clocks。如果 Va （casually <） Vb, 那么可以直接覆盖，如果不存在Casually关系，只能合并vector clocks，让sematic来处理。

iv) Get and Put：Dynamo使用的是与Cassandra相同的机制，一个client先找到一个coordinator，由这个coordinator来负责发送读写请求。

同时注意（W，R, N）三元组的搭配

Put:

1. Coordinator generates vector clock and new version

2. Send it to other nodes

Get:

1 Gather versions

2 处理版本不一致的情况，进行处理，并且回写

v) Handling Failures: Hinted Handoff

在处理暂时的错误时（比方说A暂时不可达或者网络问题），系统会把副本暂时拷贝到D的一个区域内，并且标明这是A的副本。这个区域里专门存放这个hinted replica。定期扫描这个区域，一旦A恢复马上把这个副本给A送回去。

vi) Handling permanent failures: Replica synchronization

还是存在一种情况是，hinted replica还没被送回去就挂了，因此系统使用了另一种协议：anti-entropy protocol来保持副本同步（利用Merkel Tree）。

vii) Membership and failure detection

利用gossip协议

viii) add/remove nodes

采用一致性hashing，比如向AB之间添加了接待X，之后的节点会在确认之后删除原本他们负责的部分。

ix) Implementation：

每个节点有三个主要的模块：request coordination, membership and failure detection, a local persistence engine.

Local Persistence engine  可以使用了MySQL等数据库，request coordination建立在一个事件驱动的编程上，具体是使用JAVA NIO实现的。