分布式之CAP原则

一、知识储备

1.1 一致性（Consistency）

一致性，指的是分布式系统完成某个写操作时，服务器的各个都应该获取到最新的值，保持各个节点之前的数据一致性

1.2 可用性（Availability）

可用性，指的是在分布式系统中，用户可以永远在正常时间内进行读和写操作，一直可以正常访问并得到响应

1.3 分区容错性（Partition tolerance）

分区容错性，是指在分布式系统中，其中一个节点宕机，整个系统还是能满足一致性和可用性的服务，即部分故障不影响整体使用，所以在项目架构时都会考虑一些外部因素造成的故障，都是要求部分故障不影响整体使用的。

二、CAP原则

CAP原则，指在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），这三个要素最多只能同时实现两点，不可能三者兼顾。

2.1 证明

假设有一个简单的分布式系统，只有两台机器A和B，并且发生了网络分区，即A和B之间不能互相通信。
此时，客户端向A发起了一个写请求，并且收到了成功的响应。接着客户端又对B发起了一次读请求，因为B没有收到来自A的同步信息，所以B只有两种选择：要么返回自身已知但已过时的信息，这就违背了一致性；要么不做出响应，这就违背了可用性。

三、常见分布式系统采用的原则

3.1 CP原则

CP：优先保证一致性和分区容错性，在数据一致性要求比较高的场合使用，在出现问题时牺牲用户体验，恢复之后用户正常访问。

zookeeper保证CP原则，即一致性、分区容错性 。zookeeper对于故障实例会直接剔除，不能保证每次请求的可用性，如果其中一个节点宕机或者在和另外一个节点同步数据的时候网络发生问题，请求就会出问题，会等恢复正常数据同步之后才会继续可以访问。==

3.2 AP原则

AP：优先保证可用性和分区容错性，其中一个节点出问题之后还是能正常访问，不会影响用户体验，但是可能接收到的数据不是最新的数据，恢复之后数据变一致。

==Eureka保证AP原则，即可用性、分区容错性 。Eureka为了实现更高的服务可用性，牺牲了一定的一致性，极端情况下宁愿接收故障实例也不愿丢掉健康实例。在其中一个节点出问题时，其他节点可以正常访问，只不过可能数据不是最新数据，eureka还有自我保护机制，在运行期间统计心跳失败的比例，在15分钟之内是否小于85%，如果低于的话就会将这些实例保护起来，不会注销此项服务

3.3 CA原则

CA：数据一致性、可用性。比如京东的JSF微服务框架。

3.4 动态调节一致性和可用性(TACT)

Tunable Availability and Consistency Tradeoffs，简称TACT，是Haifeng Yu和Amin Vahdat提出的一个概念。在这种场景下，不再将一致性和可用性看成非此即彼的关系，而是根据将其看作一个连续的变量，根据实际的需要在其中做选择。

如飞机的订票系统，在余票较多情况下，可以优先保证可用性，随着余票数量下降，系统的一致性越来越重要。例如Cassandra就使用了这种设计思路，可以在读写数据时设置consistency level，根据consistency level来调整系统提供更高的可用性还是一致性。

三、应用场景

1. CA without P，放弃系统扩展性，不部署子节点，比如

   （1）单节点的关系型数据库

2. CP without A，在分布式服务器中保持强一致性，但可能会导致同步时间长，比如

   （1）分布式数据库redis

3. AP without C，放弃一致性，保持高可用。每个节点使用本地数据提供服务，使得全局数据不一致。比如

   （1）手机网购，可能浏览商品时还有货，但下单时系统告诉你下单失败。
   （2）web缓存，相比于长时间加载不出来网页，用户看到没有更新的网页可能更容易接受。