详解三种主流分布式事务方案的优劣(3)

1)实现思路：

• 主动方应用系统通过业务操作完成业务数据的操作，在准备发送消息的时候将消息存储在主动方应用系统一份，另一份发送到实时消息服务;
• 被动方应用系统监听实时消息系统中的消息，当被动方完成消息处理后通过调用主动方接口完成消息确认;
• 主动方接收到消息确认以后删除消息数据;
• 通过消息查询服务查询到消息被接收之后再规定的时间内没有返回ACK确认消息就通过消息恢复系统重新发送消息。

2)优点：

• 消息的时效性比较高;
• 从应用设计的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖;
• 方案轻量级，容易实现。

3)缺点：

• 与具体的业务场景绑定，耦合性强，不可以共用;
• 消息数据与业务数据同步，占用业务系统资源;
• 业务系统在使用关系型数据库的情况下消息服务性能会受到关系型数据库的并发性能限制。

独立消息服务方案

1)实现思路：

预发送消息：主动方应用系统预发送消息，由消息服务子系统存储消息，如果存储失败，那么也就无法进行业务操作。如果返回存储成功，然后执行业务操作。

执行业务操作：执行业务操作如果成功的时候，将业务操作执行成功的状态发送到消息服务子系统。消息服务子系统修改消息的标识为“可发送”状态。

发送消息到实时消息服务：当消息的状态发生改变的时候，立刻将消息发送到实时消息服务中。接下来，消息将会被消息业务的消费端监听到，然后被消费。

消息状态子系统：相当于定时任务系统，在消息服务子系统中定时查找确认超时的消息，在主动方应用系统中也去定时查找没有处理成功的任务，进行相应的处理。

消息消费：当消息被消费的时候，向实时消息服务发送ACK，然后实时消息服务删除消息。同时调用消息服务子系统修改消息为“被消费”状态。

消息恢复子系统：当消费方返回消息的时候，由于网络中断等其他原因导致消息没有及时确认，那么需要消息恢复子系统定时查找出在消息服务子系统中没有确认的消息。将没有被确认的消息放到实时消息服务中，进行重做，因为被动方应用系统的接口是幂等的。

2)优点：

消息服务独立部署，独立维护，独立伸缩。

消息存储可以按需选择不同的数据库来集成实现。

消息服务可以被相同的的使用场景使用，降低重复建设服务的成本。

从分布式服务应用设计开发角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。

降低了业务系统与消息系统之间的耦合，有利于系统的扩展维护。

3)缺点：

一次消息发送需要两次请求;

主动方应用系统需要实现业务操作状态的校验与查询接口。

消息服务子系统的设计实现

示例消息数据表：

（编辑：ASP站长网）