一、柔性事务

        柔性事务主要分为补偿型和通知型，补偿型事务⼜分：TCC、Saga；通知型事务分：MQ事务消息、最⼤努⼒通知型。需要注意的是：补偿型事务都是同步的，通知型事务都是异步的。

二、通知型事务

        通知型事务的主流实现是通过MQ（消息队列）来通知其他事务参与者⾃⼰ 事务的执⾏状态，引⼊MQ组件，有效的将事务参与者进⾏解耦，各参与者 都可以异步执⾏，所以通知型事务⼜被称为异步事务。

        通知型事务主要适⽤于那些需要异步更新数据，并且对数据的实时性要求 较低的场景，主要包含:异步确保型事务和最⼤努⼒通知事务两种。

• 异步确保型事务：主要适⽤于内部系统的数据最终⼀致性保障，因为内 部相对⽐较可控，如订单和购物⻋、收货与清算、⽀付与结算等等场 景；
• 最⼤努⼒通知：主要⽤于外部系统，因为外部的⽹络环境更加复杂和不 可信，所以只能尽最⼤努⼒去通知实现数据最终⼀致性，⽐如充值平台 与运营商、⽀付对接等等跨⽹络系统级别对接；
  

   

  三、异步确保型事务

        指将⼀系列同步的事务操作修改为基于消息队列异步执⾏的操作，来避免 分布式事务中同步阻塞带来的数据操作性能的下降。

    四、MQ事务消息⽅案

        基于MQ的事务消息⽅案主要依靠MQ的半消息机制来实现投递消息和参与 者⾃身本地事务的⼀致性保障。半消息机制实现原理其实借鉴的2PC的思 路，是⼆阶段提交的⼴义拓展。        主要的流程如下：

1. 事务发起方首先将半消息发送到mq队列中；
2. MQ通知发送发消息发送成功；
3. 在半消息发送成功之后，消息发送方执行本地事务；
4. 根据本地事务的结果决定之commit还是rollback；
5. 如果结果是rollback则会通知MQ丢弃该消息不进行投递，如果是commit，则通知MQ将消息进行发送给消息订阅方；
6. 订阅方根据消息进行本地事务；
7. 订阅方执行本地事务成功之后就会将该消息标记为已消费；
8. 如果在执行本地事务的过程中，执行端挂掉了或者是超时，MQ服务将会不断的轮询询问producer来获取事务的执行状态；
9. Consumer端的消费成功机制由MQ来保证；

 4.1异步确保型事务使⽤示例

        举个例⼦，假设存在业务规则：某笔订单成功后，为⽤户加⼀定的积分。在这条规则⾥，管理订单数据源的服务为事务发起⽅，管理积分数据源的 服务为事务跟随者。

        从这个过程可以看到，基于消息队列实现的事务存在以下操作：

• 订单服务创建订单，提交本地事务；
• 订单服务发送一条消息；
• 积分服务消费消息后增加积分；

        我们可以看到它的整体流程是⽐较简单的，同时业务开发⼯作量也不⼤： 

1. 编写订单服务⾥订单创建的逻辑
2. 编写积分服务⾥增加积分的逻辑；

   ---

   可以看到该事务形态过程简单，性能消耗⼩，发起⽅与跟随⽅之间的流量 峰⾕可以使⽤队列填平，同时业务开发⼯作量也基本与单机事务没有差 别，都不需要编写反向的业务逻辑过程。

   4.2 基于阿里的RocketMq实现异步确保型事务

   有⼀些第三⽅的MQ是⽀持事务消息的，这些消息队列，⽀持半消息
   机制，⽐如RocketMQ，ActiveMQ。但是有⼀些常⽤的MQ也不⽀持
   事务消息，⽐如 RabbitMQ 和 Kafka 都不⽀持。

   以阿⾥的 RocketMQ 中间件为例，其思路⼤致为：
   1. producer(本例中指A系统)发送半消息到broker，这个半消息不是说消息 内容不完整， 它包含完整的消息内容， 在producer端和普通消息的发送逻 辑⼀致；
   2. broker存储半消息，半消息存储逻辑与普通消息⼀致，只是属性有所不 同，topic是固定的RMQ_SYS_TRANS_HALF_TOPIC，queueId也是固定 为0，这个tiopic中的消息对消费者是不可⻅的，所以⾥⾯的消息永远不会 被消费。这就保证了在半消息提交成功之前，消费者是消费不到这个半消 息的；
   3. broker端半消息存储成功并返回后，A系统执⾏本地事务，并根据本地事 务的执⾏结果来决定半消息的提交状态为提交或者回滚；
       
      今天先写到这把，1024程序员节日感觉csdn出bug了。。。。。。改天再补上后续内容