经验分享 – 大厂-分布式专栏 06 详细说下CAP分别代表什么含义吗

06详细说下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 理论正式成为分布式计算领域的公认定理。

  1. C 的全拼是 Consistency,代表 一致性的意思。
  2. A 的全拼是 Availability,代表 可用性的意思。
  3. 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 定理这个问题还难吗?

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

正文完