RocketMQ系统性学习-RocketMQ高级特性之消息大量堆积处理、部署架构和高可用机制

🌈🌈🌈🌈🌈🌈🌈🌈
【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 才可以完成选举