nosql理论笔记(3)
最近读了Amazon Dynamo的论文，记录几个关键点，说明大致的原理，不追求语言的准备下和严谨性。
CAP，在Dynamo论文发布后开始流行，CAP在这之前已经被提出来，大致的意思是这样的：
C:Consistent，一致性：任何一个读操作总是能够读取之前完成的写操作结果
A:Available，可用性：每一个操作总是能够在确定的时间内返回
P:Partition-tolerance，分区容忍性，在网络出现分区时，任然满足一致性和可用性
CAP理论认为三者无法同时满足，当网络分区时，一致性就得不到满足了。
Dynamo也是以CAP为指导思想进行设计的，在论文中提到引入了NWR可以配置策略，N代表系统存储数据分数，R表示读参与的节点，W表示写参与的节点。 当N =R，W=1强调可用性 ；N=W，R=1强调可用性，N=3，R=2，W=2这个是一个折中的策略。
为了增加系统可用性，Dynamo不要求系统的强一致性，也是使用了最终一致性概念：在过程中允许部分不一致，但是操作的最后是一致性的，这里就有个不一致的时间窗口，根据业务的不同，能容忍的时间窗口也是不一致的。这个时间窗口依赖于交互延迟，系统负载，以及数据副本的个数。
Dynamo和GFS，Bigtable不同，他是为了去中心化的，和p2p相似，没有中心化的Master，力求避免中心化单点故障带来的系统不可用的问题，所以系统中所有的机器都是平等的。Dynamo使用Consistent hashing算法支持分布式多节点，将每台机器实现成S个虚拟节点，这样N台机器一共有S*N个节点，这样形成一个虚拟节点的环，虚拟节点在环上均匀分布，当主键为key的节点进行hash(key)%S*N，在环上按顺时针查找大于hash(key)%S*N的第一个节点进行存储，当需要复制多份副本的时候，依次向后面的几个节点进行复制。
使用了Consistent hashing算法可以做到如下方面：
1.对物理机器可以做权重了，采用虚拟节点，在好机器上可以多设置几个节点，在差机器上可以少设置几个节点
2.当机器宕机或者新增机器时，hash值的分配不会有很大的抖动，受到影响的只有邻近的两个节点，之后需要复制的节点也会有后续的节点替补，这个后面再说。
当多个客户端并发的对同一个key进行数据的修改时，可能会引起数据混乱，数据冲突；Dynamo使用了Vector clock进行管理数据，也就是多版本数据管理，必要时还需要进行依赖合并。Vector clock 示意图如下：
这个模型在某些情况下面是有问题的：
比如A操作获得数据是个list，add一个value，put回这个list；B操作同时获得这个list，截取这个list，put回截取的list，这个时候可能就会引起数据问题，后来又使用了last write win的策略，那么像上面所说那种操作就会丢失部分数据了。
考虑到数据副本复制的问题：当在复制过程当中，被选中的机器发生宕机下线了，此时需要顺时针找到下一台机器，将数据复制给这台机器，并记录失败的机器地址，宕机的机器分为临时失效和永久失效两种，临时失效的机器重新上线后需要进行数据同步，此时原来记录失败的机器地址的机器通过Gossip协议发现临时失效机器重新上线，将失效这段时间的数据传送给他，完成了数据归还。当机器是永久失效，则机器需要同步失效机器的数据了。
一次数据的读写流程基本上是这样的：
客户端的读/写请求首先传输到有缓存的一台机器，根据预先配置的N、W和R值，对于写请求，根据DHT算法计算出数据所属的节点后直接写入后续的N个节点，等到W个节点返回成功时返回客户端，如果写请求失败将加入retry_list不断重试。如果某台机器发生了临时性异常，将数据写入后续的备用机器并在备用机器中记录临时异常的机器信息。对于读请求，根据DHT算法计算出数据所属节点后根据负载策略选择R个节点，从中读取R份数据，如果数据一致，直接返回客户端；如果数据不一致，采用vector clock的方法解决冲突。Dynamo系统默认的策略是选择最新的数据，当然用户也可以自定义冲突处理方法。读取过程中如果发现副本中有一些数据版本太旧，Dynamo内部异步发起一次read-repair操作，更新过期的数据。
Dynamo的问题
在网上我看到很多大牛多Dynamo论文的缺陷，主要有以下几点：
1.Dynamo依赖合并冲突来解决问题，一些场合下冲突很难解决，就像我前面所说的那样(其实对于任何cache的系统，如果没有版本号的话，并发的插入同个key的数据肯定会有数据丢失，一般做法是版本低插入数据失败，客户端需要重新尝试插入数据)
2.可能读到脏数据影响后续的写入(这个个人观点是第1点)
3.Dynamo中即使N + W > R，这里所谓的“最终一致性”还是依赖冲突合并算法，最后读取的结果和客户期望的结果可能不一致
Dynamo还是有很多可取之处，去中心化，一致性hash，NRW的使用，也让除了GFS和Bigtable后有了一个新的理论指导。
