Skip to main content

ConsumerGroup 自动创建开关配置项检查

巡检规则​

本文中提及的 RocketMQ Copilot 术语是 AutoMQ Copilot for RocketMQ 的简称，均特指安托盟丘（杭州）科技有限公司面向 Apache RocketMQ 设计实现的消息队列智能辅助运维系统。

检测数据源​

ConsumerGroup 自动创建开关配置项的检测数据源是目标集群 BrokerConfig 信息，通过读取目标集群当前生效的配置，判断是否处于异常和风险的状态。

检测周期​

  • 每 10 分钟一次。
  • 不可关闭。

异常检测逻辑​


[BrokerConfig#autoCreateSubscriptionGroup](https://github.com/apache/rocketmq/blob/release-4.9.4/common/src/main/java/org/apache/rocketmq/common/BrokerConfig.java#L53C21-L53C48)= true，则产生异常事件。

事件和风险​

RocketMQ Copilot 系统巡检会对检测不通过的规则产生异常事件和风险，异常事件遵循 概述▸ 。

异常事件​

异常风险​

  • 关联的风险类型：订阅组自动创建被启用

风险分析​

如果启用 Consumer Group 自动创建开关，Broker 会在 Consumer 往 Broker 发送心跳/拉取消息时/回发消费失败消息时检查 Consumer 对应的 Consumer Group 是否已经创建，如果没有就会自动进行创建。

与 Topic 类似，启动该选项可以帮助使用者在测试环境快速上手，对于生产环境更建议禁用。对 Consumer Group 的创建做好提前规划是一个更好的实践。启动该选项时一些可能的隐患包括：

  1. 导致 Consumer Group 资源管理混乱。
  2. 每个 Consumer Group 对应的 Consumer 上线时会在 Broker 创建新的 Retry Topic。单个集群创建过多的 Retry Topic 会导致：
    1. 对应的 Consume Queue 会增多，带来更多的随机磁盘 IO，从而影响 Consume Queue 的分发效率，延长 Broker 启动以及异常宕机时的 Recovery 时间。
    2. Broker 上管理 Topic 资源的模块压力比较大。后续对 Topic 元数据的变更和向 Broker 注册路由信息都需要序列化 JSON 文件，太多的 Topic 会导致在老年代上直接分配大对象，加快 Broker FGC 的频率，出现明显的写入毛刺，影响服务质量。

运维建议​

建议 1：生产环境关闭自动创建 ConsumerGroup​

生产环境建议关闭该开关，仅在本地单机环境临时测试时开启。

建议 2：使用Admin API 集成实现自动化 ConsumerGroup 管理​

生产环境如需自动管理 ConsumerGroup 资源，可以介入 Admin API 实现 ConsumerGroup 自动化创建删除等管理。