Amazon Dynamo的NWR模型，把CAP的选择权交给了用户，让用户自己选择CAP中的哪两个。   N代表N个副本（replication），W代表写入数据时至少要写入W份副本才认为成功，R表示读取数据时至少要读取R份副本。对于R和W的选择，要求W+R > N。    优化写性能(AP) 当我们需要优化写性能（写多读少）的时候，可以配置W = 1 （写完一个副本就成功，其他的副本就异步去慢慢复制都可以），如果N=3，那么根据公式W+R>N，则R = 3（读取数据的时候需要读3个副本以判断数据是否有冲突）。 这种情况只要写任何节点成功就认为成功，但是读的时候必须从所有的节点都读出数据。   优化读性能(CP) 当我们需要优化读性能（读多写少）的时候，可以配置 W=N（写完所有的副本才成功，只能同步复制），根据公式W+R>N，则 R=1（只需读一个副本即可）。这种情况任何一个节点读成功就认为成功，但是写的时候必须写所有三个节点成功才认为成功。   平衡读写性能(AC) 当我们数据不多，单台能搞定，且不需要容错和扩展性的时候，可以配置N=1（只有一份数据），根据公式W+R>N，则W=1，R=1。这种情况就简化为单机问题了。     多个线程会同时更新一份数据，在这种情况下怎么保证一致性？   Amazon Dynamo使用多版本并发控制，即乐观锁。如果用户A读出来的数据的版本是v1，当用户A计算完成后要更新数据时，却发现数据的版本号已经被更新成了v2，那么服务器就会拒绝更新导致更新失败，这时候就需要用户A自己处理冲突，方法为：重新读取v2数据，然后重新计算，重新更新。这里跟在svn提交代码发生冲突的情况是一样的，svn提交代码遇到冲突，需要先更新代码，解决冲突之后才能再次提交。   如何发现不同节点上面的副本不一致？   还有更糟糕的时候（W=1），用户A更新一个副本，在A的更新还没有异步复制到其他副本之前，如果用户B也更新了其他副本，那么数据就处于不一致的状态了，同样需要用户自己处理。    Amazon  Dynamo使用Vector Clock（向量时钟）。每个节点各自记录自己的版本信息，包括：1）更新数据的节点名称，2）版本号。   如下所示，有A、B和C三个节点，W=1，R=N=3：  

1. （节点A写了两次）一个写请求，第一次被节点A处理了。节点A会增加一个版本信息(A，1)。我们把这个时候的数据记做D1(A，1)。 然后另外一个对同样key的请求还是被节点A处理了于是有D2(A，2)。这个时候，D2是可以覆盖D1的，不会有冲突产生。
2. （节点A的数据成功异步复制到节点B和节点C，节点A、节点B、节点C处于一致）现在我们假设D2异步复制到了所有其他节点(节点B和节点C)，节点B和节点C收到的数据不是来自用户，而是由节点A异步复制（为了让所有副本保持一致）来的，所以节点B和节点C不产生新的版本信息，因此现在节点B和节点C所持有的数据还是D2(A，2)。于是节点A，节点B，节点C上的数据及其版本号都是一样的。
3. （节点B写了一次）如果有一个新的写请求到了节点B上，于是节点B生成数据D3(A,2; B,1)，意思是：数据D全局版本号为3，节点A更新了2次，节点B更新了1次。
4. （节点C写了一次：节点B的改变还没异步复制到节点C之前节点C就写完了）如果D3还没有异步复制到节点C的时候，节点C又处理了一个新的写请求，于是，节点C上的数据是D4(A,2; C,1)。
5. 好，最精彩的事情来了：如果这个时候来了一个读请求，因为W=1，R=N=3，所以R会从所有三个节点（A、B、C）上读，此时，他会读到三个版本：

• A结点：D2(A,2)
• B结点：D3(A,2; B,1);
• C结点：D4(A,2; C,1)

  6.这个时候可以判断出，D2已经是旧版本（已经包含在D3/D4中），可以舍弃。   7.但是D3和D4是明显的版本冲突，只能交给用户自己去做版本冲突管理。就像前面说的svn源代码版本管理一样。