java分布式面试CAP含义

引言

上一节讲面试中被问到分布式系统概念相关的，讲完了分布式系统的概念，优点缺点和 RPC 后，我以为这个问题就到此结束了，没想到成功给自己挖了个坑（微笑脸），关于 CAP，以前只是听说过，并没有详细点整理过，这一次问好好整理了下。

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

1. 系统可用性提升。

2. 系统并发能力提升。

3. 系统容错能力提升。

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

1、面试官，说到 CAP 定理，那能详细说说 CAP 分别代表什么吗？

问题分析：一个很经典的概念性面试题。

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

C 的全拼是 Consistency，代表 一致性的意思。

A 的全拼是 Availability，代表 可用性的意思。

P 的全拼是 Partition tolerance，代表 分区容错性的意思。

2、面试官：听起来很简单，这只是概念，但是具体是什么意思呢？

问题分析：下次这种问题不能等面试官来问了，这面试有点挤牙膏的感觉，不如我一次说完，让面试官闭嘴。

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

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

 （开始拿起纸笔画了三个圈圈）

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

面试官：行了行了，这个理论性的问题就到这，时间有限，我们聊点别的。

举例深入分析

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

 Redis 去中心集群架构优点：

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 会自动同步到 Slave，如果 Master 写服务宕机，Slave 读服务会被提升为 Master ，也就是说机房 1 的数据在机房 2 的 Slave2 上还有备份，数据还在，在宕机的 Master 没有恢复前 Slave 要同时承担读写服务，虽然累一点，但是还能用，这样设计是为了提高可用性（A），和容错性（P）。系统准许你一台机器或者整个机房都宕机，系统仍然能用。

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

进一步分析：

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

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

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

 总结

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

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