幂等表到底是个啥

说实话，hen多人一听到“幂等表”就觉得hen高级。

其实它不过是数据库里专门用来记“这条业务Yi经处理过了”的小表。

哈哈，这玩意儿本意是防止重复消费。

可是咱们往往忽略了它背后隐藏的坑。

消息重试的基本逻辑

先把大局说清楚。

生产者把消息投进去，broker 收到后会持久化。

消费者拉取后Ru果业务异常就会抛异常，broker 会把这条消息重新投递给同一个或别的消费者。

这个过程叫“重试”。

重试的前提是：消费者必须告诉 broker “我这次没成功”。

Ru果 ACK 了broker 就以为你Yi经处理完了。

幂等表怎么把重试挡住

先说个Zui常见的场景：支付成功后要创建分账单。

业务代码一般会这么写：

INSERT INTO profit_share VALUES ;
UPDATE order SET status='SHARING' WHERE order_no=? AND status='PAID';

kan起来hen安全，因为第二步只在订单是 PAID 时才会改成 SHARING。

但是Ru果第一步插入成功，第二步因为网络抖动或 DB 死锁失败了会抛异常。

这时候消费者捕获异常后会让 broker 重试。

问题来了——幂等表里Yi经有了 event_id 的记录！

下一次重试进来代码第一眼kan到“记录Yi存在”，直接返回，不再执行 UPDATE。

于是订单一直停留在 PAID 状态，分账单也卡在 PROCESSING。

这不就是所谓的“半成功”吗？

细节决定成败：状态不是二元的

hen多人把幂等表设计成只有两种状态：存在即成功，不存在即未处理。

其实我们需要geng细腻的状态机：

PROCESSING: 正在处理中，还可Neng失败。

SUCCESS: 完全成功，Ke以安全跳过重复消费。

FAIL: 明显失败，需要 尝试或人工干预。

只有当状态是 SUCCESS 时才真的Ke以 “忽略”。

如何让幂等表不挡住合法重试

思路hen简单：在记录里保存业务进度，而不是仅仅标记“Yi处理”。

CREATE TABLE t_msg_consume (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    event_id VARCHAR NOT NULL,
    consumer VARCHAR NOT NULL,
    status   VARCHAR NOT NULL DEFAULT 'PROCESSING',
    retry_cnt INT NOT NULL DEFAULT 0,
    last_error TEXT,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    UNIQUE KEY uk_event_consumer 
);

消费开始时 INSERT … ON DUPLICATE KEY UPDATE status='PROCESSING', retry_cnt=retry_cnt+1;

If status='SUCCESS' → 直接 ACK 并返回；

If status='PROCESSING' 且 超时未完成 → 抛 RetryLaterException，让 broker 再投递；

分布式锁真的Neng解决吗？别傻乎乎地把锁当唯一防线！

A、加锁只Neng防止并发冲突，不Neng解决“业务Yi半成功但记录Yi标记”的问题。

B、Redis 的 setnx kan起来像万Neng钥匙，其实也是有失效窗口的——Ru果业务崩溃而锁没释放，下次重试又卡死了。

案例拆解：从“消息Yi处理”到“业务真正完成”之间的鸿沟

ConsumeRecord rec = recordService.getOrCreate;
if ) {
    log.info;
    return;
}
if  && !rec.isTimeout) {
    // 正在处理中但还没超时交给 broker 稍后再来
    throw new RetryLaterException;
}
recordService.markProcessing;
try {
    // 关键业务
    int rows = orderMapper.updateStatus;
    if  {
        // 状态不对或者Yi经被别的线程改掉
        throw new IllegalStateException;
    }
    profitShareMapper.insert);
    recordService.markSuccess;
} catch  {
    recordService.markFail);
    throw ex;
}

为什么百度不收录？说实话，这和我们的技术文章也有点关系…

先说百度爬虫喜欢结构清晰、内容原创且包含关键词密度合适的页面。

"标题党"、大量重复代码块或者缺少自然语言解释，dou可Neng让爬虫打上 “低质量” 的标签，从而不收录。

"帮忙"一下把正文里的关键词自然散布在段落里别一次性堆砌，这样geng友好哦！

避免被百度忽视的小技巧

#1 内容原创： 不要直接复制官方文档，要用自己的话解释概念。比如上面我们用口语化描述幂等表的坑，就是好办法。

#2 合理使用 H 标签： H1一次H2/H3 用来划分层级，让爬虫geng容易抓取结构。

#3 合理插入代码块： 代码块要配文字说明，否则爬虫只kan到一堆符号，会降低可读性评分。

#4 控制关键词密度： 不要一次性塞满 “幂等”“消息重试”，自然出现几次即可。

实战指南：让幂等表既保安全，又不挡住合法重试 a) 幂等键选取要稳妥——业务语义优先级Zui高

E1: 使用全局唯一的 event_id作为主键；

E2: 若业务允许，同一事件可Neng对应多种动作，就再拼接 biz_type 或 request_no 作复合键。

b) 状态机设计——从 PROCESSING 到 SUCCESS 再到 DONE

UPDATE t_msg_consume 
SET status='SUCCESS', updated_at=NOW
WHERE event_id=? AND consumer=? AND status='PROCESSING';

SUCCESS 前一定要保证所有业务事务dou提交成功，否则就回滚并保持 PROCESSING 状态，让下次重试继续走完整流程。

b) 超时检测与补偿任务 —— 防止“卡死”状态

// 每分钟跑一次
List stuck = service.findProcessingOlderThan);
for  {
    r.setStatus;
    service.update;
}
# 后续Ke以人工或自动补偿

b) 并发窗口细化 —— 乐观锁或唯一索引双保险

UPDATE t_order 
SET status='SHARING', version=version+1 
WHERE order_no=? AND status='PAID' AND version=?;
-- 若返回受影响行数为0，则说明并发冲突或状态Yi变，需要重新读取判断。

常见误区大盘点

✔ "只要有幂等表，就不会重复消费" ——错！只有 SUCCESS 才Neng真正安全跳过。

✔ "只要加了唯一索引，就不用关心事务一致性" ——错！插入唯一索引失败只是告诉你Yi有记录，但业务可Neng还没完成。

✔ "Redis set nx 就是完美幂等" ——错！网络抖动导致 set 成功但后面的业务挂掉，这时仍然需要消费记录兜底。

✔ "把所有错误dou swallow 掉，只打印日志" ——错！错误必须回滚并让 broker 知道你没有成功 ACK，否则消息会丢失或误认为成功。

✔ "消费记录无限增长没事" ——错！定期归档或清理老旧记录，否则查询慢慢变成灾难。

小结：让幂等表发挥正Neng量，而不是成为绊脚石

A、明确区分「处理过」和「处理成功」两层含义，用状态字段区分；

B、每一步关键操作dou放在同一个事务里要么全部提交，要么全部回滚；

C、配合唯一索引防止并发冲突，但不要把唯一键当作唯一成功标识；

D、加入超时检测和补偿任务，把「卡死」情况拉出来单独处理；

E、别忘了 SEO 小技巧，让搜索引擎也爱上你的技术文章～

哈哈，kan完是不是感觉豁然开朗？ Ru果还有疑惑，随时来聊哈。 祝你玩转幂等与消息重试，两手抓，两手dou硬！

---