Dynamo是Amazon提供的一款高可用的分布式Key-Value存储系统，其满足可伸缩性、可用性、可靠性。
CAP原理满足：通过一致性哈希满足P，用复制满足A，用对象版本与向量时钟满足C。用牺牲C来满足高可用的A，但是最终会一致。但是，是牺牲C满足A，还是牺牲A满足C，可以根据NWR模型来调配，以达到收益成本平衡。
Dynamo内部有3个层面的概念：
Key-Value：Key唯一标识一个数据对象，Value标识数据对象实体，通过对Key来完成对数据对象的读写操作。
节点node：节点是指一个物理主机。在每个节点上，会有3个必备组件：请求协调器（request coordination）、成员与失败检测、本地持久引擎（local persistence engine），这些组件都由Java实现。本地持久引擎支持不同的存储引擎，最主要的引擎是Berkeley Database Transactional Data Store（存储数百K的对象更合适），其它还有BDB Java Edtion、MySQL以及一致性内存Cache。本地持久化引擎组件是一个可插拔的持久化组件，应用程序可以根据需要选择最合适的存储引擎，比如：如果存储对象的通常为数千字节则可以选择BDB，如果是更多尺寸则可以选择MySQL。生产中，Dynamo通常使用BDB事物数据存储。
实例instance：从应用的角度来看就是一个服务，提供IO功能。每个实例由一组节点组成，这些节点可能位于不同的IDC，这样IDC出现问题也不会导致数据丢失，这样会有更好的容灾和可靠性。

二、背景条件
1、系统假设与要求
（1）查询模型
基于Key-Value模型，而不是SQL即关系模型。存储对象比较小，通常小于1MB。

（2）ACID属性
传统的关系数据库中，用ACID（A原子性、C一致性、I隔离性、D持久性）来保证事务，在保证ACID的前提下往往有很差的可用性。Dynamo用弱一致性C来达到高可用，不提供数据隔离I，只允许单Key更新。

（3）效率
在廉价的机器上满足SLA，通过配置来满足延时和吞吐量的要求，因此，必须在性能、成本、可用性和持久性保证之间做权衡。

（4）其它假设
Dynamo仅在Amazon内部使用，因此，认为其使用环境是可信赖的。

2、服务水平协议（SLA）
        所谓服务水平协议是指客户端和服务端在某几个指标上达成一致的一个协议，通常包括客户端请求API的速率、服务端的预期延时，比如：在客户端每秒500个请求负载的高峰时，99.9%的响应时间为300毫秒。
        一般业界，对这种面向性能的SLA采用平均数（average）、中值（median）和预期变化（expected variance）。但是这些指标只能对大多数客户端有良好体验，而不是所有。为了解决这个问题，Dynamo采用99.9%百分位来代替这些指标。

3、设计考虑（复制数据）
传统的数据复制算法，在出现故障时，为了保证数据一致性被迫牺牲掉可用性，即：与其不能确定数据是否正确，不如让数据一直不可用直到数据绝对正确时。

但是，一个高度灵活的系统应该能够让用户知道在何种情况下能到达哪些属性，Dynamo就是如此。

对于故障是常态的系统来说，采用乐观复制技术可以提供系统的可用性，但带来的问题是需要检测并协调解决冲突，协调解决冲突的过程又包含两个问题，即：何时协调和由谁协调。Dynamo的设计是数据存储最终一致，即所有更新操作最终到达所有副本。