摘要：在微服务架构中，事件驱动设计已成为服务间通信的核心范式。设想这样一个场景：用户完成订单支付后，订单服务需要触发库存扣减、物流通知等一系列后续操作。然而实际部署中常出现以下现象：
在微服务架构中，事件驱动设计已成为服务间通信的核心范式。设想这样一个场景：用户完成订单支付后，订单服务需要触发库存扣减、物流通知等一系列后续操作。然而实际部署中常出现以下现象：
数据库记录已提交，扣款成功消息队列中却未捕获到对应的事件消息下游服务因收不到事件而无法执行后续逻辑这种 “业务操作成功但消息丢失” 的问题，暴露了分布式系统中一个常见误区：过度关注消息发送端的可靠性（发件箱模式），却忽视了接收端的可靠处理（收件箱模式）。本文将从架构设计角度解析如何通过两种模式的结合，实现 “至少一次传递 + 幂等处理” 的可靠消息通信。
传递保证核心特性典型场景实现复杂度最多一次可能丢失，绝不重复日志收集、监控指标上报低至少一次确保送达，允许重复订单支付、库存扣减中恰好一次精准投递，无丢失无重复金融交易、事务性操作极高由于分布式环境下网络分区、节点故障等不确定性，“恰好一次” 在工程实践中极难实现。因此，业界普遍采用 “至少一次传递 + 幂等性设计” 的组合方案，在可靠性和复杂性之间取得平衡。发件箱与收件箱模式正是这一方案的核心实现载体。
发件箱模式通过数据库事务保证业务操作与事件发布的原子性，确保 “要么都成功，要么都失败”。
核心实现流程
关键技术点
事务一致性：业务表与发件箱表的写入必须在同一事务中，确保事件仅在业务操作成功后入队事件序列化：发件箱表需包含事件 ID、类型、payload、状态（待发送 / 已发送）等字段异步投递：通过独立线程或定时任务轮询发件箱，避免阻塞业务主线程典型表结构示例
CREATE TABLE orders ( id UUID PRIMARY KEY, user_id UUID, amount DECIMAL(10, 2), status VARCHAR(50));CREATE TABLE outbox_events ( event_id UUID PRIMARY KEY, order_id UUID, event_type VARCHAR(50), payload JSON, status VARCHAR(50) DEFAULT 'PENDING', created_at TIMESTAMP);局限性
仅保障发送端可靠性：无法解决接收端处理失败或重复消费问题事件积压风险：轮询效率低时可能导致发件箱表堆积大量待发送事件收件箱模式通过幂等性设计确保消息仅被正确处理一次，即使面对重复投递或节点崩溃也能保证一致性。
核心实现流程
关键技术点
幂等性校验：通过唯一消息 ID（如 message_id）作为收件箱表的唯一索引，避免重复处理事务边界：收件箱记录写入与业务逻辑处理必须在同一事务中，确保原子性状态机设计：可扩展状态字段（如 PROCESSING/COMPLETED）处理并发场景下的竞争条件典型表结构示例
CREATE TABLE inbox_events ( message_id UUID PRIMARY KEY, event_type VARCHAR(50), payload JSON, processing_status VARCHAR(50) DEFAULT 'UNPROCESSED', processed_at TIMESTAMP);核心优势
防重复处理：唯一索引确保相同消息仅被处理一次故障恢复：即使处理过程中服务崩溃，重启后通过收件箱状态可恢复处理将发件箱与收件箱模式结合，可实现完整的可靠消息链路：
全流程时序图
关键协同点
事件溯源：发件箱的 event_id 需与收件箱的 message_id 保持一致，作为跨服务关联标识重试机制：消息代理需支持失败重试，配合收件箱的幂等性实现至少一次传递最终一致性：允许短暂的不一致，但通过重试和补偿机制保证最终状态正确Stripe 在支付回调中使用idempotency_key作为消息唯一标识：
客户端生成唯一键并随请求发送服务端通过收件箱表校验，重复请求直接返回历史结果确保同一支付请求无论重试多少次，仅执行一次扣款分布式系统的本质是处理不确定性，而发件箱与收件箱模式正是应对这种不确定性的有效工具。通过将 “至少一次传递” 与 “幂等性处理” 相结合，我们得以在复杂环境中构建可靠的事件驱动架构。记住：在消息通信的两端，发送方的 “尽责” 需要接收方的 “克制” 来配合 —— 每个发件箱都需要一个收件箱，才能完成这场可靠性的双人舞。
“设计系统时，请始终假设消息会丢失或重复 —— 因为它们一定会。”
—— 分布式系统设计黄金法则
来源：SuperOps
