k神吹水之 聊聊分布式事务 转载

事务就是一个会话过程当中，对上下文的影响是一致的，要么全部的更改都作了，要么全部的更变都撤销掉。就要么生，要么死。没有半死不死的中间不可预期状态。

参考下薛定谔的猫。

事务是为了保障业务数据的完整性和准确性的。

分布式事务，常见的两个处理办法就是两段式提交和补偿。
两段式提交典型的就是XA，有个事务协调器，告诉你们，来都准备好提交，你们回复，都准备好了，而后协调器告诉你们，一块儿提交，你们都提交了。
补偿比较好理解，先处理业务，而后定时或者回调里，检查状态是否是一致的，若是不一致采用某个策略，强制状态到某个结束状态（通常是失败状态），而后就世界太平了。典型的就是冲正操做。

准备好了之后，若是没有问题，收到提交，全部人都开始提交。
这个时候，好比对数据库来讲，有redo日志的。
若是某个数据库这时候宕机了，那么它重启的时候，先执行检查，也会把上一次的这些操做都提交掉的。因此各个点的数据都是一致的。

问题 1：好比 一个业务要调用不少的服务都是写操做，若是有其中一个写的服务失败了，怎么办 ？假设 4个写的吧，有2个写失败了 。

kimmking：淘宝之类的网站通常的作法是，若是4个都成功才算成功，那么此次提交时4个写都设置成一个中间状态，先允许不一致。而后4个执行完成了之后，回调或是定时任务里检查这4个数据是否是一致的，若是一致就所有置为成功状态，若是不一致就所有置为失败。

复杂的业务交互过程当中，不建议使用强一致性的分布式事务。解决分布式事务的最好办法就是不考虑分布式事务。就像刚说的问题同样，把分布式的事务过程拆解成多个中间状态，中间状态的东西不容许用户直接操做，等状态都一致成功，或者检测到不一致的时候所有失败掉。就解耦了这个强一致性的过程。

通常状况下准实时就成了。涉及到钱，有时候也能够这么搞。
淘宝几s内完整一个订单处理，不是什么问题吧。
银行也不是所有都强一致性。也会扎差，也会冲正。

特别是涉及到多个系统的时候，咱们好比买机票，支付完成之后，只支付完成状态，而后返回给用户了，咱们过几分钟再刷新页面，才会看到变成已出票，订单完成状态。
这个时候，若是咱们要求全部处理，都是强一致性的，那么久完蛋了。页面要死在那儿几分钟，才把这个事务处理完成，返回给用户。

这样就确定涉及一个问题，支付了，可是最终出票没出来。那就没办法，商量换票或退款。
淘宝的订单改为出票失败，给支付发消息通知退款。

慢的时候，有多是手工出票，这时出一张票半小时均可能，若是要求都必须强一致性的话，全部处理线程都挂在哪儿，系统早就完蛋了。

解决分布式事务的最好办法就是不考虑分布式事务。

拆分，大的业务流程，转化成几个小的业务流程，而后考虑最终一致性。

问题2：分布式事务是大家本身开发的，仍是数据库自带的？

kimmking：

一、只要一个处理逻辑能保证要么成功，要么跟什么也没作同样，都算是事务。数据库事务，MQ也有事务。
你本身甚至能够写个程序生成两个文件，要么都生成了，要么都删掉不留痕迹，这也算是事务。
二、分布式事务这一块有个XA规范，实现XA接口的事务，均可以加入到一个分布式事务中，被XA容器管理起来。

三、补偿的办法，须要具体状况具体分析，没有一个各类场合都适用的框架。