【11来了】文章导读地址：点击查看文章导读！

消息大量堆积如何处理？

消息出现大量堆积的原因是：生产者速度 >> 消费者速度

首先需要排除 代码层面 的问题，再去对 RocketMQ 的配置做处理！

那么对于消息堆积的处理，就分为两种情况：

  • 事发时处理：

    • 扩容消费者（在消费者数量 < MessageQueue 的情况下）

      这里 增加消费者的数量 是有依据的，比如一个 Topic 下有 8 个 MessageQueue，那么最多将消费者数量增加到 8 个，因为 Topic 下一个队列只可以被同一消费者组的一个消费者消费，如果消费者的数量比 Topic 下的队列数量多的话，会有部分消费者分不到队列，因此消费者数量最多和 Topic 下的队列数量相同

    • 设置消费者的并发线程数

      提高单个消费者的消费并发线程，RocketMQ 支持批量消费消息，可以通过修改 DefaultMQPushConsumer 类中的 consumeThreadMin、consumeThreadMax 来提高单个消费者的并发能力

    • 消费者批量拉取消息

    • 新建临时 Topic 并设置 MessageQueue 数量多一点，将当前堆积信息转发到新建 Topic 中，再使用大量消费者去消费新的 Topic

  • 提前设计预防：

    • 生产者：限流，评估 Topic 峰值流量合理设计 Topic 的队列数量，添加异常监控
    • 存储端：限流，将次要消息转移
    • 消费者：降级次要消息消费，将重要消息落库（数据库或ES），再异步处理，合理根据 Topic 队列的数量和应用性能来部署消费者机器数量
    • 上线前，采用灰度发布，先灰度小范围用户进行使用，没问题之后，再全量发布

部署架构和高可用机制

部署架构分为（这里的 Master ）：

  • 单 Mastaer

    （图片来源于网络）

    • 入门学习时常使用

  • 单 Msater 单 Slave：Master 宕机后集群不可写入消息，但是可以从 Slave 读取消息

    （图片来源于网络）

    • 生产上不怎么使用，一般用作自己学习搭建主从使用

  • 多 Master ，无 Slave

    （图片来源于网络）

    • 部署方式简单，生产常用
    • 单个 Master 宕机后，不影响整体集群的读写服务，但是宕机的在这台服务中未被消费的消息，在这台服务下次重启之前无法被消费

  • 多 Master，多 Slave，异步复制

    （图片来源于网络）

    • Slave 作为备份节点，提供数据保障
    • 但是异步复制，可能丢失部分 Master 中的数据

  • 多 Msater，多 Slave，同步复制

    （图片来源于网络）

    • 同步复制中，避免了丢失 Master 数据的风险
    • 但是同步复制限制了整个集群的吞吐量

  • Dledger 模式

    • 提供了在主从模式中，Master 挂了之后，自动将 Slave 选举为 Master 的功能
    • 但是在 Dledger Group 中，至少需要 3 个 Broker 才可以完成选举