分布式事务一致性：本地消息表设计与实践

概念

本地消息表是一种常见的解决分布式事务问题的方法。其核心思想是将分布式事务拆分成本地事务来处理，通过消息队列来保证各个本地事务的最终一致性。

实现步骤

• 创建本地消息表：在数据库中创建一个本地消息表，用于存储待发送的消息以及消息的发送状态和相关信息。表结构通常包含字段如 message_id（消息唯一标识）、message_body（消息内容）、status（消息状态，如待发送、已发送等）、create_time（消息创建时间）等；

• 业务处理与消息记录：在业务逻辑中，当需要发送消息时，首先将消息插入到本地消息表中，设置状态为待发送。然后执行业务逻辑，并将业务变更信息与消息记录插入操作放在同一个本地事务中；

• 消息发送：创建一个后台线程或定时任务，定时扫描本地消息表中状态为待发送的消息，并将这些消息发送到消息队列。在成功发送到消息队列后，将消息表中对应的状态修改为已发送；

• 消息消费：消费者监听消息队列，解析消息内容，并执行相应的业务逻辑处理。此步骤必须保证幂等性，即多次消费相同的消息不会导致数据不一致；

• 消息状态确认：当消息消费完成后，进行状态变更。如果消费失败，需要根据失败原因进行重试或人工处理；

注意事项

• 消息的幂等性：消费者必须保证接口的幂等性，以防止消息重复处理导致的数据不一致；
• 本地消息表的设计：需要考虑到消息状态、重试次数、创建时间等字段，以便实现消息的跟踪和管理；
• 定时任务和重试机制：实现定时任务或者重试机制来确保消息的可靠发送和处理；

缺点及解决方式

• 消息堆积、扫表效率慢：可以通过索引优化、分页查询、分库分表、多线程分段查询等方法提高效率；
• 定时任务扫表延迟问题：可以通过异步发送MQ改为同步调用接口、发送MQ延迟消息、分布式定时任务等方法减少延迟；

应用场景

本地消息表适用于金融、电商等领域，尤其适用于涉及多个服务交互的复杂交易场景，如资金转账、订单创建等。通过其强大功能，可以确保在分布式环境中实现事务的一致性和可靠性，有效防止数据不一致的问题。

通过上述方法，可以在不使用开源框架的情况下，利用本地消息表实现分布式事务，保证数据的一致性和系统的稳定性。

实际使用

下面是一个消息表的设计

CREATE TABLE ` mq_notify ` (
  ` id ` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  ` payment_no ` varchar(30) NOT NULL COMMENT '订单号',
  ` message ` varchar(1000) DEFAULT NULL COMMENT 'mq message',
  ` retry ` tinyint(4) NOT NULL COMMENT '发送剩余次数',
  ` status ` tinyint(4) NOT NULL COMMENT '状态',
  ` yn ` tinyint(4) NOT NULL COMMENT '是否有效',
  ` create_time ` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  ` update_time ` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  PRIMARY KEY (` id `) ,
  KEY ` idx_status ` (` status `)
) ENGINE = InnoDB COMMENT = 'mq消息表'

在插入消息表时，可以设置重试的最大次数，比如 3。

在定时任务扫描时，筛选retry > 0 且 status = 'init' 的消息记录，发送mq成功，status 更新为'finish',发送mq失败，retry 次数减一。

如果消息发送 3 次还没有成功，此时就需要报警人工介入了。