12 个“大 TPS 规模效应问题”——现象 + 排查 + 常见解决

本文结合实际大型 IAM（认证授权）系统的性能经验，总结了 高 TPS 环境下常见的 12 类"规模效应"性能问题

并给出每类问题的：
现象 → 排查手段 → 常用解决方案

---

🧠 什么是"大 TPS 规模效应"？

小环境（单 pod、小 TPS）能暴露大部分逻辑问题

但 高 TPS（如 3k～20k TPS） 会触发一些 只有大规模时才会出现的系统级问题：

• 非线性放大

• 队列堆积

• 网络拥塞

• 分布式一致性

• 存储写压力

• LB 不均衡

• GC 行为变化

这些是传统小规模压测无法完全复现的。

---

🏆 目录

1. LB / Sidecar / 多 Pod 负载不均

2. TCP backlog / SYN 队列溢出

3. Kafka backlog / Cassandra 写入压力

4. Redis 单线程 / 分片热点问题

5. Oracle 性能（CBO、I/O、索引衰减）

6. GC 在高 TPS 下的特殊行为

7. 线程池饱和与队列堆积（非线性）

8. K8s 调度延迟 + Pod 重建

9. 多跳网络导致的累积延迟

10. 分布式缓存一致性 & 锁竞争

11. 容量上限附近的断崖式崩溃

12. 级联超时 / 雪崩效应

---

🎯 1. LB / Sidecar / 多 Pod 负载不均

📌 现象

• 明明有 10 个 pod，但只有其中 2 个 CPU 打满

• 部分实例 RT 比其他实例高 3～5 倍

• 错误率集中在某 1～2 个实例

🔍 排查

• 查看每个实例 QPS、RT、CPU、内存差异

• 检查 LB 策略：Round robin / Hash / Sticky session

• 查看 Istio / Envoy 的 metrics

🛠 解决方案

• 去掉不必要的 session 粘连

• 使用更均匀的 LB 策略（least request）

• 增加副本数量分摊流量

---

🎯 2. TCP backlog / SYN 队列溢出

📌 现象

• 客户端偶发连接超时

• 服务端 CPU 不高，但连接被拒绝

• netstat 显示大量 SYN_RECV

🔍 排查

• 查看 ss -s、netstat -s 中 TCP 队列

• 查看 somaxconn 和 tcp_max_syn_backlog

• 查看是否短连接太多

🛠 解决方案

• 增大 backlog

• 使用连接池 / keep-alive

• 增加实例数量分散连接压力

---

🎯 3. Kafka backlog / Cassandra 写压力

📌 现象

Kafka：

• consumer lag 持续上升

• broker 堆积消息

Cassandra：

• compaction 时间很长

• read/write latency 飙升

🔍 排查

• 查看 Kafka consumer lag

• 查看 Cassandra 的 read/write 统计、SSTable 数量

• 查看磁盘 I/O、队列长度

🛠 解决方案

Kafka：

• 增加 partition / consumer 数

• 优化 producer batch

Cassandra：

• 优化表 schema、减少热点分区

• 调整副本数和一致性等级

---

🎯 4. Redis 单线程瓶颈 / 热点 key / 分片不均

📌 现象

• 某个 Redis 实例 CPU 单核打满

• Redis 响应时间偶发飙升

• 部分 key 明显比其他 key 慢

🔍 排查

• 慢日志（slowlog）

• INFO monitor

• 查看 key 热点分布

🛠 解决方案

• 拆热点 key（前缀分桶）

• 使用 Redis Cluster 分片

• 避免大 pipeline/batch 一次塞太多

---

🎯 5. Oracle 在大数据量下的性能劣化（非常典型）

📌 现象

• 测试环境很快，生产环境极慢

• AWR 中 top SQL 占据大量 DB Time

• 等待事件上升：db file sequential read、log file sync

🔍 排查

• 对比执行计划

• 查看索引是否失效

• 查看统计信息是否过期

• AWR → Top Waits / Top SQL

🛠 解决方案

• 给热点 SQL 加索引

• 更新统计信息，让 CBO 选择更优计划

• 表分区 / 数据归档

• 对热点查询加缓存层

---

🎯 6. GC 在高 TPS 下对象分配速率暴涨

📌 现象

• 高 TPS 时 GC 次数、Pause 时间显著增加

• Old 区晋升频繁

• CPU 很多花在 GC 上

🔍 排查

• 解析 GC 日志（G1、CMS）

• 使用 JFR 看对象分配速率

• 查看 Survivor 区压力

🛠 解决方案

• 减少短生命周期对象创建

• 调整 heap / region / pause 目标

• 减少 JSON 序列化 / 拷贝

• 避免在高频路径上创建大对象

---

🎯 7. 线程池饱和 + 队列放大效应

📌 现象

• RT 一开始稳定

• 到某个点后 RT 急剧上升

• 线程池 activeCount 满，queue 堆积

• 错误率飙升

🔍 排查

• 看线程池各项指标

• 看排队时间（从提交到执行）

• 查看下游调用耗时

🛠 解决方案

• 合理配置线程池

• 拒绝策略替代无限排队

• 拆分耗时任务

• 加限流 / 熔断 / 降级

---

🎯 8. K8s 调度问题（Pod 重调度 / Evicted / CPU Throttling）

📌 现象

• RT 偶发变大

• Pod 有重建、驱逐

• 容器 CPU throttle 时间急剧增加

🔍 排查

• 看 kubectl describe pod 的事件

• 看节点 CPU/内存压力

• 查看 cgroup metrics：throttled_periods

🛠 解决方案

• 调整 CPU request/limit

• 给关键服务更高 QoS（Guaranteed）

• 避免在一个 node 上塞太多 pod

---

🎯 9. 多跳（multi-hop）网络导致的延迟累积

📌 现象

• 单接口 RT 看似还好，但在长链路中 P99 偏高

• 不同链路差异明显

• 跨 region / zone 更明显

🔍 排查

• 用 trace（Jaeger / Zipkin）看全链路图

• 各 hop 的 RT / 网络延迟

🛠 解决方案

• 减少链路层级

• 批量接口

• 就近访问（减少跨区调用）

---

🎯 10. 多实例缓存一致性 / 分布式锁竞争

📌 现象

• 数据偶尔不一致

• 分布式锁等待变长

• 多实例间更新不一致

🔍 排查

• 看缓存 key 更新策略

• 分析分布式锁实现

• 查看热点 key 频率

🛠 解决方案

• 用 redisson / ZK 实现成熟锁

• 缩小热点 key

• 减少分布式写入

---

🎯 11. 接近容量上限时的断崖式性能下降

📌 现象

• QPS 提升到某一点后，RT 很快从 100ms → 200ms → 2s

• 错误率陡升

• 系统进入排队风暴（queueing storm）

🔍 排查

• QPS vs RT 曲线

• 找出转折点、瓶颈组件（线程池/Redis/DB/CPU）

🛠 解决方案

• 保持负载在"安全水位"（例如 70% 极限值）

• 实施限流、降级、快速失败

• 扩容瓶颈组件

---

🎯 12. 级联超时 / 雪崩效应（非常典型）

📌 现象

• 下游某个 API 慢 → 上游都慢

• 线程池被全部占满 → 新请求排队

• 大面积 500/超时

🔍 排查

• 看分布式 tracing

• 确认最先变慢的服务

• 检查上游线程池占用情况

🛠 解决方案

• 加熔断（Circuit Breaker）

• 限流 token bucket

• 设置合理的超时 + 重试策略

• 对关键链路做隔离

---

📘 总结

大 TPS 不只是"请求变多"这么简单，它带来的规模效应会影响：

• 负载均衡

• 网络堆积

• 分布式存储

• 数据库

• JVM

• 线程模型

• 缓存

• 容器平台

• 调用链路

理解这 12 类问题是成为高级性能工程师的关键。