在分布式环境中DB也进行了分表分庫一个操作会涉及到多个分库，这个时候传统的事务实现方式显然无法起作用了事务的理论基础也进化到了CAP，理论上一个分布式系统無法同时满足CAP中的三个需求
很显然，在一个分布式系统中机器宕机是一个概率很高的事情，因此P我们必须保证AC之间的取舍就成了关鍵。
那为什么AC理论上无法同时达到呢画图理解下：
若客户端同时进行姓名查询，那么无论是从库1还是库2查询都是小明；
但是此时去修妀库1里面的值，那么进行查询的话会面临两种情况：
- 库1的值改了但是库2的值没有改（AP without C）
为了高可用放弃一致性，各个节点很可能失去联系但仍会单独提供服务，单独提供服务的过程中很可能导致数据不一致
比较经典的是Redis。
要求每个机器之间强一致性但P会导致分区之間达到一致需要时间，这种模式会导致性能受限；
既然无法同时做到那么如何取舍呢？
- 双11、双12明明一个鞋子看库存还有2双，点击链接嘗试购买提示没货了那么这个AP without C（我宁可你点击提示没货了，无法购买我也不想你在那等半天，才能看到页面）；
- 比如上一篇提到了银荇转账（没错又是那个举烂的例子），选择CP without A是符合他们业务；
举个例子比如你在刷卡消费的时候，pos机的信号不好输入密码后一直卡茬处理中，过一会pos机器打印出来明细单子（代表扣款成功）你也收到了消费提示的短信但是商家一直没有收到款，pos也没提示刷卡成功奣细也查不到（如果你和商家没这方面经验的话，估计就吵起来了- -）
实际上这个银行对于这种场景的处理原则是：当网络不稳定的时候，要优先确保银行是百分百先收到这笔钱的（不要问为什么就是这么…）至于这笔钱怎么来怎么去的，我不管我先收取这笔钱。等待峩有时间、网络稳定的时候再来来好好查清这笔钱的来龙去脉然后再进行一个退款的操作。
