分布式事务之CAP定理:对于共享数据系统,最多只能同时拥有CAP其中的两个,无法三者兼顾。一句话概述:分布式系统中,网络故障、服务瘫痪仍然能保持数据的一致性。
1.CAP定理
加州大学计算机科学家Eric Brewer提出,分布式系统有三个指标:

Consistency: - 说明:等同于所有节点访问同一份最新的数据副本。 - 情景:分布式系统的几台服务器,写入之后由于同步延时等,使得几台服务器读取的结果不一致。
Availability: - 说明:每次请求都能获取到非错的响应。 - 情景:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据(不覆盖C)。
Partition tolerance: - 分区的定义:区间通信可能失败。 - 说明:系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。 - 情景:比如,一台服务器放在中国,另一台服务器放在美国,这就是两个区,它们之间可能无法通信:G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息,G2 可能无法收到。
2.CAP技术实现的困难
在分布式系统中,同时满足“CAP定理中的“一致性、可用性和分区容错性”三者是不可能的,其根本原因是Consistency和Availability 的矛盾。
一致性和可用性,为什么不可能同时成立?答案很简单,因为可能通信失败(即出现分区容错)。
举例:北京的订单系统,访问上海的库存系统,可能导致失败。如果发生失败,就要在A和C之间做出选择。要么停止系统进行错误恢复,要么继续服务但是降低一致性,所以说只能保证AP或CP。
CAP有哪些组合方式呢?
所以在生产中对分布式事务处理时要根据需求来确定满足CAP的哪两个方面。
AP:放弃一致性,追求分区容忍性和可用性。这是很多分布式系统设计时的选择。 例如:上边的商品管理,完全可以实现AP,前提是只要用户可以接受所查询的到数据在一定时间内不是最新的即可, 通常实现AP都会保证最终一致性,后面讲的BASE理论就是根据AP来扩展的,一些业务场景 比如:订单退款,今日退款成功,明日账户到账,只要用户可以接受在一定时间内到账即可。
CP:放弃可用性,追求一致性和分区容错性,我们的zookeeper其实就是追求的强一致,又比如跨行转账,一次转账请求要等待双方银行系统都完成整个事务才算完成。
CA: 放弃分区容忍性,即不进行分区,不考虑由于网络不通或结点挂掉的问题,则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统,我们最常用的关系型数据就满足了CA。

总结: 通过上面我们已经学习了CAP理论的相关知识,CAP是一个已经被证实的理论:一个分布式系统最多只能同时满足 一致性(Consistency)、可用性(Availability)和分区容忍性(Partition tolerance)这三项中的两项。它可以作 为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景,结点众多、部署分散,而且现在的 集群规模越来越大,所以节点故障、网络故障是常态,而且要保证服务可用性达到N个9(99.99…%),并要达到良好的响应性能来提高用户体验,因此一般都会做出如下选择:保证P和A,舍弃C强一致,保证最终一致性。