记录一次RocketMQ的生产事故

事故描述: 系统刚部署完毕, 前端还没有流量进来,就发现大量的MQ消息在消费.

事故排查:

1, 开始以为是老消息挤压, 但是公司的业务量对于RocketMQ, 完全不存在挤压的可能.

2, 然后发现历史几个月内所有的消息都被从新消费了一次, 感觉像是MQ没有拿到返回的CONSUME_SUCCESS标识而一直在重试, 但是这个也不成立, 因为队列的重试次数都是有限的, RocketMQ默认16次, 这么长时间了, 如果消费不成功, 消息早就进入死信队列了.

3, 无奈之下, 开始去一行行比对代码, 最终发现消费者的“组名”被修改了, 后经本地验证, 确实是这个造成的.

事故预防:

1, 禁止修改已有的消费者的“组名”, 如果对于某个已有的Topic要新增消费者, 那请使用相同的组名.

2,当然任何时候, 消息的消费都要实现幂等性, 这样即使消息重了也没影响.

事故疑问:

同一个Topic下的不同消费组都会得到消息, 这个可以理解, 但是新增的消费组为什么要去消费历史老的消息呢? 不应该限制一下么?

RocketMQ不做限制似乎也无可厚非, 因为对于同一个Topic, 一般情况下也不会有多个不同的消费组consumerGroup.