关于分布式事务的处理

通常事务解决方案：

两个阶段：将提交分红两阶段进行的目的很明确，就是尽量晚地提交事务，让事务在提交前尽量地完成全部能完成的工做，这样，最后的提交阶段将是一个耗时极短的微小操做，这种操做在一个分布式系统中失败的几率是很是小的

 

准备阶段：事务协调者(事务管理器)给每一个参与者(资源管理器)发送Prepare消息，每一个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交。

 

提交阶段：若是协调者收到了参与者的失败消息或者超时，直接给每一个参与者发送回滚(Rollback)消息；不然，发送提交(Commit)消息。

 

一阶段提交(Best Efforts 1PC模式)：从应用程序向数据库发出提交请求到数据库完成提交或回滚以后将结果返回给应用程序的过程。

 

TCC编程模式：也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操做。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，若是更新订单失败，则进入Cancel阶段，会去恢复库存。

 

通常商城分布式事务解决：

在后台管理系统中更新商品后，须要同步搜索系统、详情系统商品信息：这时候会发送MQ消息，而后在搜索系统、详情系统会订阅消息，接收到消息后执行对应操做。

在后台中，管理系统在同一个事务中执行的内容：更新商品数据，发送MQ消息；若是更新商品数据失败那么则回滚，而且不会发送MQ消息；若是发送MQ消息失败，那么也将回滚商品数据的更新。

在搜索系统、详情系统中监听MQ消息，执行对应的同步更新操做，若是消息接收失败那么ActiveMQ会从新发送6次消息，而且作了消息持久化，只要搜索系统、详情系统没有接收消息那么下次则会重发保证消息的成功传递。至于接收到消息后搜索、详情系统的执行失败是不会回滚在后台管理系统的操做的；因此在开发过程当中须要保证搜索、详情系统的执行成功率很是高。