CAP Theorem笔记

时值秋招,offer拿得还算顺利,所以也没有特别大的压力了,这段时间刚好可以加强一下理论的积累。

下午听了一个和CAP相关的讲座——《CAP Theorem and Its Implications for Building Robust Distributed Systems》,当然主要还是介绍CAP Theorem,基本没怎么涉及“健壮的”分布式系统,毕竟1个小时也分享不了多少内容。

虽然网上已经有不少关于CAP的文章了,但和这次讲座上提到的相比,似乎存在一些问题,并不是说做学术的就是权威,大家需要自己斟酌。

CAP最早是由UCB的Eric Brewer教授(现在Google)于2000年在PODC上提出的一个猜想,然后在2002年由MIT的Seth Gilbert和Nancy Lynch完成证明,使之成为了一个Theorem(定理)。

CAP Theorem陈述的是,在一个无法避免网络分区的系统中,任何协议都无法实现同时满足Safety和Liveness性质的原子读写操作。Safety即没有坏事发生,Liveness即好事会最终发生。

目前所述的CAP分别指:

  • Consistency - 一致性,在任一时刻,各副本的内容是一致的,就是所谓的强一致性
  • Availability - 可用性,每次请求最终都能够接收到响应,常和SLA挂钩
  • Partition tolerance - 分区容忍性,对于网络分区的容忍性,例如由于网络故障,导致集群被分割成2个子集群,系统能够继续服务

通常说CAP只能3选2,不知大家是否有想过为何至今没有CA系统?

事实上,网络是不稳定的,网络分区的问题始终无法排除,试想在不保证P的前提下,如何能够实现CA?

只要网络是不稳定的,我们只能从CA中选择一个,例如常见的系统如下:

  • CP:HBase、ZooKeeper等
  • AP:Cassandra、Dynamo(据说它已经放弃了其所有的核心概念)等

常见的强一致性方案,例如2PC、3PC、Raft等协议,总体来说是悲观的,代价较大的。然而很多分布式系统其实并不需要强一致性,例如DNS系统、CDN等,对于过期的信息是存在一定的容忍度,并且它们通常也是乐观的,先执行,出现问题时,再重做即可。

因此最初的CAP猜想是存在如下局限性:

  1. 并不是CAP3选2,通常是CA2选1,除非你有理想中的网络
  2. CA也并不是一定要2选1,如果你将这里的C放宽至Eventual Consistency(最终一致性),那么它可能就是CA各自占比的问题了
  3. 网络分区也并不是不可恢复的,现实世界中,网络分区往往是一个短暂状态
  4. 可用性事实上应该是需要体现延迟的,如果超过一定的阈值,它就应该被理解成不可用

对于学术研究而言,如果某个理论非黑即白,那么我们往往可以通过放宽约束,从中寻找一个折衷的方案,通常会得到一个比较理想的结果。

对于CAP Theorem,同样可以采用该方案,例如将C放宽到Eventual Consistency,或者将A换成SLA(如99.99%)。Eventual Consistency提出的背景就是多DC的数据同步,当业务扩大到全球时,例如Facebook,想要保证全球各副本的强一致性也是不太现实的,毕竟延迟以及带宽的限制始终存在。但纠结的是,Eventual Consistency并不是Silver Bullet,很多场景并不适合,例如支付。

在实际开发过程中,需要划分适合强一致性和弱一致性的场景,前者为全序关系,而后者则为偏序,可以在一定程度上实现并行处理,处理开销是远小于前者的,例如对于电商平台而言,购物车可以使用弱一致性,而支付则需要实现强一致性。此处的“艺术”就是实现强一致性和弱一致性的平衡,或者说尽可能减少强一致性的占比,例如3:7。

在分布式系统领域,追求one-size-fits-all是不切实际的,做好场景的划分,以及合适的折衷不失为一个理性的选择。

说两句: