痛点：线上服务出现CPU使用率不均。导致部分实例持续高负载、响应变慢、资源浪费，运维定位困难，业务上线受阻。

现象

• 监控显示多个实例的CPU使用率差异明显。部分实例长期偏高，而不是偶发的CPU尖峰。
• 即使重启高CPU实例，也无法根除异常；一段时间后整体恢复均衡后又会重新出现。

根因定位

关键是找出异常实例与正常实例之间的差异，确认负载是否真正均衡。

• 接口 QPS：基本持平，没有显著差异。
• Kafka 消费 QPS：高 CPU 实例消费消息量明显更大；低 CPU 实例几乎没有消费任务。老实说，

问题根源这方面。

• Kafka Topic 被划分为若干 Partition，每个 Partition 同时只能被一个使用者实例消费。
• 当服务实例数> Partition 数时仅有部分实例拿到 Partition 并执行消费逻辑，导致 CPU 持续偏高；按理说，未分配到 Partition 的实例则相对空闲。话说回来，
• Kafka 不再产生新消息且已有消息被全部消费完后各实例 CPU 使用率会恢复均衡。

历史变更回顾

• 最初部署少量实例。仅提供 API 接口，CPU 均衡。
• 随后引入定时离线数据导出并消费的任务。Kafka Partition 数设为与实例数相同，仍未出现异常。话说回来，
• 业务增长导致实例数扩容至约 100。此时 Partition 数远小于实例数，CPU 不均现象显现。

方法

快速方案这方面。扩大 Kafka Partition 数

优点：实施迅速，可立即降低单实例负载。

缺点：

• 仅对新产生的增量消息生效，已在 Topic 中的历史消息仍受旧 Partition 限制。
• Kafka Partition 数难以随服务规模动态联动，需要手动维护。 说起来，

从彻底方案来看。拆分消费任务服务 与 业务 API 服务

• 消费任务服务保持固定规模，可按倍数配置足够的 Partition，实现每个消费实例获取均匀的分片。
• 业务 API 服务独立扩容缩容。灵活应对流量波动，不再受限于 Kafka 分片数量。

Kafka 主要概念回顾

Topic 与 Partition

A Topic 是逻辑上的消息队列，它被划分为多个 Partition。Partition 是物理存储和并行消费的最小单元，也是决定并发度的原因之一。其实，Partition 越多，并发消费能力越强。每个 Partition 内部严格有序，不同 Partition 之间无序。生产者可通过消息 Key 将同一业务 ID 的消息路由到同一 Partition，以保证顺序性。

Consumer Group 与 Rebalance

A Consumer Group 是一组协同消费的使用者实例。同一时间，同一个 Partition 只能被该 Group 内唯一一个使用者实例消费。当有使用者加入/退出或 Partition 数变化时会触发 Rebalance，将 Partition 在使用者间重新分配。

Offset 与超时风险

使用者会被踢出 Group。引发 Rebalance，从而进一步影响性能。其实，

思路要点：

• 固定时间窗口拉取所有异常实例监控指标进行横向对比；差异即为排查线索，

#1 对比请求量 & 消息流入情况

确认负载是否真的均衡，包括接口 QPS、Kafka 消费 QPS、热点 key 等。常见导致不均的原因：

• Kafka Producer Key 倾斜：热点业务 ID 导致大量消息集中到同一 Partition；
• L4/L7 负载均衡失效或 RPC 一致性哈希倾斜：`某些 IP/使用者`始终落到特定机器上。

#2 对比线程状态 & 线程池利用率

在流量相近前提下如果 CPU 差异仍然明显，则检查线程层面的问题：

• Pooled Threads 饱和：`rpc`、业务自定义线程池、数据库连接池大小不足导致阻塞堆积；
• I/O 超时或下游响应慢：`调用存储/下游程序`超时设置不合理，使得大量线程处于等待状态；
• C​AS 乐观锁自旋：`高并发更新`导致大量自旋耗 CPU；
• `同步代码块`未释放导致线程卡住。

If thread pool looks normal,turn to GC:

• 大对象频繁创建堆内存不足或老年代碎片化严重；
• -Xmx/-Xms 配置过小或 GC 日志 未开启导致难以定位。
\