Dynamo: Amazon’s Highly Available Key-value Store （下）
前言
这篇博文是上一篇博文的后续部分。重点大都在上篇中，为了完整性，这篇主要简单收个尾。
六、Implementation
这个部分简要介绍了一点实现的细节部分。说的是每个存储结点主要包括三个主要的组件：
- 本地持久化存储引擎（local persistence engine）：dynamo允许上层的应用根据不同的存储需求选择不同的底层持久化引擎。paper中说到dynamo提供了BDB,mysql以及in-memory buffer（本质上来说这个应该算不上持久化引擎）这三种存储引擎。
- 请求协调器（request coordinator ）: 每一个读或者写请求都由一个Coordinator来协调完成。Coordinator会建立一个状态机（按照我的理解就是一系列读写流程）来执行整个完整的读(写)操作。
- 成员及故障检测器（membership and failure detection）：这个部分paper中暂且没有提到。
注：
- 具体的读写过程这里就不说了，这里简单说点设计要点吧。在read的时候，Coordinator可能会执行read repair来给其它的副本提供丢失的数据；在write的时候，选取的coordinator并不一定是第一个，考虑到负载均衡的需要，coordinator有可能是perference list 中的任何一个。如果是先read后write的情况，系统会优先选取read操作时response最快的那个node结点。
七、Experiences & Lessons Learned
这一部分主要是介绍了设计dynamo的过程中的一些经验。大概有以下几点：
（1）、一般来说，在分布式系统中，性能（Performance）和持久性（Durability）是一对矛盾的特性。为了提供系统的持久性，一般会增加副本数，这样的话，又会降低系统的性能（如果要保持一定的一致性，则必须要把相关的操作（读或者写）应用的更多的副本中去）。 这个时候就需要系统的使用者来进行trade-off 。 dynamo中给用户提供了这种机制，使用者可以设定写入的副本数，读取的副本数， 即quorum机制。
（2）、对于数据partition来说，dynamo采用的是一致性hash算法。对于一致性hash算法中node选择的虚拟节点问题（paper中称作token），paper分析了三种不同的策略：
- T random tokens per node and partition by token value.
- T random tokens per node and equal sized partitions
- Q/S tokens per node, equal-sized partitions
这部分我也不是非常了解，以我的浅见来看， 策略2是过度策略，策略1和策略3的本质区别在于其是否把hash ring 分成相同大小的partition。前者采用简单的随机挑选策略，后者把整个ring分成Q个相等大小的range, 总共有S个node, 每个node 分配Q/S 个range; 后者的一个优点在于对于实现分割好的range，如果有node的加入或移除，不需要从相邻的结点遍历所有的data，只需要按照需求遍历对应的range 就可以。
（3）、paper中说到的第三个learned point 就是数据什么时候会产生不一致，即divergent version。 总的来说有两个时候，一是在出现failure的时候（包括network partition，node failure 等）； 二是在出现对同一个结点数据出现大规模并发写的时候。
（4）、第四点讲的是系统中的读写请求的路由问题。系统提供了两种方案：一个是客户端负责，另一个是由一个中间的load-balancer来负责。paper中的实验表明，前者的方案相对来说，效果更好些。
（5）、paper中第五点说明的是在系统中对于background tasks （比如说数据同步等）不应该过多的影响到正常的读写请求（foreground）。因此系统中设立了monitor, 用以检测后台任务的资源占用情况和正常请求的性能，并以此做出相应的feedback 处理。
注：influxdb内部实现的时候，好像也有类似的监控机制。
八、Conclusion
最后，稍微总结下。
对于dynamo系统来说，它是一个高可用的KV存储系统。在整个系统的设计与实现中，有以下几个要点：
（1）、为了保持系统的高可用，放弃了数据的强一致性，利用hinted-off 和anti-entropy（repica synchronization） 采用了最终一致性。
（2）、为了适应不同的应用需求（对于性能、持久化、一致性的不同要求），在实现具体的读写一致性的时候，使用了类似quorum的机制，给上层的开发者提供了（N,R,W）参数配置的能力。
（3）、采用了去中心化的结构，使用了gossip协议来“传播” 系统的元数据信息（membership信息）。
参考
【1】、论文笔记-1：Dynamo: Amazon’s Highly Available Key-value Store
【2】、分布式存储系统学习笔记(三)—分布式键值系统(1)—Amazon Dynamo