背景： 共16个接口 系统每秒请求量 1000-3000次，接收到请求后，扔到 MQ， 消费服务消费.
16个消费者16个topic。
2023年12月 某一天，其中一个请求量大的topic 不再消费，无错误日志。
重启后发现，有一条warn日志，显示该topic出现OOM,之后再无其他日志。
梳理 RocketMQ 消费过程， 消费者是不断的从 borker 拿消息，进行消费，也就是说不管手里的消息消费完没有，只要到了设定的参数阈值，就会去获取一批消息，很显然可能是还没有消费完上一批，就拿了下一批，造成 OOM 内存撑爆啦呗。
参数：消费消息的线程程数 10
参数：每次获取数量，20条
参数：获取下一次消息的等待时间 5秒
10 * 20 = 200 条记录，而且这个接口正好是批量接口，也就是报文里是集合套集合，三层集合，而且集合的数量有可能是2000多，处理起来更慢, 数据是对接方发送过来的，数据可能不规范，导致不可控。
解决方法：
调小线程数，减半
每次获取10条
等待时间 10秒
服务稳定启动，并且消费，RocketMQ 支持 重新消费，所以把时间调回到前3天，重新消费最近3天的数据，消费做了幂等性，所以不怕数据重复消费导致的数据重复。
中间也想过其他办法，比如 把 其他的 topic 全部注释掉，只留这一个，查看日志情况，使用命令排查看服务情况，因为没有明显的错误日志，所以莫名的启动后就无反应，着实令人头疼。后来仔细看了启动日志发现这一条warn日志。
