关于分布式事务的一点思考

所谓事务，就是指满足ACID特性的过程，在跨库事务中，spring事务是无法满足一致性的，比如在一单商品交易中，存在多个库，多个表需要进行update操作，比如订单表，库存表，积分表等等,只有同时更新成功这三个表了才算是一个交易的完成，这个交易过程称之为分布式事务，也叫跨库事务，一般解决方案有TCC（两阶段提交协议），我之前也阐述过这个过程，也就是先预提交，比如更新三个表，再根据每个语句返回的状态决定是提交还是回滚。

CAP理论：
一致性（consistency）
可用性（Availability）
分区容错（partition-tolerance）
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以大多数情况下分区容错性是我们必须需要实现的（金融领域需要满足CA）。所以我们只能在一致性和可用性之间进行权衡，也就是选择是CP或者AP之间的选择，一致性跟可用性无法同时满足，如果要满足数据的一致性，那么就必然会牺牲可用性，比如说在转账业务中，如果一定要返回最后转账结果，那么就必须做同步了，转账过程是十分耗时的，那用户的体验性就会很差，实际上我们看到很多的转账操作都是马上返回结果的，提示转账正在处理，这只是说交易已经提交给银行处理了，但是实际上对方还没有收到钱，这里选择的就是AP，电商交易场景中，很多时候我们都是把用户体验放在第一位，那一致性问题如何解决？这又引出了另外的一个理论

BASE理论
基本可用(Basically Available)基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，核心可用就行。
软状态(Soft state)软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
最终一致(Eventually consistent)最终一致性是指系统中的所有数据经过一定时间后，最终能够达到一致的状态。

比如在商品交易系统中，我们对中间状态的处理可以异步消息机制，人工对账，定时任务对账等方法对数据进行处理，比如把支付订单交给rabbitMQ推送给银行，银行处理成功后再修改订单状态，最终实现数据的一致性