分布式系统不得不说的CAP定理

引言

CAP问题已经成了计算机科学中一个研究领域，之前说到分布式系统有哪些优势时讲到三个提升：

1.系统可用性提升。

2.系统并发能力提升

3.系统容错能力提升。

那么这三方面在实施起来可以同时满足吗？答案是不能，设计分布式系统的时候，设计者需要理解一个重要的理论概念，CAP定理。

BASE: Basically Available（基本可用）, Soft state（软状态）和 Eventually consistent（最终一致性）

2012年Brewer发表了一篇文章，重新解释了他对CAP定理的理解：

1. 首先，网络分区的发生是小概率事件，当网络没有发生分区的时候没有任何理由放弃C或者A
2. 其次，在同一个系统中C和A的选择可能发生多次，不同的子系统可以做不一样的选择，当条件不同时做出的选择可以不一样，例如：不同的操作、数据、用户可能会导致不同的选择
3. 最后，这三个属性不是0和1的选择，而是线性的。可用性很明显可以从0%到100%，其实一致性甚至分区容忍性也是有差别的

CAP分别代表什么吗？

关于CAP，它是2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理。

1. C的全拼是 Consistency，代表一致性的意思。
2. A的全拼是Availability，代表可用性的意思。
3. P的全拼是Partition tolerance，代表分区容错性的意思。

三选二：CP、AP、CA

一个分布式系统最多同时满足一致性 (Consistency)，可用性 (Availability) 和分区容忍性 (Partition Tolerance) 这三项中的两项。

• 同时满足一致性（C）和可用性（A）就要牺牲掉容错性（P）
• 同时满足可用性（A）和分区容错性（P）就要牺牲掉一致性（C）
• 同时满足一致性（C）和分区容错性（P）就要牺牲掉可用性（A）

这三个象限，只能同时满足其中两个圆圈的交集。

举个例子

用 Redis Cluster高可用架构举例：redis就能会将数据分片到多个实例(按照slot存储)中，即一个机房分担一部分数据。Master 负责写，Master会自动同步到 Slava。

Reids去中心集群架构优点：

1. 无中心架构：三机房部署，其中一主一从构成一个分片，之间通过异步复制同步数据，异步复制存在数据不一致的时间窗口，保证高性能的同时牺牲了部分一致性一旦某个机房掉线，则分片上位于另一个机房的 slave 会被提升为 master 从而可以继续提供服务，
2. 可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除。
3. 降低运维成本，提高系统的扩展性和可用性。

分析，这个分布式架构中满足了CAP中哪个两个定理？

优点1中讲到，三机房部署，每个机房有一主一从，即一个 Master 对应一个 Slave ，但是你会发现，机房1中的 Master 1 连接的 Slave 在机房2，机房2中的 Master 2 连接的 Slave 在机房3，机房3中的 Master 3 连接的 Slave 在机房1，这样构成一个环，为什么要这样设计？

假设：机房断电or火灾or其他各种原因，反正就是机房1所有机器都不能用了。

这个时候那机房1的全部数据都不能访问了吗？这显然是我们不希望的。前面已经说了Master 负责写，Master会自动同步到 Slava，如果 Master写服务宕机，Slave 读服务会被提升为 master ，也就是说机房1的数据在机房2的Slava2上还有备份，数据还在，在宕机的master没有恢复前 Slave 要同时承担读写服务，虽然累一点，但是还能用，这样设计是为了提高可用性（A），和容错性（P）。系统准许你一台机器或者整个机房都宕机。系统仍然能。

公众号【转行程序员】回复”加群“，我会拉你进技术群。

但是你会发现，单个机房如果距离很远， Master 1 的数据同步到 Slave2 上是跨机房，跨机房同步肯定不如同机房块，这样一来 Slave2 负责的读就会有延迟，Master1 要更新的数据还没有同步到他在另一个机房的备份前，读操作就是不一致的，这样设计显然是牺牲掉一致性（C）。相信这样分析应该能理解CAP定理了。

进一步分析：

让同一组 Master - Slave 放在一个机房，同机房复制数据不是更快？这样能不能解决数据一致（C）问题，答案是能，还有更好的解决一致性的办法就是不要Master - Slave 组合，就一台机器，一台机器同时担任读写请求，没有延迟不存在数据一致性问题。这是时候如果宕机了怎么办？这样的架构下，那就真的是不可用了，解决了一致性（C）却牺牲了可用性（A）和容错性（P），太不划算了。

总之，分布式系统下，CAP确实无法同时满足，在Reids去中心集群架构中，最优的解决方案还是满足可用性（A）和分区容错性（P）就要牺牲掉一致性（C），即使跨机房同步数据，延迟也不过1s，数据不一致的问题只出现在1s内，日常开发中，很少遇到要求强一致性的场景。例如订单系统，用户更新了订单支付状态，读订单状态是在从库，有什么读场景等不来这一秒？

如果真的必须要求强一致性，那可能就必须调整分布式架构方案来。

总结

本文主要讲解了CAP定理的概念，为什么要学习这个概念，设计高可用分布式系统时，你必须知道系统的短处，懂得CAP能让你根据实际情况有舍有得。面试会被经常问到，比如，你说你使用了消息队列，解决了系统耦合问题，提高了响应速度，那面试官问题：使用消息队列有啥缺点？如果你知道CAP定理这个问题还难吗？

显然消息的延迟会带来数据不一致问题。理想情况下消息不丢失那数据会最终一致，你能保证消息不丢失吗？如何解决机问题，如果是我，我会选择“最终一致性”，就是说不管消息延迟多久甚至丢失，设计一个离线定时任务，定期去扫描两个系统的数据，有不一致的情况就主动刷新同步，这样保证最终一致。

参考资料

• CAP theorem – Wikipedia
• CAP Twelve Years Later: How the “Rules” Have Changed