分布式事务的背景
当系统架构使用非单体应用的时候，如采用 面向服务架构、徽服务架构的时候，会将项目拆分为不同的应用服务到单独的运行环境中，应用服务之间通讯使用的如wcf、http、rpc等等远程调用技术、每个服务中都有自己的数据库数据源和本地事务，服务之间互不影响，这种情况下就产生了分布式事务的问题。
CAP是什么
CAP定律是指在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
注意
1、这里说的是在一个分布式系统中才会出现的问题，在单体应用中不会出现CAP三者不可兼得的问题。
2、关于权衡，不要以为在所有时候都只能选择两个特性。在不存在网络失败的情况下（分布式系统正常运行时的必要条件），C和A能够同时保证。只有当网络失败时，才会在C和A之间做出选择。
接下来我们具体来了解CAP具体是什么？
Consistency（一致性）
对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。
Availability（可用性）
任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。
Partition tolerance（分区容错性）
由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。
CAP的取舍权衡
C、A、P三个特性只能满足其中两个，那么取舍的策略共有3种：
- CA没有P；如果没有P就是没有分区的意思，这咱情况下系统没有扩展性，无法部署节点、也就无法完成分布式设计的思想。
- CP没有A；不要可用性的情况下，每个服务器之间保持强一致性而P（分区）之间的数据同步需要一定的时间，同步期间用户会有不好的体验，有很多系统使用的是CP的方案，如 Redis、HBase等
- AP没有C；如果没有C一致性，系统可以高可用分区的情况下，P分区情况下节点之间，节点使用本地数据提供服务，这样的方案下数据在全局来看无法达到一致性。一般在抢购的场景下会出现这种情况，如看到库存还在，但是抢购下单的时候发现库存已经不在了。牺牲数据一致的用户体验，让系统整体可以运行，不会阻塞用户的购物流程。
一般的大型互联网应用采用多主机，集群化部署的方式。这种多节点的架构方式下，对于P的容错是分布式系统架构下一定要面对的问题，于是只能在C和A之间做取舍，但是有时对于一些对C强一致性要求极高的场景中，如银行转账可以在A和P之间取舍，如果出现网络故障，宁可停止服务。
具体可以根据实际的业务场景选择适合的架构设计。
参考：