关于rocketmq 的坑 --MessageListenerOrderly 会导致 消费端启动后消费延迟

今天升级了一个中间件 rocketmq到4.9.4 遇到一个坑:
我在互联网场景使用 rocketmq 顺序消费, 经过多次测试后发现:
如果使用 DefaultMQPushConsumer + MessageListenerOrderly 解决有序接收消息时, 接收方.start() 以后, 有时很快可以收到数据, 大部分时候需要很长时间(超过30s)才可以收到数据, 我尝试改动所有配置都没有改善

改动配置如下:
// consumer.setPersistConsumerOffsetInterval(1000);
// consumer.setPollNameServerInterval(100);
// consumer.setConsumeMessageBatchMaxSize(1000);
// consumer.setHeartbeatBrokerInterval(1000);
// consumer.setConsumerPullTimeoutMillis(10);
// consumer.setPullInterval(100);
都无法改善延迟接收的问题

最终放弃了这种写法,我开始分析原因

假设:
发送方可以从一个或多个通道发送消息到Mq集群 , 然后消费方到Mq集群 去拉取通道中的消息,如果要实现顺序接收, 必然遇到一些技术难题:

1. 发送方如何多线程发送有序消息
2. 客户端一定要拉取所有通道数据才能组织有序的消息队列
3. 还要确保消息不遗漏

MessageListenerOrderly 实现顺序接收的逻辑无非是
收到消息以后判断是不是需要及时处理
如果不是就放回消息队列,如果是就马上处理
而且需要配合生产端顺序发送才可以实现

因为 接收端启动后 ,会延迟接收 ,所以我认为这个顺序算法和设计的有问题

现在我发现有可以 用DefaultLitePullConsumer 类,通过封装改造也可以 实现顺序消费 ,所以就不用MessageListenerOrderly 了

我重新评估了一下DefaultLitePullConsumer 和DefaultMQPushConsumer 认为

1. DefaultMQPushConsumer + MessageListenerConcurrently 可以处理 中小企业的快速且实时的消息中转(特点: 数据处理实时性,网速较快,网络稳定)因为这种推送方案 主要是解决消息的快速响应, 接收端的应答不可缺少, 所以对网络稳定和速度还是要求比较高的,在单机局域网环境测试可能没有问题,在外网环境就会发现性能一般.

2. 如果是需要处理海量的表单数据,不担心数据处理的时长,
   还是采用客户端轮询拉取比较好 ,建议使用DefaultLitePullConsumer
   轮询间隔时间可以根据客户端处理能力自定义
   比较适合大数据处理