Jorgen's blog Jorgen's blog
首页
  • 平台架构
  • 混合式开发记录
  • 推送服务
  • 数据分析
  • 实时调度
  • 架构思想

    • 分布式
  • 编程框架工具

    • 编程语言
    • 框架
    • 开发工具
  • 数据存储与处理

    • 数据库
    • 大数据
  • 消息、缓存与搜索

    • 消息队列
    • 搜索与日志分析
  • 前端与跨端开发

    • 前端技术
    • Android
  • 系统与运维

    • 操作系统
    • 容器化与 DevOps
  • 物联网与安全

    • 通信协议
    • 安全
    • 云平台
newland
  • 关于我
  • 终身学习
  • 关于时间的感悟
  • 分类
  • 标签
  • 归档
GitHub (opens new window)

jorgen

Love it, make mistakes, learn, keep grinding.
首页
  • 平台架构
  • 混合式开发记录
  • 推送服务
  • 数据分析
  • 实时调度
  • 架构思想

    • 分布式
  • 编程框架工具

    • 编程语言
    • 框架
    • 开发工具
  • 数据存储与处理

    • 数据库
    • 大数据
  • 消息、缓存与搜索

    • 消息队列
    • 搜索与日志分析
  • 前端与跨端开发

    • 前端技术
    • Android
  • 系统与运维

    • 操作系统
    • 容器化与 DevOps
  • 物联网与安全

    • 通信协议
    • 安全
    • 云平台
newland
  • 关于我
  • 终身学习
  • 关于时间的感悟
  • 分类
  • 标签
  • 归档
GitHub (opens new window)
  • 消息队列
  • 主流消息队列产品对比与选型指南
  • 消息队列中的事务性消息:实现可靠业务流程的关键
  • 消息队列事务消息:分布式事务的可靠保障
  • 消息队列的事务处理:确保数据一致性的关键
  • 消息队列的事务性处理:从理论到实践
  • 消息队列的事务消息与可靠性保证
    • 前言
    • 事务消息的挑战
      • 分布式事务的困境
      • 事务消息的定义
    • 事务消息的实现方案
      • 本地消息表方案
      • RocketMQ的事务消息
      • RabbitMQ的事务消息
    • 消息可靠性保障机制
      • 消息持久化
      • 消息确认机制
      • 重试机制
      • 幂等性处理
    • 实战案例:订单系统中的事务消息
      • 场景描述
      • 解决方案
    • 总结
  • 消息队列的可靠性与持久化机制
  • 消息队列的可靠性保证:从理论到实践
  • 消息队列的可靠性保证:如何确保消息不丢失、不重复、不乱序
  • 消息队列的可靠性保证:如何确保消息不丢失、不重复
  • 消息队列的可靠性保证与事务消息
  • 消息队列的可靠性保障机制
  • 消息队列的可靠性机制:如何确保消息不丢失、不重复、不乱序
  • 消息队列的性能优化与扩展性-高并发场景下的关键考量
  • 消息队列的安全性防护-构建企业级可靠通信的关键
  • 消息队列的监控与运维-构建可观测性体系的关键
  • 消息队列的架构设计模式-构建高可用系统的关键选择
  • 消息队列的消息路由与过滤机制-构建灵活消息系统的关键
  • 消息队列的测试策略与方法论-构建可靠系统的质量保障
  • 消息队列的集群部署与高可用架构-构建企业级消息系统的基石
  • 消息队列的流处理能力-构建事件驱动架构的核心引擎
  • 消息队列的延迟与死信队列处理-构建健壮消息系统的关键机制
  • 消息队列的消息模式与通信模式-构建灵活系统的基石
  • 消息队列的消息去重与幂等性处理-构建健壮业务系统的关键保障
  • 消息队列的优先级调度机制-构建高效消息处理系统的核心策略
  • 消息队列的容错与故障恢复机制-构建高可用系统的最后一道防线
  • 消息队列的事件溯源与CQRS模式-构建可追溯系统的架构基石
  • 消息队列与微服务架构的集成-构建分布式系统的通信基石
  • 消息队列的消息序列化与数据格式选择-构建高效通信系统的关键决策
  • message_queue
Jorgen
2023-11-15
目录

消息队列的事务消息与可靠性保证

# 前言

在分布式系统中,消息队列扮演着至关重要的角色。它不仅能够解耦系统组件,提高系统的可伸缩性和可用性,还能有效削峰填谷,提升系统的稳定性。然而,在实际业务场景中,我们常常面临一个棘手的问题:如何保证消息发送方、消息队列和消息接收方之间的数据一致性?

这个问题就是今天我们要探讨的核心——事务消息与可靠性保证。🤔

在本文中,我将分享我在项目中处理事务消息的经验,以及如何通过各种机制保证消息的可靠性传递。

# 事务消息的挑战

# 分布式事务的困境

在单体应用中,我们可以通过数据库事务来保证多个操作要么全部成功,要么全部失败。但在分布式系统中,跨服务的数据一致性变得异常复杂。我第一次面对这个问题时,差点就想回退到单体架构了。

消息队列虽然可以帮助我们解耦系统,但也引入了新的挑战:

  1. 消息发送失败:业务逻辑执行成功,但消息发送失败
  2. 消息接收失败:消息成功到达队列,但消费者处理失败
  3. 重复消费:消息被多次处理,导致业务数据不一致
  4. 消息丢失:消息在传输过程中丢失

# 事务消息的定义

事务消息是指能够保证本地事务与消息发送同时成功或同时失败的消息机制。简单来说,就是"先执行业务逻辑,再发送消息",如果业务逻辑执行失败,则消息不会发送;如果消息发送失败,则回滚业务逻辑。

# 事务消息的实现方案

# 本地消息表方案

这是最经典的事务消息实现方案之一,其核心思想是通过本地数据库来记录消息状态。

提示

核心思想:将消息与业务数据放在同一个本地事务中处理,通过本地消息表记录消息状态,然后由定时任务将消息发送到消息队列。

实现步骤如下:

  1. 创建本地消息表,包含消息ID、消息内容、消息状态等字段
  2. 在业务方法中,开启本地事务
  3. 执行业务逻辑,将业务数据写入业务表
  4. 将消息信息写入本地消息表
  5. 提交本地事务
  6. 由定时任务扫描本地消息表,将状态为"待发送"的消息发送到消息队列
  7. 发送成功后,更新消息状态为"已发送"
CREATE TABLE `local_message` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `message_id` varchar(64) NOT NULL COMMENT '消息唯一标识',
  `message_body` text NOT NULL COMMENT '消息内容',
  `message_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '消息状态:0-待发送,1-已发送,2-发送失败',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_message_id` (`message_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
1
2
3
4
5
6
7
8
9
10

# RocketMQ的事务消息

RocketMQ原生支持事务消息,其实现机制更为优雅。

THEOREM

RocketMQ事务消息原理:通过两阶段提交协议,确保本地事务与消息发送的原子性。 ::具体流程如下:

  1. 发送方发送半消息(Half Message)到MQ
  2. MQ将消息标记为"暂不可消费"
  3. 发送方执行本地事务
  4. 根据本地事务执行结果,向MQ提交二次确认(Commit或Rollback)
  5. MQ收到确认后,将消息标记为可消费或删除消息
// 事务消息发送示例
TransactionMQProducer producer = new TransactionMQProducer("please_rename_unique_group_name");
producer.setNamesrvAddr("localhost:9876");
producer.setTransactionListener(new TransactionListener() {
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        // 执行本地事务
        try {
            // 业务逻辑处理...
            return LocalTransactionState.COMMIT_MESSAGE;
        } catch (Exception e) {
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    }
    
    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        // 回查本地事务状态
        // 根据业务实际情况判断是否提交或回滚
        return LocalTransactionState.COMMIT_MESSAGE;
    }
});
producer.start();

// 发送事务消息
TransactionSendResult result = producer.sendMessageInTransaction(msg, null);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# RabbitMQ的事务消息

RabbitMQ本身不直接支持事务消息,但可以通过以下方式实现:

  1. 使用发布确认(Publisher Confirms)机制
  2. 结合本地消息表实现
  3. 使用RabbitMQ的插件实现事务消息

# 消息可靠性保障机制

除了事务消息,我们还需要考虑消息在传输过程中的可靠性问题。以下是几种常见的可靠性保障机制:

# 消息持久化

提示

消息持久化是将消息存储在磁盘上,即使MQ服务器重启,消息也不会丢失。

在大多数消息队列中,可以通过以下方式实现消息持久化:

  1. 交换机持久化:确保交换机在重启后仍然存在
  2. 队列持久化:确保队列在重启后仍然存在
  3. 消息持久化:确保消息在写入磁盘后才返回确认
// RabbitMQ中设置持久化
channel.exchangeDeclare("exchange.name", "direct", true);
channel.queueDeclare("queue.name", true, false, false, null);
channel.basicPublish("exchange.name", "routing.key", 
    MessageProperties.PERSISTENT_TEXT_PLAIN, 
    message.getBytes());
1
2
3
4
5
6

# 消息确认机制

消息确认机制确保消息被正确处理:

  1. 生产者确认:确认消息已成功发送到MQ
  2. 消费者确认:确认消息已被成功处理
// RabbitMQ中开启生产者确认
channel.confirmSelect();
channel.addConfirmListener(new ConfirmListener() {
    @Override
    public void handleAck(long deliveryTag, boolean multiple) {
        // 消息成功发送到MQ
    }
    
    @Override
    public void handleNack(long deliveryTag, boolean multiple) {
        // 消息发送失败,需要重试
    }
});
1
2
3
4
5
6
7
8
9
10
11
12
13

# 重试机制

当消息处理失败时,合理的重试机制至关重要:

  1. 有限次数重试:避免无限重试导致资源浪费
  2. 指数退避:避免短时间内大量重试对系统造成冲击
  3. 死信队列:超过重试次数的消息转入死信队列,人工干预
// RabbitMQ中设置重试和死信队列
Map<String, Object> args = new HashMap<>();
args.put("x-dead-letter-exchange", "dlx.exchange");
args.put("x-dead-letter-routing-key", "dlx.routing");
args.put("x-message-ttl", 60000); // 消息过期时间

channel.queueDeclare("retry.queue", true, false, false, args);
1
2
3
4
5
6
7

# 幂等性处理

在分布式系统中,由于网络问题或消费者故障,同一条消息可能会被多次处理。因此,消费者必须具备幂等性。

常见的幂等性处理方案:

  1. 唯一ID去重:为每条消息生成唯一ID,处理前检查是否已处理过
  2. 数据库唯一约束:利用数据库的唯一约束防止重复处理
  3. 状态机模式:通过状态机控制业务流程,防止重复执行
// 幂等性处理示例
public void processMessage(Message message) {
    String messageId = message.getId();
    
    // 检查是否已处理
    if (messageRepository.existsById(messageId)) {
        return;
    }
    
    // 处理业务逻辑
    // ...
    
    // 记录处理状态
    messageRepository.save(new MessageRecord(messageId));
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 实战案例:订单系统中的事务消息

让我们通过一个订单系统的案例,来展示如何在实际应用中结合事务消息和可靠性机制。

# 场景描述

用户下单后,需要执行以下操作:

  1. 创建订单记录
  2. 扣减库存
  3. 发送订单创建消息,通知其他系统

# 解决方案

  1. 使用RocketMQ事务消息保证订单创建与消息发送的原子性
  2. 开启消息持久化防止消息丢失
  3. 配置消费者重试机制,最多重试3次,每次间隔指数增长
  4. 实现幂等性处理,防止重复下单
// 订单服务中的事务消息发送
@Service
public class OrderService {
    
    @Autowired
    private TransactionMQProducer transactionMQProducer;
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private InventoryService inventoryService;
    
    public Order createOrder(OrderDTO orderDTO) {
        // 创建订单
        Order order = new Order();
        // ...设置订单属性
        
        // 保存订单
        orderRepository.save(order);
        
        // 发送事务消息
        Message message = new Message("order-topic", "order-create", 
            JSON.toJSONString(order).getBytes());
        
        TransactionSendResult result = transactionMQProducer.sendMessageInTransaction(message, null);
        
        return order;
    }
    
    @TransactionalEventListener
    public void handleOrderCreatedEvent(OrderCreatedEvent event) {
        // 扣减库存
        inventoryService.decreaseStock(event.getProductId(), event.getQuantity());
    }
}

// 库存服务消费者
@Component
@RabbitListener(queues = "inventory.queue")
public class InventoryConsumer {
    
    @Autowired
    private InventoryRepository inventoryRepository;
    
    @Retryable(value = {Exception.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 2))
    public void handleInventoryDecrease(InventoryDecreaseMessage message) {
        // 幂等性检查
        if (inventoryRepository.existsByMessageId(message.getMessageId())) {
            return;
        }
        
        // 扣减库存逻辑
        // ...
        
        // 记录处理状态
        inventoryRepository.save(new InventoryProcessRecord(message.getMessageId()));
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

# 总结

在本文中,我们深入探讨了消息队列的事务消息与可靠性保证机制。通过本地消息表、RocketMQ事务消息等技术,我们可以有效解决分布式系统中的数据一致性问题;通过消息持久化、确认机制、重试机制和幂等性处理,我们可以确保消息的可靠传递。

在实际项目中,我们需要根据业务场景和系统特点,选择合适的技术方案。记住,没有银弹,每种方案都有其适用场景和局限性。🤷‍♂️

正如Martin Fowler所说:"任何问题都可以通过增加一个中间层来解决",而消息队列正是那个神奇的中间层,它让我们的系统更加松耦合,更加健壮。

希望本文能对你在项目中使用消息队列有所帮助。如果你有任何问题或建议,欢迎在评论区交流讨论!😊


如果你觉得这篇文章对你有帮助,别忘了点赞和关注哦!你的支持是我写作的最大动力!

#事务消息#可靠性#分布式系统
上次更新: 2026/01/28, 13:30:02
消息队列的事务性处理:从理论到实践
消息队列的可靠性与持久化机制

← 消息队列的事务性处理:从理论到实践 消息队列的可靠性与持久化机制→

最近更新
01
LLM
01-30
02
intro
01-30
03
intro
01-30
更多文章>
Theme by Vdoing | Copyright © 2019-2026 Jorgen | MIT License
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式