CAP原则和BASE原则

       CAP和BASE是分布式系统中最常见的两个原则，我们常见的类似的Zookeeper，Eureka中间件，MySQL，Oracle数据库，或者是我们的分布式业务系统，其实都在这两个原则当中。

CAP原则

一致性（C:Conistency）：分布式节点之间的数据或者状态应该保持一致。比如服务注册中间件中注册服务列表应该保持一致，数据库多个从库数据应该保持一致。

可用性（A:Availability）：分布式系统提供的服务应该始终处于可用状态，不会返回500异常，在一定的时间内返回结果。

分区容错性（Partition tolerance）：分布式系统在遇到部分网络故障的情况下，仍然能都对外提供满足一致性和可用性的服务。

       通常会说到在分布式系统当中，CAP永远是无法同时满足的。其实也就是一般的分布式系统要么是满足AP，要么是满足CP。满足CA却丢掉分区容错性本身就违背了分布式系统这个前提。那么为什么C和A无法同时在分布式系统中同时满足呢？

      其实并不是多复杂的因素，只有关键的一点，网络延迟。分布式系统表示存在多节点同时提供服务，同时为了保持一致性，多节点之间的数据必须通过网络进行同步。就是因为这个同步操作带来的网络延迟，决定这C和A之间只能完全满足一个。当一个用户更新了Node1，Node1需要将数据同步到Node2。但是还未更新之间，另外一个用户请求了Node2来获取相同的数据，这个时候返回的肯定不是最新数据，满足了可用性却满足不了一致性。为了满足一致性，在Node2更新之前不允许进行访问，那当一个用户的请求进了Node2则需要等待更新操作完成，这个时候也就是影响了可用性。

      CP和AP其实针对就是分布式系统当中的数据状态，在实际业务中还是需要根据实际情况来进行取舍和平衡。

 

BASE原则

BASE是在无法满足CAP原则的情况下评估出的一种原则，代表是基本可用（Basically Available）、软状态（Soft state）和最终一致性（Eventually consistent）。

基本可用指的是分布式系统在遇到故障的情况下降低一定的可用性，例如请求返回要慢点，活动期间出现等待页面。

软状态是在和服务器的交互过程中出现下游系统拥堵的情况下，给数据加上一个中间状态，例如商城购买商品时候的支付中，支付完成。

最终一致性是数据最终要达到一致的情况。比如一笔支付中状态的数据，它最终要么是支付完成，要么是支付失败。支付中的状态存留的时间取决下游支付系统完成这笔支付的时间。