邮件标题：20260924-技术评审-营销活动中心-解决RocketMQ日志导致Pod磁盘写满被驱逐问题
邮件正文：
晓娜、建新：
已完成针对【解决 RocketMQ 日志导致 Pod 磁盘写满被驱逐问题】的技术评审，现将评审结论、风险判断及后续执行安排同步如下，便于各方对齐认知并落实执行。
项目名称： 营销活动中心
评审时间： 2026-09-24
参与评审人： 潘玉平、王建朝、张喜、张建利、马奇、宋洋
评审结果： 通过
一、技术方案背景
- 业务场景：receive 服务内两个 RocketMQ Listener 共用同一个消费组订阅不同 Topic，Broker 端按消费组匹配订阅关系时持续抛
CODE: 24告警刷屏。该告警不影响消息消费，但 rocketmq-client 默认将日志落盘到${user.home}/logs/rocketmqlogs/，日志快速增长写满容器 4G 磁盘，最终导致 receive 服务 Pod 被驱逐、节点异常。
二、技术方案要点
- 整体流程：消费组拆分（两个 Listener 各自使用与 Topic 一一绑定的独立消费组，消除订阅关系冲突）→ 新增
rmq.logback.xml覆盖 rocketmq-client 内置日志配置，客户端日志由落盘改为只输出 STDOUT → 交由腾讯云日志采集，不再占用容器磁盘。
三、决议事项
- 消费组拆分与 RocketMQ 客户端日志改 STDOUT（
rmq.logback.xml）两项改动，由 @潘玉平 负责在节后发版窗口上线（pet、sit 环境已验证通过）。 - 发版前须在 Broker 端手动创建
${rocketmq.topic.uploadInfo}-group、${rocketmq.topic.specialSign}-group两个消费组，由 @潘玉平 负责，避免上线后新 Group 未注册导致消费不到消息。 - 消费组切换须安排在凌晨 1–2 点业务低谷期执行，确认旧消费组内消息已全部消费完毕再切换，由 @潘玉平 负责，防止消息丢失。
- RocketMQ 客户端日志级别由默认 INFO 调整为 WARN（Nacos 配置
rocketmq.log.level），避免控制台输出过多无意义告警，由 @潘玉平 负责。
四、风险提示
- 消费组变更后，新 Group 从当前重置策略对应的位点开始消费（一般为最新位点）；历史堆积消息如需处理，须提前确认位点策略，否则存在消息丢失风险。
五、方案地址
https://yldc.coding.yili.com/p/sip-mac/wiki/54616