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

21天学会C语言?3天学会弹钢琴?

放弃一切错误方法,从今天开始“刻意练习”,

因为这才是最强大的,也是唯一正确的学习方法。

--《刻意练习》Anders Ericsson

引言

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

1.系统可用性提升。

2.系统并发能力提升

3.系统容错能力提升。

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

BASE: B asically A vailable(基本可用), S oft state(软状态)和 E ventually 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的全拼是 C onsistency,代表 一致性 的意思。

  2. A的全拼是 A vailability,代表 可用性 的意思。

  3. P的全拼是 P artition 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

联系我

VX搜索【转行程序员】回复”加群“,我会拉你进技术群。讲真的,在这个群,哪怕您不说话,光看聊天记录也是一种成长。 阿里/腾讯/百度资深工程师、Google技术大神、IBM工程师、还有我王炸、敖丙 、各路大牛都在,有任何不明白的都进群提问。

最后,觉得王炸的文章不错就来个三连吧:关注 转发 点赞

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章