海量存储的一致性和高可用
为了更好的描述一致性，我们通过以下的场景来进行，这个场景中包括三个组成部分：
- 存储系统
存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证。
- Process A
ProcessA主要实现从存储系统write和read操作
- Process B 和ProcessC
ProcessB和C是独立于A，并且B和C也相互独立的，它们同时也实现对存储系统的write和read操作。
下面以上面的场景来描述下不同程度的一致性：
- CA 强一致性
强一致性（即时一致性） 假如A先写入了一个值到存储系统，存储系统保证后续A,B,C的读取操作都将返回最新值
- CP 弱一致性
假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念，它特指从A写入值，到后续操作A,B,C读取到最新值这一段时间。
- AP 最终一致性
最终一致性是弱一致性的一种特例。假如A首先write了一个值 到存储系统，存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到最A写入的最新值。此种情况下，如 果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中replica的个数（这个可以理解为 master/salve模式中，salve的个数），最终一致性方面最出名的系统可以说是DNS系统，当更新一个域名的IP以后，根据配置策略以及缓存 控制策略的不同，最终所有的客户都会看到最新的值。
c是一致性，就是无论何时何人的读取的信息都是一样的，a是高可用，就是无论何时都要保证系统是可用的；p就是容忍集群中有个别的节点失去联系，不是光从一致性上考虑的。
关于数据存储中著名的 CAP 定理, 很多业界人士都给出了自己的解决方案. 美其名曰:"打败CAP定理", 总结如下:
最终一致性(Cassandra的做法):
对于分布式数据系统：
N — 数据复制的份数
W — 更新数据是需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。
如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。
对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。
如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突
Storm的作者的建议:
将实时数据和离线数据进行架构整合, 数据的一致性交由批处理的离线数据负责, Storm产生的实时数据则保证可用性 
相关 Blog
关于NOSQL的CAP分类:
关注一致性和可用性的 (CA)
这些数据库对于分区容忍性方面比较不感冒，主要采用复制(Replication)这种方式来保证数据的安全性，常见的CA系统有：
- 传统关系型数据库，比如Postgres和MySQL等(Relational) ;
- Vertica (Column-oriented) ;
- Aster Data (Relational) ;
- Greenplum (Relational) ;
关注一致性和分区容忍性的(CP)
这种系统将数据分布在多个网络分区的节点上，并保证这些数据的一致性，但是对于可用性的支持方面有问题，比如当集群出现问题的话，节点有可能因无法确保数据是一致性的而拒绝提供服务，主要的CP系统有： 1. BigTable (Column-oriented) ; 2. Hypertable (Column-oriented); 3. HBase (Column-oriented) ; 4. MongoDB (Document) ; 5. Terrastore (Document) ; 6. Redis (Key-value) ; 7. Scalaris (Key-value) ; 8. MemcacheDB (Key-value) ; 9. Berkeley DB (Key-value) ;
关于可用性和分区容忍性的(AP)
这类系统主要以实现"最终一致性(Eventual Consistency)"来确保可用性和分区容忍性，AP的系统有：
- Dynamo (Key-value);
- Voldemort (Key-value) ;
- Tokyo Cabinet (Key-value) ;
- KAI (Key-value) ;
- Cassandra (Column-oriented) ;
- CouchDB (Document-oriented) ;
- SimpleDB (Document-oriented) ;
- Riak (Document-oriented) ;
关于2pc的一致性和脑裂问题:
A prepare --> B commit --> A commit
这是最原始的二阶段提交, 但是 如果B的反馈未知 , 那么整个集群则处于危险状况
-
一致性上就出现了问题，无反馈的情况下，无法区分成功还是失败了，于是最安全和保险的方式，就是等着。。。没错，你没看错，就是死等。等到B给个反馈。。。这种在可用性上基本上是0分了。。无论你有多少机器，死等总不是个办法
-
A得不到B的反馈，又为了保证自己的可用性，唯一的选择就只好像【P A ->C B(b机器挂掉), 这里面所提到的方法一样：等待一段时间，超时以后，认为B机器挂掉了。于是自己继续接收新的请求，而不再尝试同步给B。又因为可用性指标是如此重要，所以 这基本成为了在这种情况下的必然选择，然而，这个选择会带来更大的问题，左脑和右脑被分开了！
碰到问题，就要去解决，所以，针对一致性问题上的那个“死等”的萌呆属性，有人提出了三段提交协议，使用增加的一段提交来减少这种死等的情况。不过3PC 基本上没有人在用，因为有其他协议可以做到更多的特性的同时又解决了死等的问题，所以3pc我们在这里就不表了。3pc是无法解决脑裂问题的，所以更多的 人把3pc当做发展过程中的一颗路旁的小石头。。
而针对脑裂，最简单的解决问题的方法，就是引入第三视点，observer。
既然两个人之间，直接通过网络无法区分出对方是不是挂掉了，那么，放另外一台机器在第三个机房，如果真的碰到无响应的时候，就去问问observer:对方活着没有啊？就可以防止脑裂问题了。但这种方法是无法解决一致性问题中的死等问题的。。。
所以，最容易想到的方式就是，3pc+observer，完美解决双机一致性和安全性问题。