企业官网建设流程全解析

目录

① 导读卡片

② 背景与目标

为什么学？

学完能怎样

③ 概念与原理

什么是 OutBox 模式？

架构示意

OutBox 解决的根本问题

OutBox 不保证什么

④ 逻辑与对比：OutBox vs 其他方案

⑤ 核心详解：完整实现与代码

第一步：创建 outbox 表

第二步：业务服务写入 outbox

第三步：MessageRelay —— 独立的消息转发器

第四步：消费者（需幂等）

⑥ 案例实战：秒杀系统的库存扣减 + 事件发布

场景

不使用 OutBox 的隐患

使用 OutBox 的正确做法

完整流程图

⑦ 避坑 & 最佳实践

❌ 常见错误

✅ 最佳实践

⑧ 总结 & 路线图

记住了什么

下一步去哪

① 导读卡片

② 背景与目标

为什么学？

先看一段"看起来很合理"的代码：

@Transactional public void deductStock(Long productId, Integer count) { inventoryMapper.updateStock(productId, count); // 扣库存 mqTemplate.send("stock.deducted", productId); // 发消息 }

这段代码有两个隐藏的坑：

这两个问题本质上是一个问题：本地事务和消息发送不是一个原子操作。

OutBox（事务性发件箱）模式就是为解决这个问题而生的——用一张数据库表当"发件箱"，把这两个操作统一到同一个本地事务里。

学完能怎样

• 彻底告别"在事务里发消息"的坑

• 能独立设计一套可靠的异步事件发布方案

• 面试被问"怎么保证消息的可靠性投递"时，给出完整的方案

• 能说清楚 OutBox 和事务消息、Saga 的区别和适用场景

③ 概念与原理

什么是 OutBox 模式？

OutBox 模式（事务性发件箱，Transactional Outbox）的核心思想是：

不直接在本地事务里发消息，而是在同一个事务里写业务表和 outbox 消息表。事务提交后，由另一个独立的进程轮询 outbox 表，把消息发到真正的 MQ。

架构示意

OutBox 解决的根本问题

保证"本地事务提交"和"消息发送到 MQ"这两个操作的原子性。

• ✅ 本地事务提交 → outbox 记录落盘 → MessageRelay 一定能看到 → 重试直到发送成功

• ✅ 本地事务回滚 → outbox 记录不存在 → 不会发出脏消息

OutBox 不保证什么

OutBox 只负责"从生产者到 MQ"这一段，不保证消费者一定能消费到。

消费者能否收到并处理成功，是MQ 可靠性 + 消费者幂等 + 消费确认机制要解决的事。

④ 逻辑与对比：OutBox vs 其他方案

很多人把 OutBox 和分布式事务方案混为一谈，其实它们解决的问题不同：

关系图：

OutBox/事务消息 → 解决"单服务内部"的原子性 ↓ （是更复杂方案的基础） TCC/Saga/Seata → 解决"跨服务"的分布式事务

⑤ 核心详解：完整实现与代码

第一步：创建 outbox 表

CREATE TABLE `outbox` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `aggregate_id` VARCHAR(64) NOT NULL COMMENT '聚合根ID（如订单ID）', `event_type` VARCHAR(128) NOT NULL COMMENT '事件类型（如 OrderPaid）', `payload` JSON NOT NULL COMMENT '事件内容（JSON）', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0=待发送 1=已发送 2=发送失败', `retry_count` INT NOT NULL DEFAULT 0 COMMENT '重试次数', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), INDEX `idx_status_created` (`status`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关键设计点：

• status=0表示待发送——写入时必须是 0，不是 1

• payload存完整的 JSON 事件体，下游反序列化即可消费

• retry_count控制重试上限，防止死信无限重试

• 索引(status, created_at)让 MessageRelay 能高效扫描

第二步：业务服务写入 outbox

@Service public class InventoryService { @Autowired private InventoryMapper inventoryMapper; @Autowired private OutboxMapper outboxMapper; @Transactional public void deductStock(Long productId, Integer count, Long orderId) { // 1. 业务操作：扣减库存 inventoryMapper.deduct(productId, count); // 2. 写入 outbox 记录（同一个事务！） OutboxRecord record = new OutboxRecord(); record.setAggregateId(String.valueOf(orderId)); record.setEventType("StockDeducted"); Map<String, Object> payload = new HashMap<>(); payload.put("productId", productId); payload.put("count", count); payload.put("orderId", orderId); record.setPayload(new ObjectMapper().writeValueAsString(payload)); record.setStatus(0); // 待发送！不是 1！ record.setRetryCount(0); outboxMapper.insert(record); } }

⚠️ 关键：setStatus(0)是"待发送"，不是"已发送"！如果写成 1，MessageRelay 永远不会扫到这条记录。

第三步：MessageRelay —— 独立的消息转发器

@Component public class MessageRelay { @Autowired private OutboxMapper outboxMapper; @Autowired private RabbitTemplate rabbitTemplate; // 或 RocketMQ/RabbitMQ 等 private static final int BATCH_SIZE = 100; private static final int MAX_RETRY = 5; /** * 定时轮询（Spring @Scheduled） * 生产环境建议用独立调度任务或 CDC 方案（见最佳实践） */ @Scheduled(fixedDelay = 1000) // 每秒轮询一次 @Transactional public void relayMessages() { // 1. 批量取出待发送的消息 List<OutboxRecord> pendingRecords = outboxMapper.selectPending( BATCH_SIZE, // 每次处理 100 条 MAX_RETRY // 重试超过 5 次的跳过 ); for (OutboxRecord record : pendingRecords) { try { // 2. 发送到 MQ rabbitTemplate.convertAndSend( "stock.exchange", "stock.deducted", record.getPayload() ); // 3. 更新状态为已发送 outboxMapper.updateStatus(record.getId(), 1); } catch (Exception e) { // 4. 发送失败，增加重试次数 outboxMapper.incrementRetry(record.getId()); log.error("消息发送失败，将重试: {}", record.getId(), e); } } } }

第四步：消费者（需幂等）

@Component public class OrderServiceConsumer { @RabbitListener(queues = "stock.deducted.queue") public void handleStockDeducted(String payload) { StockDeductedEvent event = parseEvent(payload); String orderId = event.getOrderId(); // 幂等校验：防止重复消费 if (orderService.isOrderStockDeducted(orderId)) { log.info("订单库存已扣减，跳过: {}", orderId); return; } // 执行业务：更新订单状态 orderService.markStockDeducted(orderId); } }

⑥ 案例实战：秒杀系统的库存扣减 + 事件发布

场景

秒杀系统中，库存服务消费秒杀 MQ 消息后，需要：

1. 扣减库存（本地数据库）

2. 发布"库存已扣减"事件通知订单服务

不使用 OutBox 的隐患

// ❌ 错误做法 @Transactional public void handleSeckillOrder(SeckillMessage msg) { inventoryMapper.deduct(msg.getProductId(), 1); // 扣库存 // 风险：MQ 发送时网络闪断，抛出异常 → 库存扣了但消息没发出去 mqTemplate.send("stock.deducted", msg.getOrderId()); }

使用 OutBox 的正确做法

// ✅ 正确做法 @Transactional public void handleSeckillOrder(SeckillMessage msg) { // 1. 扣库存 inventoryMapper.deduct(msg.getProductId(), 1); // 2. 写 outbox——和扣库存在同一个事务里 outboxMapper.insert(new OutboxRecord( msg.getOrderId().toString(), "StockDeducted", new ObjectMapper().writeValueAsString(msg), 0, // status = 待发送 0 // retry = 0 )); // 事务提交后，MessageRelay 会可靠地把消息发出去 }

完整流程图

1. 消费秒杀 MQ 消息 │ ▼ 2. @Transactional 开始 │ ├── 2.1 扣减库存（inventory表） │ └── 2.2 插入 outbox 记录（status=0） │ ▼ 3. 事务提交 ✅ │ ▼ 4. MessageRelay（独立线程，@Scheduled 每秒跑一次） │ ├── 4.1 SELECT * FROM outbox WHERE status=0 LIMIT 100 │ ├── 4.2 发送到 MQ │ └── 4.3 UPDATE outbox SET status=1 WHERE id=? │ ▼ 5. 订单服务消费消息（幂等处理）

⑦ 避坑 & 最佳实践

❌ 常见错误

✅ 最佳实践

1. 生产环境用 CDC 替代轮询

   @Scheduled定时轮询在低并发时够用，但高并发下建议用CDC（Change Data Capture）：

   • 使用 Debezium、Canal 等工具监听 MySQL binlog

   • outbox 表写入后，binlog 实时推送变更到 MQ

   • 性能更好，延迟更低

   定时轮询 vs CDC

2. 消息幂等是必须的

   即使 OutBox 保证"至少一次投递"，消费者仍然可能收到重复消息（MQ 重试、消费者重启等），所以幂等是必须的，不是可选的。

3. 独立的 MessageRelay 进程

   不要把 MessageRelay 和业务服务放在同一个进程中。否则业务服务重启时，MessageRelay 也会暂停，消息积压。建议：

   • 独立部署的定时任务服务

   • 或单独的 CDC 消费端

4. 监控告警

   • 监控 outbox 表中status=0的记录数

   • 超过阈值（如 1000 条积压）触发告警

   • 监控retry_count超限的记录，人工介入排查

⑧ 总结 & 路线图

记住了什么

下一步去哪

• 在自己的项目里实际应用一次 OutBox 模式
• 研究 Debezium + Kafka 的 CDC 方案搭建
• 对比 RocketMQ 事务消息和 OutBox+MQ 的区别
• 尝试把 OutBox 和 Saga 模式结合起来，设计可靠的跨服务流程
• 思考：为什么说 OutBox 是"至少一次投递"（at-least-once）而非"恰好一次投递"（exactly-once）？