背景
突然收到电话告警，RocketMQ集群的cpu被打到90%以上，马上打开监控系统查看下，cpu直线上升
硬盘I/O也在狂飙
集群中只有两个节点的cpu暴涨，通过集群信息查下，发现是集群中的两个从节点的cpu暴涨。(我们的集群是4主4从，2个节点部署在同一台机器上，为了省钱)。虽然从节点cpu暴涨不影响整个集群的正常tps写入，还得要清楚是啥原因造成的cpu暴涨。找到对应的集群业务负责人，询问有什么操作没有，说是有消息积压了几千万，重新消费了。
原因
如果消息积压了，消费者重新消费消息时，会从RocketMQ集群中的从节点上拉取消息。这是因为RocketMQ采用主从架构，并且从节点负责提供消息的存储和读取服务。当主节点的消息积压造成消费者无法快速处理消息时，RocketMQ的负载均衡策略会自动将从节点作为备用提供消息服务，以提高消费效率。
具体地说，当消费者处理消息的速度无法跟上消息的产生速度时，消息就会积压，即处于等待消费状态。当等待时间超过一定的时间后，RocketMQ就会将这些积压的消息向从节点进行转移，以便消费者可以从从节点上重新消费它们。这样可以使消费者能够尽快处理消息，从而保证消息的快速处理。
需要注意的是，从节点提供的服务仅限于消息的读取和存储，主节点仍然负责消息的写入和同步。如果主节点宕机，则从节点仍然需要等待主节点的恢复以处理任何修改或新增操作。因此，在使用RocketMQ时，应该注意保持主节点的稳定性，以避免消息服务的中断。
处理方法
只能让业务暂停止消费，防止出现从节点被挂的风险，消费者正常下线后，从节点的水平也慢慢恢复正常。
