随着分布式的发展，分布式的各种理论和工程实践都已经深入每个开发工程师的内心。其中CAP是每个开发工程师或多或少都听过的理论。但你真的理解这个理论了吗？
我们先来看下CAP分别代表什么：
C:consistency,数据在多个副本中能保持一致的状态。
A:Availability，整个系统在任何时刻都能提供可用的服务
P：Partition tolerance，分区容错性，在出现分区的情况下依然能提供服务。
CAP猜想就是说在C，A，P之间最多只能存在两个。
Lynch在2002年发表论文证明了这个猜想，将它上升到定理的层面。我抱着对CAP的疑问看了Lynch的论文。
Lynch在证明中对CAP中的三个概念进行了描述
C：与Atomic等价，即任何写操作都对后面的任何操作都是可见的。
A：可用性，任何的请求都是可终止的（即有正常响应的，在http上即是200）。
P：当发生分区时，两个分区之间是不可达的（任何网络请求都是超时）。
如下图先在分区A中更新了a使a变成a'，那么后在分区B中请求a时，拿到数据是a而不是a'。这个时候就只有如下两种选择。
选择等待直到分区消失，而保证一致性，但请求在分区内没有终止。
选择立即返回，这保证了可用性，但是数据是不一致的。
cap关注的是数据，不是系统，一个系统中，不同的数据在分区发生时，可以有不同的选择。比如说一份商品数据，在分区发生时，他的商品描述是可修改的，可在事后补偿达到最终一致，这放弃了c，但商品价格是不可修改的，因为这会导致发生交易行为时的不一致，这放弃了a。在lynch的论文中也列举了数种解决方案。
分区的发生概论是很低的，我们借用google团队的图片，google在保证99.99%可用性的同时，我们可以看到网络出现问题的概率只有7.6%。当然这和google团队的强大工程能力有关系。所以，我们架构时要考虑的是在未发生分区时如何保证数据的ca，同时也要保证分区发生时我们要选择cp，还是ap。
实际上，因为光的传播速度，我们的网络是有延迟的，同机房都会产生毫秒级的延迟。这意味着，我们的数据同步必然会存在毫秒级的不一致。所以我们要为不同的业务数据分配不同的策略，降低不一致产生的业务影响。甚至有的业务，如金钱业务，我们只能选择ca，单点写入，来消除不一致的影响。
分区只是暂时的，我们需要在分区时做一些工作，来保证我们的数据能在分区结束后达到最终一致性，而BASE理论就是AP的实践。
四、总结
CAP理论告诉我们分区发生时，CA时不可兼得的。但是我们也要清楚的认识到，CA是数据级，我们设计时需要针对不同的数据有不同的策略。同时，我们考虑不发生分区时，延时对一个分布式系统的影响。而我们设计一个系统时，更应该考虑的是整个系统的可用性和一致性双重保障。
