RocketMQ事务消息和普通消息有什么区别？

一、核心定义与设计目标

二、核心区别对比（关键维度）

三、关键差异拆解（结合实操）

1. 消息发送流程差异

普通消息（同步发送）：

// 普通消息发送（一行代码完成）
rocketMQTemplate.syncSend("normal_topic", "普通消息内容");
// 流程：发送 → Broker 持久化 → 立即投递消费者

事务消息：

// 事务消息发送（必须绑定本地事务监听器）
rocketMQTemplate.sendMessageInTransaction("tx_topic", txMessage, null);
// 流程：
// 1. 发送半消息（Broker 暂存，不可投递）；
// 2. 执行本地事务（如扣减库存）；
// 3. 提交/回滚半消息（消费者才会收到/收不到）；
// 4. 异常则触发 Broker 回查生产者。

2. 异常场景处理差异

场景 1：生产者发送消息后，本地事务执行失败

• 普通消息：消息已发送到 Broker，消费者会收到消息（导致「消息发送成功但本地事务失败」的数据不一致）；
• 事务消息：生产者回滚「半消息」，Broker 删除消息，消费者收不到（保证一致性）。

场景 2：本地事务执行成功，但生产者宕机（未发送提交指令）

• 普通消息：无回查机制，若消息已发送则消费者收到，未发送则失败；
• 事务消息：Broker 定时触发「事务回查」，生产者回查本地事务状态后，提交消息（最终消费者仍能收到）。

3. 代码层面核心差异

四、典型使用场景对比

普通消息适用场景：

• 系统通知：用户注册后发送欢迎短信（即使短信发送失败，不影响注册核心流程）；
• 日志采集：应用日志异步发送到日志平台（允许少量丢失，追求高性能）；
• 缓存更新：数据库变更后发送消息更新 Redis（即使更新失败，可通过定时任务补偿）。

事务消息适用场景：

• 电商订单：订单支付成功（本地事务：扣减用户余额）→ 发送消息创建物流单（必须保证「扣余额成功才发消息」）；
• 资金转账：A 账户扣款（本地事务）→ 发送消息给 B 账户加款（必须保证「扣款成功才发消息」）；
• 库存扣减：秒杀下单（本地事务：扣减库存）→ 发送消息创建订单（必须保证「扣库存成功才发消息」）。

五、核心总结

实操建议

1. 若业务仅需「发消息、收消息」，无本地事务关联 → 用普通消息（高性能、简单）；
2. 若业务需要「本地事务成功才发消息」，且需保证数据一致性 → 用事务消息（牺牲少量性能换一致性）；
3. 事务消息必须配合「幂等消费 + 事务状态持久化（如数据库）」，否则回查机制无法生效。