PushConsumer、PullConsumer 消费模式分析 ​

Push 和 Pull 优缺点分析 ​

Push ​

实时性高; 但增加服务端负载， 消费端能力不同， 如果Push推送过快， 消费端会出现很多问题

Pull ​

消费者从Server端拉取消息，主动权在消费者端，可控性好；但间隔时间不好设置，间隔太短，则空请求，浪费资源；间隔时间太长，则消息不能及时处理

长轮询 ​

Client 请求 Server 端也就是 Broker 的时候，Broker会保持当前连接—段时间默认是 15s，如果这段时间内有消息到达，则立刻返回给 Consumer。没消息的话超过15s，则返回 空，再进行重新请求；主动权在Consumer中，Broker即使有大量的消息 也不会主动提送 Consumer。
缺点：服务端需要保持Consumer的请求，会占用资源，需要客户端连接数可控 否则会—堆连接

PushConsumer 本质是长轮训 ​

• 系统收到消息后自动处理消息和 offset，如果有新的 Consumer 加入会自动做负载均衡。在 broker 端可以通过 longPollingEnable=true 来开启长轮询
• 消费端代码：DefaultMQPushConsumerImpl -> pullMessage -> PullCallback
• 服务端代码：broker.longpolling
• 虽然是push，但是代码里面大量使用了 pull，是因为使用长轮训方式达到 Push 效果，既有 pull 有的，又有 Push 的实时性
• 优雅关闭：主要是释放资源和保存 Offset， 调用 shutdown() 即可 ，参考 @PostConstruct、 @PreDestroy

PullConsumer需要自己维护Offset(参考官方例子) ​

• 官方例子路径: org.apache.rocketmq.example.simple.PullConsumer
• 获取 MessageQueue 遍历
• 客户维护 Offset，需用用户本地存储 Offset，存储内存、磁盘、数据库等
• 处理不同状态的消息 FOUND、NO_NEW_MSG、OFFSET_ILLRGL、 NO_MATCHED_MSG、4种状态
• 灵活性高可控性强，但是编码复杂度会高
• 优雅关闭:主要是释放资源和保存 Offset，需用程序自己保存好Offset，特别是异常处理的时候