时值秋招，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猜想是存在如下局限性：
- 并不是CAP3选2，通常是CA2选1，除非你有理想中的网络
- CA也并不是一定要2选1，如果你将这里的C放宽至Eventual Consistency(最终一致性)，那么它可能就是CA各自占比的问题了
- 网络分区也并不是不可恢复的，现实世界中，网络分区往往是一个短暂状态
- 可用性事实上应该是需要体现延迟的，如果超过一定的阈值，它就应该被理解成不可用
对于学术研究而言，如果某个理论非黑即白，那么我们往往可以通过放宽约束，从中寻找一个折衷的方案，通常会得到一个比较理想的结果。
对于CAP Theorem，同样可以采用该方案，例如将C放宽到Eventual Consistency，或者将A换成SLA(如99.99%)。Eventual Consistency提出的背景就是多DC的数据同步，当业务扩大到全球时，例如Facebook，想要保证全球各副本的强一致性也是不太现实的，毕竟延迟以及带宽的限制始终存在。但纠结的是，Eventual Consistency并不是Silver Bullet，很多场景并不适合，例如支付。
在实际开发过程中，需要划分适合强一致性和弱一致性的场景，前者为全序关系，而后者则为偏序，可以在一定程度上实现并行处理，处理开销是远小于前者的，例如对于电商平台而言，购物车可以使用弱一致性，而支付则需要实现强一致性。此处的“艺术”就是实现强一致性和弱一致性的平衡，或者说尽可能减少强一致性的占比，例如3:7。
在分布式系统领域，追求one-size-fits-all是不切实际的，做好场景的划分，以及合适的折衷不失为一个理性的选择。