CAP

单一的垂直型架构已经无法很好的满足大流量的系统需求，继而产生了分布式的架构。分布式架构中会将各个服务独立部署为进程，并采用各种技术手段保障HA，但在分布式系统中，经常遇到单一架构中没有的事务问题。也就是分布式事务问题，为了解决这个问题，各大厂商都提出了自己的中间件。eg：

蚂蚁金服的分布式事务产品：https://tech.antfin.com/products/DTX

阿里云的全局事务服务：https://help.aliyun.com/product/48444.html

要理解分布式事务解决方案，必须先了解其基础理论，今天我这篇文章的主题就是分布式事务的基础理论--CAP（有很多地方都是参考其他的文章）

什么是CAP

cap：

C：consistency 一致性；不管有多少个数据源，每次读取的结果一致，等同于访问一份最新的数据副本。

A：availability 可用性；只要接受到客户的请求，服务端就一定要给出响应，就算部分节点故障，也要响应请求。

P：partition tolerance 分区容错性；分布式系统的子系统一般都分布在各个子网络，每一个子网络都是一个独立的分区（partition），系统设计的时候一般都会考虑到整个问题，所以CAP中的P总是成立，剩下的C和A无法同时做到。

 

很多朋友也许会疑惑，为什么3点不能同时满足。看如下案例：

我们来看一个简单的问题, 一个DB服务   搭建在两个机房（北京,广州)，两个DB实例同时提供写入和读取

  1. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功
      在没有出现网络故障的时候，满足CA原则，C 即我的任何一个写入，更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致， A 即我的读写操作都能够成功，但是当出现网络故障时，我不能同时保证CA，即P条件无法满足

  2. 假设DB的更新操作是只写本地机房成功就返回，通过binlog/oplog回放方式同步至侧边机房
      这种操作保证了在出现网络故障时,双边机房都是可以提供服务的，且读写操作都能成功，意味着他满足了AP ，但是它不满足C，因为更新操作返回成功后，双边机房的DB看到的数据会存在短暂不一致，且在网络故障时，不一致的时间差会很大（仅能保证最终一致性）

  3. 假设DB的更新操作是同时写北京和广州的DB都成功才返回成功且网络故障时提供降级服务
      降级服务，如停止写入，只提供读取功能，这样能保证数据是一致的，且网络故障时能提供服务，满足CP原则，但是他无法满足可用性原则