RocketMQ-最佳实践&积压消息如何快速处理？

（1）合理分配Topic、Tag

一个应用尽可能用一个Topic，消息子类型用tags标识.

（2）使用Key加快消息索引

Key可以参与消息过滤，建议每个消息key分配一个业务层面的唯一标识码。可以配合Tag进行更精确的消息过滤，Broker端会为每个消息创建一个哈希索引。

（3）关注错误消息重试

• 消费者端如果处理消息失败，Broker会重新投送消息。重试时，RocketMQ会为每个消费者组创建一个对应的重试队列。

• 超过重试次数，消息将不再投递，转为进入死信队列。重试次数默认16次，可以定制，时间间隔均为2小时。

• 消息最大重试次数的设置对相同GroupID下的所有Consumer实例有效，最后启动的Consumer会覆盖之前启动的Consumer的配置。

（4）手动处理死信队列

要处理死信队列，就得先了解什么是死信队列？有什么特征？

• 一个死信队列对应一个ConsumeGroup，不是对应某个消费者实例。如果一个ConsumeGroup没有产生死信队列，RocketMQ就不会为它创建相应的死信队列。

• 一个死信队列包含这个ConsumeGroup里的所有死信消息，不区分该消息属于哪个Topic。死信队列中的消息不再会被消费者正常消费。

• 死信队列的有效期跟正常消息相同，默认3天，对应broker.conf中的fileReservedTime属性。超过有效期的消息都会被删除，不管消息是否消费过。

（5）消费者端进行幂等控制

消息幂等有三种实现语义

• at most once 最多一次： 每条消息最多只会被消费一次，用异步发送、sendOneWay等方式可以保证。

• at least once 至少一次：  每条消息至少会被消费一次，同步发送、事务消息等方式能够保证。

• exactly once 刚刚好一次： 每条消息都只会被消费一次，需要由业务系统自行保证消息的幂等性。

消息重复的3个场景

① 发送时

• 当一条消息已经被成功发送到服务端，并完成持久化，

• 出现网络闪断或客户端宕机，导致服务端对客户端应答失败，

• 生产者意识到消息发送失败并尝试再次发送消息，

• 消费者会收到两条相同内容和Message ID的消息。

② 投递时

• 消息已经投递到消费者，并完成业务处理，

• 当客户端给服务端反馈应答时网络闪断，

• 为了保证消息至少被消费一次，服务端会在网络恢复后，再次尝试投递已被处理过的消息，

• 消费者会收到两条相同内容和Message ID的消息。

③ 负载均衡时

• 当Broker或客户端重启、扩容或缩容时，

• 会触发负载均衡，消费者可能会收到重复消息。

处理方式或方案

需要在业务上自行来保证消息消费的幂等性，使用业务唯一标识作为消息的Key进行传递。

————我是分割线————

关于积压消息如何快速处理问题？第一步确认是否有消息积压？

正常情况下，消息生产速度和消费速度整体上是平衡的。如果部分消费者系统出现故障，会造成大量的消息积累。这类问题通常在实际工作中会出现得比较隐蔽。还有一种情况就是业务突然爆发性增长，也会出现消息积压。

有三种方式可以查看

（1）最简单的方式，可以通过web控制台，就能直接看到消息的积压情况。就是RocketMQ Dashboard的界面，如何搭建可以参考之前写过的文章《RocketMQ-管控利器【Dashboard 2.0】服务搭建》。

（2）通过mqadmin指令在后台检查各个Topic的消息延迟情况。

（3）查看 ${storePathRootDir}/config 目录下落地一系列的json文件，可以用来跟踪消息积压情况。

对于积压消息的处理，就看消息是否重要了。如果不重要，可以在管理控制台直接使用跳过堆积的功能；如果很重要，且是消费者端处理能力不够，造成消息大量积压，则需要设计一套消息转移方案来处理。

具体要采用哪种方案，要看Topic下的MessageQueue配置是否足够多？

2.1、Topic下的MessageQueue配置足够多

• 每个Consumer实际上会分配多个MessageQueue消费，可以通过增加Consumer的服务节点数量加快消息的消费。

• 等积压消息消费完了，再恢复成正常情况。

• 最极限的情况是把Consumer的节点个数设置成跟MessageQueue的个数相同。

2.2、Topic下的MessageQueue配置不够

• 可以创建一个新的Topic，配置足够多的MessageQueue。

• 把所有消费者节点的目标Topic转向新的Topic，紧急上线一组新的消费者，只负责消费旧Topic的消息，转储到新的Topic。

• 在新的Topic上，可以通过增加消费者个数提高消费速度，之后再根据情况恢复成正常情况。

敬请关注我的公众号：大象只为你，持续更新技术知识......

原文始发于微信公众号（大象只为你）：RocketMQ-最佳实践&积压消息如何快速处理？