17370845950

PostgreSQL消息系统实现幂等的核心是唯一标识+状态记录+原子操作：建msg_id唯一状态表，用INSERT ON CONFLICT和事务内校验-处理-更新保障一致性，辅以Redis缓存加速去重，幂等键须由生产者生成且反映同一业务事实。

PostgreSQL 消息系统实现幂等，核心在于“同一消息多次处理结果一致”。关键不是阻止重复投递，而是让消费端能安全重试——靠唯一标识 + 状态记录 + 原子操作。

用消息ID + 处理状态表保障唯一性

建一张轻量级的状态表，记录每条消息是否已成功处理：

• 表结构建议包含：msg_id (UUID或业务唯一键)、status (‘pending’/‘success’/‘failed’)、created_at、updated_at
• 插入时用 INSERT ... ON CONFLICT DO NOTHING（基于 msg_id 主键或唯一索引），确保首次写入成功；后续重复插入自动忽略
• 真正业务逻辑执行前，先查该 msg_id 是否 status = ‘success’；若是，直接跳过

在事务内完成“校验 + 处理 + 状态更新”

避免校验和更新之间被并发干扰，必须包裹在同一数据库事务中：

• 开启事务
• SELECT FOR UPDATE 或使用 INSERT ... ON CONFLICT DO UPDATE 尝试标记为 processing
• 执行业务逻辑（如更新订单、发通知）
• 成功则 UPDATE 状态为 ‘success’；失败则设为 ‘failed’，并记录错误上下文
• 提交或回滚事务

这样即使多个消费者同时拿到同一条消息，也只有一个能真正执行业务逻辑。

结合应用层重试与去重缓存（短期兜底）

数据库是最终一致性保障，但高频场景可叠加一层快速判断：

• 用 Redis 缓存最近 N 分钟已处理的 msg_id（TTL 设为略大于最大重试窗口，比如 5~10 分钟）
• 消费前先查 Redis，命中则直接丢弃；未命中再查 DB 状态表
• DB 更新成功后，同步写入 Redis（注意：Redis 不保证强一致，仅作性能优化，不能替代 DB 状态表）

消息体自带幂等字段，由生产者负责生成

避免依赖外部序列或时间戳，推荐由生产者生成确定性 ID：

• 用业务主键 + 时间戳 + 随机盐拼接后哈希（如 md5(order_id || '_' || event_type || '_' || created_at)）
• 或直接用 UUID v4（需确保同一业务事件不重复生成）
• 禁止用自增 ID、纯时间戳、或无业务语义的随机数作为幂等键

基本上就这些。不复杂但容易忽略的是：状态表必须有唯一约束、所有判断和更新必须在事务里闭环、以及幂等键要真正反映“同一业务事实”。