CAP理论分析

CAP理论概念

• 可用性：我部署两台Redis机器在一个集群中（主备集群），如果此时有一台Redis挂了我客户端照样可以访问另一台Redis，保证了一定程度的可用性（保证允许一台Redis宕机）
• 一致性：如果我客户端在A节点的Redis设置了一个M值，然后A节点宕机，此时换B节点的Redis上，如果B节点正好同步了这个M值，就保证了一致性，但是有可能B节点的Redis还没来得及同步这个M值，我客户端在B节点读不到M值，这就存在了一致性问题
• 分区容错性：这两台主备Redis发生了分区（A、B节点互相连接不上），那就做不了数据同步了，但此时集群依然向外开放服务，此时集群具有分区容错性，如果发生分区，集群就不能对外服务，则集群不具有分区容错性（P特性）

分布式系统中只能保证CP或AP

分区容错性，代表当分布式节点发生分区（A、B节点互相连接不上）此时的分布式系统是否还提供服务（是否容错），如果没有了P，代表发生分区之后整个分布式集群不能使用，这显然是不行的。下面看看保证P与不保证P的集群是什么样的：

如果没了P，理论上集群不容许任何一个节点发生分区，当没有分区发生时确实可以保证AC（谁能保证集群系统的节点百分百不会出问题呢？能保证也不需要讨论AC问题了），当发生分区时整个集群不可用，没有现实意义，如果保证P，说明集群就只能从A和C选择其一。
综上所述，所以做一个分布式系统，P一定需要保证，那么我们的焦点就在AP与CP的模型去选择

CP和AP分析

A和B节点，A节点的数据未成功同步B节点，

• CP：若此时不让客户端读取B节点的M值，那么此时不可用，只能让客户端读取A节点，在A节点中M值确实是刚刚客户端Set M = 1值，M值一致，此时是CP模型，可用性被舍弃。
• AP：若此时可以让客户端读取B节点的M值，那么此时节点可用，但是读取到的值M=0，如果下次又来一个客户端读取A节点的M值，却读到了M=1，M值不一致，此时是AP模型，一致性被舍弃

数据复制

半数复制原则：只有Leader节点接受事务请求，Leader节点会通知其他节点保存数据，当有半数节点返回OK，Leader节点也保存数据，返回给客户端保存成功信息（保证数据在超过半数的节点上）

领导者选举

• 获得集群内大多数节点的选票的节点才能当一个Leader

• 每一个节点都可以发起选举让别人投自己一票，每一个节点在同一个任期号内只能投一票

如何保证一致性

假设此时客户端在写入一个值M=1

根据数据复制规则，Leader只需要保证数据在多数节点上保存下来就可以返回成功, 若此时Leader在收到半数节点OK之前就挂了，那么客户端也会返回一个设置M值错误，显然此时的集群数据是一致的（从未保存过值）,Leader在收到半数节点OK，证明数据在大部分节点上之后，返回给客户端设置值成功之后Leader节点就挂了,群龙无首，此时必须选举出一个新的Leader, 数据较新的节点会选举成功，若拥有最新数据的节点也挂了呢？， 这时会出现选不出leader的现象， 整个集群不可用， 可看成满足一致性。

总结

从上面的讨论上来看，半数很关键（半数提交、半数选举），相信看到这里你会懂得这半数的魔力，接下来总结一下此分布式一致性协议由于"半数"会有哪些问题：

事务操作的性能瓶颈：由于需要保证半数节点保存了数据，则增删改数据的性能取决于半数节点的性能（5个节点的写入性能则取决于3个节点（包括自己）的写入速度）和与半数节点通信的网络开销。这意味着，集群节点越多（如果想要高可用，那就上多节点），写入性能有可能会越差（试想，上100个节点，每次写入都要发给50个节点确保写入成功，有50次网络开销，不过数据复制过程是并行的，木桶效应总耗时取决于半数中最慢的那个节点，不过节点越多，木桶短板出现的概率也就越大，所以这里说写入性能是可能变差的）

基本可用：集群由于需要半数提交才能成功写入数据，所以如果5个节点宕机2个集群是可用的，若宕机3个，由于得不到半数的提交，集群就会不可用，从这点上来看达到了基本可用的特性

最终一致性 or 强一致性（线性一致性）：

如果我们仅仅只是写入一个值，从写入角度来说那就是强一致性（因为都在Leader处理，Raft与Zab都支持顺序一致性，即为你刚刚Set M = 1，又Set M = 2，顺序如果反了那结果会变成 M = 1，由于都在同一个Leader节点做，节点维护一个队列即可保持顺序），所以下面更多的是对于读数据的一致性讨论

最终一致性：这取决于具体的实现，若是最终一致性，那么Follower就开放读能力，这么做有个优点，整个集群的读能力会随着节点个数得到提升，但有个缺点，由于半数提交的规则，有可能上一秒你写入成功了一个值，下一秒在集群另外某个节点中读不到这个值（可能还没同步到），但最终会在一个时间点此值被同步，也就是最终一定会达到一致性
强一致性（线性一致性）：如果读能力只在Leader节点开放，也就是读我也只能在Leader上读，那么此时的一致性是极强的，随着上一秒的设置值，下一秒一定可以查到刚刚设置的值，缺点就是读性能得不到扩展，局限于Leader单点性能的问题（读写都在一台节点上操作）
以上讨论了CP模型，对一致性要求比较高的系统比较适用，可以看出来，这种分布式协议有性能的局限性，因为他牺牲了一定的客户端响应延迟来确保一致性，而且仅仅保证了半数的基本可用性。在延时要求高、高并发场景下这种模型或许并不适用，此时可以考虑AP模型提高响应延迟。

如果是AP模型，相比于一致性协议会简单一些，因为他只需要保证可用性，加集群节点即可，而数据丢失、不一致的情况只会在宕机的那一时刻发生，丢失、不一致的也只是那一时刻的数据，例如Redis的主从集群架构，主Redis节点只需要异步、定时去同步数据，在写入时只需要一个节点确认写入即可返回，延时比一致性协议低，由于Redis在使用上大部分场景都用在缓存，快是他的设计目标，偶尔丢几条或者不一致几条缓存数据并不影响场景。

参考

从分布式CAP理论到分布式一致性协议