幂等消费者

解释 at-least-once 消息系统中消费者为什么必须容忍重复交付，以及唯一约束、消息去重表、状态机和业务幂等如何避免重复副作用。

#concept #growing #backend #architecture

[!info] related notes

所属 MOC：Messaging & Queues MOC

前置：消息投递语义、接口幂等设计

具体实现：Apache Kafka、RabbitMQ

跨系统：分布式事务

[!abstract] 一句话定义幂等消费者允许同一逻辑消息被投递和处理多次，但最终业务状态与成功处理一次相同。它防的是重复副作用，不只是“看见相同 Message ID 就跳过”。

为什么重复是正常情况

Consumer updates DB successfully
→ crashes before ACK / Offset Commit
→ Broker redelivers

这是 At-least-once 的正常故障窗口。因此消息系统“没有重复”不应成为业务正确性的前提。

例如订单支付事件最终创建一条支付记录：

UNIQUE (payment_id)

重复 INSERT 由数据库约束拒绝或转为 Upsert。优点是正确性靠近最终事实。

transaction:
  insert (consumer_name, message_id) unique
  update business state
commit

如果 Message ID 已存在，说明该 Consumer 已成功处理。去重记录与业务更新必须在同一事务，否则仍有窗口。

UPDATE orders
SET status = 'paid', version = version + 1
WHERE id = ?
  AND status = 'pending'
  AND version = ?;

重复或过期事件无法再次推进状态。适合有明确业务阶段的实体。

SETNX dedup:<message_id> EX 1d

可作为性能优化，但强正确性风险包括：

关键业务应让去重和业务状态在同一权威事务边界内。

Message ID 识别一次发布；Business Key 识别同一逻辑操作。

例如 Producer 因请求重试生成两个不同 Message ID，但都代表同一个 payment_id。仅按 Message ID 去重仍会重复扣款。

Transport identity → message_id
Business identity  → payment_id / command_id / idempotency_key

高风险场景通常需要业务 Key 兜底。

两条不同事件可能都各自幂等，却不能乱序：

OrderCancelled(version 3)
OrderPaid(version 2) arrives later

如果只按 Message ID 去重，旧 Paid 仍可能覆盖新状态。还需要 Entity Version、Sequence 或合法状态转换检查。

调用支付、邮件等外部 API 时：

Producer DB
→ business update + Outbox in one transaction
→ publish

Consumer DB
→ Inbox / Processed Message + business update in one transaction

这不能消除所有重复，但把重复变成可控、可审计的正常路径。