Amazon Dynamo论文以及与Cassandra对比

最新推荐文章于 2022-07-23 12:13:52 发布

颛顼子

最新推荐文章于 2022-07-23 12:13:52 发布

阅读量372

点赞数

文章标签：分布式存储数据库

本文链接：https://blog.csdn.net/hohomi77/article/details/108414490

版权

在操作系统顶级会议SOSP2017 上，Dynamo于十年前发表的论文获得了Hall of Fame Award¹。这种回顾性的表彰足以证明其影响力。它的贡献用一句话总结就是催生了一系列 NoSQL 分布式数据库。

作者要解决什么问题？

整个架构是完全去中心化的。
数据的放置和查找都是用一致性哈希。也就是把Key映射到一个环形数域，把每个节点（服务器）也映射到同一个环形数域。
一个Key归离它最近的下一个节点负责。
为了能故障耐受，数据还会被replicate到下面的N - 1个节点。
读写用的是quorum read/write，就是读至少读R个节点，写至少写W个节点，W/R是预先规定好的数字满足 W + R = N + 1，这样就能保证读一定能读到之前的写。（但是Dynamo又不严格这样做，如果实在满足不了的。比如写的时候，有个别机器慢或者挂了，就写到再后面的节点去。等本应该负责的节点恢复了，再复制回去原来该去的地方。）
虽然画图的时候大家都画成环形的，但并不是说每个节点只跟它的邻居两个节点通信。而是每个节点都知道所有节点的信息。有成员变化，是通过节点间的gossip，逐渐传到所有节点。

最终一致性（eventual consistency）
- 网络分区的时候，仍允许写。网络合并的时候保留不同版本，让客户端决定怎么合并。
不太严格的规定出席人数（sloppy quorum）
- 用的是quorum法，但是实在达不到也不强求。这样是为了优化最坏情况(Worst-case scenario)。

下面这张图中，D1、D2、D3、D4、D5是同一个键的不同版本的值。Sx、Sy、Sz是三个节点（服务器）。小括号里面的就是vector clock。准确地说应该叫版本向量（version vector）²。它是由若干个 [ node, counter] 组成的。
箭头表示什么呢？A -> B，表示B知道A的这个版本，或者说B是在A的基础上UPDATE得到的。从版本向量来看，就是B每一个counter都大于或等于A的。
版本向量怎么产生的？每个value都要带上版本向量，节点在修改一个key-value的值时，会在相应的计数器上加1。比如图中D1到D2，是Sx节点做了修改，就在Sx的counter上加1。从D2到D3是在另一个节点Sy上做了修改，所以就加了Sy的counter。
网络分区的时候，就会产生分歧。有的节点看到D3这个修改，有的节点看到了D4这个修改。
Dynamo的做法是，当有分歧的时候，把对象的所有不同版本都返回给客户端，让客户端决定如何合并。然后把合并后的结果写回去，这就是D5。

Cassandra是Dyanmo这篇论文的开源复刻版。
写采取严格的quorum，必须等到W个副本都写好，才回复客户端。读则根据客户端的要求，要么只读1个副本，要么读到R个副本。——所以它不是走最终一致性这条路线。³
用zookeeper，来选一个Leader，并保存整个系统的配置信息。Leader负责成员的join和leave，也负责分配replica的存放位置。（类似6.824 Lab 4的ShardMaster？）
失效节点的检测——用的是Accrual Failure Detector。通过估算得出节点失效的概率，避免一定要尝试通信然后等Timeout才确定节点失效。优点是速度和准确度。
应用程序可以选择副本的策略：是Rack Unaware，还是Rack/Datacenter Aware，也就是可以要求就近做副本。防止读写的延迟过大。
用NTP对时，要求所有存储服务器，运行客户端库的机器，都要对时，采取相同的时间。应该是用来给对象版本打时间戳的，因为不是采用单一写者，所以出现不同版本的时候，以时间戳为准，时间晚的视为最新版本（last writer wins）。从Spanner就知道这种简单做法是不够的，否则Spanner也不需要用到原子钟，还要commit wait来消除时间误差的影响。