跑到第250条时消费者崩了，对账下来500条里少了一条
上了队列之后最先遇到的不是性能问题，是不确定一条消息到底有没有被处理。这篇把丢消息、重复消费、消息卡住、重试风暴、坏消息占位这五件事逐个拆开，每一件都配一套可以自己复现的对账办法：造一批消息、故意杀掉消费者、再看三个数加起来等不等于总数。文中还回答了幂等标识该拿什么当键、有效期该设多长、退避为什么必须加抖动，以及发版时队列里那些旧格式消息该怎么处理。
标签
消息队列
保哥笔记 消息队列 标签下共 2 篇文章合集，含《跑到第250条时消费者崩了，对账下来500条里少了一》《下单接口里那行发邮件的代码，把24毫秒的响应拖成了9》等，与 服务器运维、异步任务、任务队列 主题密切相关，覆盖 SEO/GEO 实战角度的深度解析与可落地方案。
-
-
下单接口里那行发邮件的代码，把24毫秒的响应拖成了924毫秒
很多团队在还不需要队列的时候就把它引进来了，也有团队该上的时候一直不上。这篇不做选型对比，只回答一个问题：手上这件事到底该留在请求路径里、交给定时任务、写进一张数据库表，还是真的需要一个独立的队列组件。文中给出四条判据、三个阶段的演进路线、一张任务表的字段清单，以及上线之后必须补的三个观测指标。另外澄清两个常见误解——并发调用不等于异步，队列也不会让事情完成得更快，它只是把等待从用户身上挪走。
