5.4 性能优化：测量、定位、动手

5.4 性能优化：测量、定位、动手

本节摘要：性能优化的正确顺序是先测量基线、再分段定位、最后动手调参——反过来做的团队通常把 prefetch 和队列数翻来覆去地调，收益为零。本节给出瓶颈热区地图、三段定位法与参数清单，并用两个真实案例演示"瓶颈从来不在你以为的地方"。

整理进行到性能层。这个话题最容易写成参数大全，但参数大全式调优的效果，用团队里流传的话说就是"抽奖"。本节把随机抽奖变成工程流程。

先看热区：慢到底慢在哪

图 15 性能瓶颈热区地图

热区地图的用法配合三段定位法：先分段压测出发布极限、消费极限、端到端实际值三个数，端到端贴着哪段极限，就进哪段找热区。没有这三个数就动手调参，等于蒙眼修表。

完整演练一：发布吞吐从八百到两万

背景：某埋点上报链路，发布吞吐实测每秒八百条，业务目标两万。团队第一反应是"加机器换 SSD"。

操作：按三段定位法先压测。只压发布段，发现瓶颈就在发布侧——代码里每条消息新建连接并同步确认：

# 反面教材：每消息一连接一确认
def publish_slow(event: dict):
    conn = pika.BlockingConnection(pika.ConnectionParameters(host="mq1"))
    ch = conn.channel()
    ch.confirm_delivery()
    ch.basic_publish(exchange="metrics", routing_key="logs",
                     body=json.dumps(event).encode())
    conn.close()          # 握手加确认加断开，全部计入单条成本
​

改造为连接复用加批量确认，复用 2.5 节的单例连接骨架，确认改异步批量：

# 改造版：长连接加异步批量确认
channel = shared_connection.channel()
channel.confirm_delivery()          # 切到异步确认模式

def publish_fast(events: list):
    for event in events:
        channel.basic_publish(
            exchange="metrics", routing_key="logs",
            body=json.dumps(event).encode(),
            properties=pika.BasicProperties(delivery_mode=2))
    channel.waitForConfirms()       # 一批一等待，往返成本摊到整批
​

结果：发布吞吐从每秒八百涨到两万三，没加一台机器。解读：八百到两万的差距里，连接握手占了六成，逐条确认往返占了三成半——参数（内存水位、队列类型）一个没动。这正是本节开头的判断：性能问题多数在代码与模式。热区一与热区二一次清掉，是本案例的全部。

完整演练二：消费吞吐的 prefetch 谜题

背景：另一条链路反着来：发布侧通畅，消费跟不上，队列每天涨两百万。团队把 prefetch 从 1 调到 500，毫无起色。

操作：三段定位。消费极限压测时发现诡异现象：prefetch 调大后单消费者吞吐不升反降，消费者 CPU 却很闲。用管理界面 Connections 页观察，发现问题：消费回调里每次都要同步调用一个外部接口，耗时三百毫秒，prefetch 调大后大量消息挤在消费者本地缓冲，重投失联率也涨了（2.5 节的心跳问题开始抬头）。真正的修法是扩消费者实例——CPU 空闲是因为瓶颈在外部接口的并发上限：

# 每实例按 CPU 与外部接口并发上限设定：prefetch 收敛回小值
channel.basic_qos(prefetch_count=20)
# 实例数从 2 扩到 16，外部接口并发上限同步申请扩容
​

结果：消费者从两实例扩到十六，配合外部接口扩容，消费吞吐达标，队列水位三天下落清零。解读：prefetch 是"给流水线喂料的速度"，不是"干活的速度"——下游工位（外部接口）卡着，喂再多料也只是把半成品堆在传送带上。热区八加热区九的组合拳：先拆掉单点慢操作（本例改为批量接口后单条耗时降到五十毫秒），再扩实例。

参数清单与优先级

代码与拓扑优化完，剩下的百分之十才轮到参数，按收益排序：持久化消息的批量发布间隔（发布侧收益最大）、queue 惰性模式（超大队列场景）、Erlang 进程调度器与线程绑定（多核压榨）、流量控制阈值微调（削平延迟毛刺）。每改一项，回到压测脚本重新测量——没有测量就没有优化，这句话是本节的全部方法论。

压测脚本本身要保持轻量可重复，一个最小骨架胜过一摞文档：

import time, json

def bench(name, fn, duration=10):
    """duration 秒内的发布计数，输出每秒吞吐"""
    n, start = 0, time.time()
    while time.time() - start < duration:
        fn()
        n += 1
    rate = n / (time.time() - start)
    print(f"{name}: {rate:.0f} 条/秒")
    return rate

# 分段测：单条确认版、批量确认版，差值就是优化收益
bench("逐条确认", lambda: publish_one(payload))
bench("批量确认", lambda: publish_batch(payloads))
​

压测数据要留档成基线：每次架构或参数变更前后各跑一轮，基线漂移本身就是故障信号——很多性能退化不是突发的，是十次小改动累积出来的。

💡 关键直觉：调优的第一定律是"测过的瓶颈才是瓶颈"。队列堆积时多数人先怀疑 Broker，但演练二证明，瓶颈经常在消费者背后那个看似无辜的外部调用上。

⚠️ 常见坑：拿生产环境当实验台。所有压测与调参在预发环境完成并固化脚本，生产只执行验证过的版本——性能实验引发的事故，往往比它要解决的慢更痛。

本节要点回顾

• 三段定位法：分段压测出三个极限数，端到端贴近哪段就查哪段；
• 发布侧三板斧：连接复用、批量确认、消息瘦身，通常贡献八成收益；
• prefetch 真相：它是喂料速度不是干活速度，下游卡时调大无益有害；
• 参数靠后：先改代码与拓扑，参数是最后百分之十的精修；
• 两铁律：没有测量就没有优化，生产环境不是实验台。

调优收口。接下来两节进入框架与平台落地：Spring Boot 与容器，把手工代码变成工程组件。