【分布式】CAP理论及其应用

CAP Theorem

CAP 指的就是 "consistency 一致性","availability 可用性" "partition-tolerance分区容错性".
consistency：一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。
特点：
- 由于数据同步过程，写操作的响应存在一定的延迟
- 为了保证数据一致性会对资源进行暂时锁定，待数据同步完成释放锁资源
- 如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。
availability：可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。
特点：
- 所有请求都有响应，且不会出现响应超时或响应错误。
partition-tolerance：网络中断等问题发生后系统能正常工作，提供服务，保证一致性和可用性，不同分区之间数据同步时不影响分区数据的读写操作。一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。所以在CAP原则里面，分区容错性是必须要有的
特点：
- 分区容忍性分是布式系统具备的基本能力。

一致性、可用性和分区容错性不可能同时全部满足。最多只能满足其中两个。一致性和可用性是相互矛盾的，一般只能满足其中之一。

CAP组合方式

AP：牺牲了数据一致性，追求可用性和分区容错性。可能导致全局数据不一致。客户端发出请求之后，为了保证可用性，得到的响应可能是旧的数据，因为数据的同步需要时间，但在某些情况下旧数据也是可以接受的，通常实现AP都会保证最终一致性。比如订单退款操作，用户申请退款以后，得到信息”今日退款成功，明日账户到账“，只要用户接受在一定时间内到账即可。AP的应用也比较广泛，主要好处是可以保证数据传递的时效性，提高用户体验。AP是最常见的模型。
CP ：放弃可用性，追求一致性和分区容错性。属于强一致性。等待数据同步完才能正常访问服务，保证用户得到的数据一定是最新的，否则不返回数据。一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验。举个例子，银行跨行转账时，一次转账需要等待双方银行都完成整个事务的时候才算完成，这种应用场景常见于金融系统。应用有Redis、zookeeper等。
CA：放弃了分区容错性，保证了一致性和可用性。这就不属于一个严格的分布式系统了，任何一个分区服务器出故障，都可能导致整个系统的崩溃。关系型数据库满足CA，比如Oracle、MySQL。
以上所写的”牺牲、放弃“等并不是表示完全怕抛弃某一个特性，而是表示降低对该特性的要求，提高另外对两个特性的要求