CAP无法同时满足的原因
通过这个场景来证明CAP（C一致性、A可用性、P分区容错性）无法同时满足，
用户下单，库存减1，订单加1，用户积分增加。
P分区容错性：网络是不可靠的，需要容忍网络带来的一些问题，所以要么保证A舍弃C，要么保证C舍弃A。
在高可用且保证用户体验的情况下，一定时间内必须给用户响应，即保证CP的情况下需要舍弃A高可用。
如果库存扣减成功，但在订单增加的时候卡住了，为了保证数据的一致性，需要等待重试，直到这2个数据统一以后，才能正常的往下运行。这个时候保证了CP，但高可用无法保证，因为在当前订单服务卡死的情况下，没办法在限定的时间之内给用户做出响应。
如何保证AP？
加入库存成功了，订单服务出现了问题，如果保证AP，则设置一个超时时间，比如在2秒内必须给用户返回响应 ，哪怕是异常响应（比如当前系统繁忙，请稍后重试），而不是让用户等着。
如果要保证数据一致性的话，用户只能转圈等待，但为了保证用户体验和高可用，就需要在指定时间之内给出响应，这个时候就保证了AP，C一致性就无法保证了，因为超出了2秒之后做出响应的时候，这时数据还没有完全达到一致性的状态。
这也是为什么CAP不能同时存在的原因，在分布式系统中P是必须保证的，因为没有P网络的话，就不能称之为分布式系统，所以要么保证CP要么保证AP。
在CAP理论之下，诞生了Base理论。
Base理论
Base理论有3个状态：基本可用、软状态、最终一致性，对一致性和可用性权衡的结果，源于大规模互联网系统分布式实践的总结，也是基于CAP定理演化而来的。
Base的一个核心思想：即使无法做到强一致性（数据必须同步），但每个应用都可以根据自身特点采用适当的方式来达到最终一致性。
基本可用：在整个分布式系统中出现了不可预知的故障，允许丧失一部分系统的可用性的。
比如双11，用户下单，在高并发的情况下，有些服务是没有办法用的，库存服务和订单服务需要保证能够正常使用，因为是核心业务，但是用户积分并不是核心业务，允许用户系统丧失一部分系统的可用性。
因为网络问题或并发量太高了，不需要立刻把积分加上，可以允许一段时间之后再加上，用户看到的是老的数据而不是最新的数据。
所以也就提出了软状态和基本可用的概念，核心业务要保证高可用，软状态是允许用户积分系统基本可用，待一定时间之后同步最新数据。
基本可用
分布式系统出现了不可预知的系统故障，允许损失一部分可用性，但绝不等于系统不可用。
1、响应时间上损失，比如正常情况下需要0.5秒响应，但是如果出现了故障响应时间达到了1-2秒。
2、系统功能的损失，正常情况下，消费者可顺利完成订单，但在节假日或大促期间，为了保证服务器的稳定，消费者可能会被引导到一个降级页面。
软状态
软状态就是一种中间状态，数据允许存在中间状态，并认为该中间状态的存在不会影响整个系统的可用性，即允许系统不同节点数据副本之间同步过程存在延迟。
库存和订单需要保证一致性，但是用户积分需要一段时间同步之后，才能达到数据最终一致性。
最终一致性，是所有数据副本通过一段时间同步之后，最终达到的一致性状态，而不是实时同步（强一致性）。
在过了流量高峰以后，经过一段时间的同步，保持各服务数据的一致。
Base理论是基于CAP理论诞生的，很多分布式事务的解决方案是基于Base理论诞生的。
2PC两阶段提交协议
将整个事务分为2个阶段：准备阶段和提交、回滚阶段。
和相亲对象吃饭，饭店老板规定吃饭必须先付钱，男方提出AA，即两人只要有一个人不愿意交钱，就不能吃饭。
准备阶段：老板要求男方付款，男方把钱交了，要求女方付款，女方把钱交了。
提交阶段：老板出餐，两人吃饭。
如果女生不同意，相当于两人在准备阶段，男方把钱交了，女方不交钱，在提交阶段做回滚操作，回滚的时候，老板需要把男方的钱退回，然后两人离开。
这就是一个分布式事务的场景，男女双方只要有一方拒绝付款，老板就不出餐并且会把收到的钱原路返回。
分布式事务的角色
一个是事务的管理器，一个是事务参与者，事务管理器是老板，男女双方是事务的参与者。
由管理器来抉择整个分布式事务，事务管理器决策整个分布式事务在计算机中关系型数据库支持的两阶段提交协议的过程。
在准备阶段，事务管理器会向每个参与者发送准备消息，每个事务参与者（比如数据库）参与执行本地事务，（对应着男方交钱、女方交钱），会写入日志数据，这个日志是undolog和redolog，此时事务并没有真正提交，只是一个准备阶段。
undolog是记录修改前的数据，数据是用于数据回滚的；redolog是记录修改后的数据，比如有1000块钱交100吃饭还剩900，undolog记录1000，redolog记录900。
在提交阶段，如果事务管理器收到了提交失败或超时的消息，则直接给每个参与者发送回滚的消息，否则就是整体提交。
参与者根据事务管理者的指令来执行提交或回滚的操作，并且在执行之后要释放整个事务中所使用的资源，也就是说需要把日志给删掉。
在准备阶段，事务管理器发送消息，让男女双方交钱，如果分别把钱交了，再分别回给事务管理器一个状态：钱交了。
第二个阶段就是提交阶段：老板出餐，双方吃饭。
如果女方回绝：我不吃这饭了 。其中有一个事务参与者返回失败的消息给事务管理者，最终进行回滚，即把收到的钱退回。
订单、库存的场景
TM（事务管理器）发送准备消息给订单服务和库存服务，订单服务开始事务、执行本地事务，本地事务提交，此时订单加1了，给TM返回一个执行成功的消息；再调用库存，库存开始事务、执行本地事务、本地事务提交，给TM返回执行成功，此时TM整体提交。
如果订单创建失败了，告诉TM执行失败， TM通知两方整体回滚，库存减1的数据会根据记录的undolog日志，把减1的数据回滚到之前的状态，假如之前是100，减1之后是99，就回滚到100的状态。
