分布式——我理解的分布式事务

CAP理论

在分布式环境中DB也进行了分表分库，一个操作会涉及到多个分库，这个时候传统的事务实现方式显然无法起作用了。事务的理论基础也进化到了CAP，理论上一个分布式系统无法同时满足CAP中的三个需求。

很显然，在一个分布式系统中，机器宕机是一个概率很高的事情，因此P我们必须保证，AC之间的取舍就成了关键。

那为什么AC理论上无法同时达到呢？画图理解下：

若客户端同时进行姓名查询，那么无论是从库1还是库2查询，都是小明；
但是此时去修改库1里面的值，那么进行查询的话会面临两种情况：

1. 库1的值改了，但是库2的值没有改（AP without C）
   
   为了高可用放弃一致性，各个节点很可能失去联系，但仍会单独提供服务，单独提供服务的过程中很可能导致数据不一致。
   比较经典的是Redis。

2.库1的值改了，库2的值也改了（CP without A）：

要求每个机器之间强一致性，但P会导致分区之间达到一致需要时间，这种模式会导致性能受限；

既然无法同时做到，那么如何取舍呢？
取决你的业务需要。

1. 双11、双12，明明一个鞋子看库存还有2双，点击链接尝试购买提示没货了，那么这个AP without C（我宁可你点击提示没货了，无法购买，我也不想你在那等半天，才能看到页面）；
2. 比如上一篇提到了银行转账（没错，又是那个举烂的例子），选择CP without A是符合他们业务；
   举个例子，比如你在刷卡消费的时候，pos机的信号不好，输入密码后一直卡在处理中，过一会pos机器打印出来明细单子（代表扣款成功）你也收到了消费提示的短信，但是商家一直没有收到款，pos也没提示刷卡成功，明细也查不到（如果你和商家没这方面经验的话，估计就吵起来了-。 -）
   实际上这个银行对于这种场景的处理原则是：当网络不稳定的时候，要优先确保银行是百分百先收到这笔钱的（不要问为什么，就是这么…）至于这笔钱怎么来怎么去的，我不管，我先收取这笔钱。等待我有时间、网络稳定的时候再来来好好查清这笔钱的来龙去脉，然后再进行一个退款的操作。