一、背景
1.开发背景
PaaS三节点环境下，需要针对具体服务进行横向弹缩，以提高服务的处理能力。针对弹出新服务的pm-adaptor和pm-pool容器，开发人员进行了代码对应修改，以应对同一服务的多个容器对Kafka消息的处理。
2.测试背景
利用Jenkins流水线部署了Daily-smoke-CI，通过--开发分支版本编译->环境安装部署->调用云测试任务，执行自动化用例。一天执行三次，使得代码提交到开发分支后，针对系统的基本功能进行检测，及时发现引入的故障。
二、故障发现及定位
- POOL任务相关自动化用例未通过
- 进入测试环境进行排查分析
- 发现创建POOL任务时 ，POOL中的网元上的任务未能成功创建，导致用例中到下级OAM去校验网元任务时，校验失败。初步原因：POOL中网元的网元任务未正常创建。
- 在环境中手工创建POOL，并针对POOL创建测量任务，观察pm-pool的日志。针对POOL创建任务的Kafka消息正常发送，但没有收到向POOL中网元创建测量任务的Kafka消息。
- 通过读取Kafka容器的日志，发现针对网元创建任务的Kafka消息被正常消费。
- 尝试直接针对网元创建任务，任务正常下发至下级。
- 由于pm-adaptor中创建任务和pm-pool中创建任务消费的Kafka主题相同，怀疑存在相互影响，于是针对POOL创建任务同时也观察pm-adaptor的日志，最终发现，消息被pm-adaptor所消费，故障定位。
三、故障原因分析
通过分析代码，发现最近一次提交，初始化pm-adaptor和pm-pool的消费者时，将两者放入了同一消费者群组。 原始的情况，如下图
修改后将pm-adaptor和pm-pool放入了同一个消费者群组，同一个主题下的一个分区只能被一个消费者所消费，且只有被选举为Leader的分区才会被消费，其他分区作为容灾备份用。本来的消息pm-pool也可以消费到，现在消息都被pm-adaptor所消费，从而引入了故障，如下图所示：
针对故障进行再次修改，将pm-adaptor和pm-adaptor放入不同的消费者群组，二者均能消费到分区中的消息，然后再在容器内部进行自行判断是否需要自己处理，如下图所示：
