高并发IM系统调优实战：削峰、负载均衡与内存优化

大促那天的故障复盘会，我至今记得监控屏上的曲线：IM 网关 CPU 直接顶着 95% 以上，消息队列积压从几百条跳到几十万条，连接数每分钟都在涨，紧接着一台接入节点触发了 OOM 自动重启。用户端反馈的表现是——消息延迟从几十毫秒变成十几秒，发出去的消息偶尔丢失，群里头像转圈半天刷不出来。

这套老掉的即时通讯源码，单机支撑个三四千长连接还算稳，但一到大促、秒杀这类瞬时流量洪峰就原形毕露。我们当时面临三个核心问题：一是消息洪峰来了之后数据库和下游系统根本扛不住，必须做削峰；二是接入层的负载均衡策略太粗，连接和请求都往几台机器上怼；三是 JVM 堆内堆外内存双双吃紧，GC 频繁到让人怀疑人生。

这篇文章就把这次调优的完整过程拆开讲，核心覆盖三条主线：高并发消息削峰、负载均衡策略、内存资源优化。我会把每一步的关键决策、参数计算过程、踩过的坑和最终压测数据都写出来。不管你是负责线上 IM 系统的运维，还是做后端架构设计的开发，或者刚入门想了解高并发系统怎么调优，这篇文章都值得你花二十分钟认真看一遍。

1. 项目背景与调优目标拆解

1.1 业务痛点：线上事故是怎么爆出来的

那个阶段我们的即时通讯系统承载了主站全量用户的聊天、群通知、系统公告三类消息。日常高峰 QPS 也就 5000 左右，但大促活动一开始，运营会在整点发大量群消息和公告，瞬时 QPS 能冲到 8 万以上。这种尖峰流量对系统是毁灭性的：

消息发送链路是同步调用的。客户端把消息发到接入网关，网关同步写 Redis 做离线存储，再同步投递给在线接收方，最后还要同步推消息给推送服务。链路上任何一个环节慢下来，整条链路就堵死。MySQL 的写入 TPS 到 3000 左右就会出现锁等待，Redis 的写吞吐虽然有上限，但网络带宽和序列化开销在大消息体面前也很脆弱。

接入层的负载均衡也是个问题。我们用的是 Nginx 四层代理 + 后端网关节点的方式，Nginx 的 upstream 配的是默认的轮询算法。四层负载只看连接数，不看每台网关节点实际的 CPU 负载和内存水位。导致的结果是：新建立的连接经常集中落在配置了高权重的机型上，而新扩容的低配机器反而长时间空闲。长连接又是小时级别的存活时间，连接一旦建立就固定在哪台机器，负载不均的问题会持续放大。

最头疼的是内存。K8s 给每个网关 Pod 限了 8GB，JVM 堆设置 4GB，剩余 4GB 留给堆外。但实际运行中，Netty 的堆外内存池、线程栈、直接缓冲区、压缩类元数据都要吃这部分空间。连接数一高，堆外内存直接撑爆，然后就是 OOM Kill。我们统计过，每次大促期间网关 Pod 平均重启 5 次以上，每次重启意味着几万条长连接要断线重连，断线风暴又反过来加剧负载不均——这是一连串的恶性循环。

1.2 调优目标与验收指标

项目启动前我们把目标量化了，有具体的数字才能判断调优到底有没有效果：

不追求极限性能数字，我们核心目标是：在同等机器资源下扛住双倍流量，同时系统保持稳定不 OOM、不积压、不丢消息。这些目标听着朴实，做起来需要同时在三个方向上做文章。

1.3 整体架构与优化主线

调优不是单点修改，而是一条链路的全面梳理。我们的即时通讯系统逻辑上分四层：

客户端接入层：维护长连接，处理心跳、断线重连、协议编解码。这层是连接风暴的第一道防线。

消息路由层：负责消息的接收、鉴权、路由、存储。每条消息都要在这里决定是走实时通道还是离线通道。

消息处理层：消费消息队列，做消息持久化、推送、离线存储。这层用 MQ 做异步解耦。

状态管理层：用 Redis 保存用户在线状态、Session 映射关系、连接路由表。这层是全局共享的。

对应到三块优化：

消息削峰瞄准的是消息处理层——把同步写库和同步推送改成异步削峰处理，用 Kafka 做缓冲，同时通过滑动窗口限流保护下游。

负载均衡瞄准的是接入层和路由层之间的连接分配——改造成一致性哈希 + 动态权重，让连接和流量均匀分布，避免热点节点。

内存优化则贯穿所有层——从 JVM 堆内对象复用、Netty 内存池参数调整到堆外内存监控兜底。

这三块不是孤立的。削峰做不好，内存再好也会被打爆；负载不均衡，部分节点的内存优化做得再好也扛不住超额流量。所以这是一套组合拳，必须统筹实施。

2. 高并发消息削峰：从限流到 MQ 缓冲的完整链路

2.1 削峰的核心逻辑：为什么不能靠堆机器

很多团队遇到流量洪峰第一反应就是扩容，把 Pod 数量翻倍。这在流量平缓上涨时有效，但面对瞬时尖峰，扩容的速度根本跟不上流量上涨的速度。K8s HPA 从检测到指标异常到完成扩容，冷启动至少需要 2~3 分钟，而流量洪峰是秒级就冲上来的。

更关键的是，扩机器解决不了下游瓶颈。MySQL 的写入能力不会因为你扩容网关就变强，Redis 的带宽和 CPU 也不会。真正该做的，是把同步链路改造成异步链路，消息不直接打到下游系统，而是先进队列缓冲，再由消费者按下游能承受的速率慢慢消费。这就是削峰的核心思路。

一句话概括：削峰不是让消息消失，而是让消息在队列里等一等，把时间的尖峰拉平，让系统始终工作在平稳的水位线上。

这个道理类似高速公路上的收费站。早晚高峰时车流是集中的，如果每个车道都对应一个收费员，高峰一过收费员就闲置，成本浪费。更好的做法是建一个大的停车场（MQ），让车先排队（缓冲），收费员按固定速度一辆一辆放行（消费速率控制），这样收费员的工作量是均匀的。

2.2 接入层限流：令牌桶与滑动窗口的取舍

有了队列缓冲，不等于可以无上限地接收消息。如果发送方疯狂灌消息，队列也会被撑爆，最终导致消费者被拖垮。所以削峰的第一道闸门是限流。

我先说踩过的坑。最初我们用 Guava 的 RateLimiter 做单机限流，令牌桶算法，每台机器限制每秒处理 1 万条。结果线上发现，某些节点负载很低却在限流，而另一些节点已经过载却还在放量。原因是单机限流只对本地流量生效，负载均衡不均时，不同节点实际流量差距很大，限流的“水位线”完全错位。

后来改成了分布式限流：基于 Redis + Lua 脚本实现全局令牌桶。Redis 单线程执行 Lua 脚本是原子操作，不会有并发竞争的问题。具体设计：

• 每 20ms 向 Redis 写入一批令牌，容量上限 1.5 万，生成速率 8000/秒；
• 网关收到消息先执行 Lua 脚本尝试取令牌，取不到直接返回“系统繁忙”错误码；
• 客户端收到错误码做本地重试，重试间隔指数退避，从 100ms 起步，最大 3 秒。

令牌桶的好处是允许一定程度的突发流量。对于消息系统中的瞬间峰值（比如整点公告），令牌桶比固定窗口限流更合适。滑动窗口限流虽然能精确控制速率，但对突发流量不友好，容易误杀正常业务。我的经验是：接入层用令牌桶，下游存储层用滑动窗口，两层配合，既能抗突发，又能保稳定。

2.3 队列缓冲：Kafka 分区与消费组的设计细节

限流只是控制入口速率，真正让消息平滑下来的是消息队列。我们选型时对比了 RocketMQ 和 Kafka。RocketMQ 的优点是事务消息和延迟消息支持好，但我们的场景就是简单的异步缓冲，不需要复杂的消息语义。最终选了 Kafka，理由有三：吞吐量极高，单 Partition 顺序写；消费模型简单，按分区顺序消费；社区生态成熟，监控和运维工具多。

Topic 设计和分区策略是这里最容易犯错的地方。一开始我们图省事，把所有人的消息都发到一个 Topic，结果消费者组的并行度上不去，消费速度跑不满。后来按业务类型拆分：单聊消息一个 Topic、群聊消息一个 Topic、系统公告一个 Topic。分区数按消费者实例数乘以 3 来设置，比如消费者 8 个实例，分区就设 24 个。这样即使消费者实例动态扩缩容，分区也能均匀分配给各实例。

分区键也有讲究。单聊消息以 conversationId 作为 key，保证同一个会话的消息进入同一分区，消费时能按时间顺序处理；群聊消息以 groupId 作为 key，保证同一个群的消息有序。这里需要注意：Kafka 的单分区有序性换来了扩展性限制，如果某一个群的吞吐量特别高（比如万人群），它会独占一个分区的消费能力。我们针对超大群做了特殊处理：群成员数超过 5000 时，群消息按群成员 ID 取模再分区，尽量分散到多个分区。

消费者的消费速率必须受控。我们在消费端加了 RateLimiter，根据下游 Redis 和 MySQL 的实际承受能力动态调整消费速率。系统启动时消费速率设为 5000 条/秒，运行过程中每秒统计下游的平均响应时间，如果 RT 超过阈值就自动降低消费速率，恢复后再逐步上调。这个自适应的限流策略避免了消费过快打爆下游，也避免了消费过慢导致积压。

2.4 群聊广播风暴的定向压降

群聊是即时通讯里最消耗资源的场景。一个 1000 人的群，发一条消息意味着要生成 1000 条投递任务。如果这个群连续有人说话，消息瞬间放大倍数是非常恐怖的。我们线上的一个极端案例：一个 5000 人游戏群在活动期间每分钟发 200 条消息，消息总量是每分钟 100 万条，直接把推送通道打爆。

群聊削峰不能套用普通的“进队列”方案，因为普通的单条消息进队列再消费，仍然要处理 1: N 的扇出逻辑。我们调整了策略：

小群（≤200人）：实时推送，每个人都走完整消息链路。因为人数少，放大倍数有限，实时性优先。

大群（200~5000人）：异步削峰推送。群消息写入 Kafka 后由专门的广播消费者处理，每台消费者分到一部分群成员，基于本地内存的成员列表做推送，不再逐个查询 Redis。这样消费吞吐提高了至少 4 倍。

超大群（>5000人）：消息先落 Redis 离线存储，不做实时推送，触发客户端拉取。客户端拉取是批量接口，一次请求拉最近 100 条，大大减少推送通道的压力。

同时我们做了消息去重。同一用户对同一条消息的多个副本只保留一条。用 Bitmap 做去重标记，以 messageId 为索引，在消息进入投递队列前先检查是否已经投递过，避免重复推送造成流量浪费。这一步优化下来，每条群消息的推送量降低了约 60%，效果非常显著。

3. 负载均衡策略：从连接入口到消息路由的精细化控制

3.1 先搞清楚负载均衡要解决什么问题

负载均衡这个词听着简单，但在即时通讯场景里，它其实包含三个不同维度的问题：

连接层面的负载均衡。客户端长连接如何分配到不同的接入网关节点，确保每台网关的连接数、CPU、内存负载相对均衡。这里最难的是：长连接一旦建立就会持久存活，新连接分配策略对存量连接的分布影响有限。如果一开始连接就集中分配，后续很难纠正。

请求层面的负载均衡。真实的消息发送请求在连接层之上，一条连接上可能同时有多个请求在飞。请求级的负载需要考虑的是：每个网关节点的处理能力是否饱和，而不仅仅是连接数。

路由层面的负载均衡。状态管理层的 Redis 集群、消息处理层的 Kafka 分区，都有各自的热点问题，需要路由策略结合具体场景来做均衡分布。

很多团队只做了第一层——用 Nginx 轮询或随机分配连接，就以为万事大吉。实际上连接平均不等于流量平均，更不等于负载平均。一个连接上活跃聊天的人多，它的请求量可能是另一些连接的好几倍。负载均衡的细致程度，决定了系统整体资源利用率的极限。

3.2 四层 vs 七层：IM 长连接的正确打开方式

接入层最初的架构是 Nginx 七层负载（HTTP 反向代理）挂在一组 WebSocket 服务后面。七层负载的好处是可以识别到 HTTP Header，做到基于用户 ID 的会话保持。但七层代理要解析完整的 HTTP 协议，连接数一上去，Nginx 的 CPU 消耗非常夸张，而且代理层本身成了瓶颈。

我们后来把长连接接入了 Nginx Stream（四层负载），也就是 TCP 层的转发。四层负载只做字节流的转发，CPU 开销极低，单机并发连接数能到 50 万级别。客户端先通过 HTTP 接口获取接入网关的地址列表，然后直接 TCP 连接到具体的网关节点，Nginx 只负责 TCP 流的透明转发。这个改动把网关层的吞吐能力提升了一个数量级。

这里有个细节值得说：客户端的连接建立流程做了调整。原先客户端随机选 Nginx 的 IP 连接，现在我们让接入层返回一个“最佳节点列表”，按照节点当前负载从低到高排序，客户端优先连负载最低的节点。这样虽然不能完全替代负载均衡，但可以让新连接一开始就落在合理的位置上。

另外，Nginx 的 worker_processes 和 worker_connections 参数也要按长连接场景调整。默认 worker_connections 是 1024，在我们这个规模下根本不够，要调到 65535，并注意内核 somaxconn 参数同步调整，否则高并发连接建立时会丢握手包。

3.3 动态权重与最小连接数：让负载均衡不再“盲选”

Nginx 自带的加权轮询算法是静态的，权重是写死在配置文件里的，不会根据后端实时负载自动调整。我们做了个“动态权重”方案，思路是：让网关节点每 5 秒上报一次自己的负载指标到注册中心（CPU 使用率、内存占用、当前连接数、消息队列积压量），Nginx 定期从注册中心拉取这些指标，动态计算新的权重。

计算权重的公式是综合考量多维负载的：

权重 = 基础权重 × (CPU 负载系数 × 0.3 + 内存系数 × 0.3 + 连接数系数 × 0.2 + 积压量系数 × 0.2)

每个系数的取值范围是 0.5~1.5，负载越高系数越低。这样 CPU 使用率高的机器会自动降低权重，新连接就会往负载低的机器上分配。这个方案线上跑了一段时间，效果很稳定，各节点连接数的标准差从原来的 32% 降到了 8% 以内。

还值得一提的是“等开销负载均衡”的概念。很多负载均衡器做均衡时只看连接数或请求量，不考虑每台机器实际的开销（比如消息体大小、编解码耗时、内存分配压力）。不同用户发送的消息体大小差异非常大，一条 1MB 的视频消息和一条 100 字节的文本消息，对系统资源的消耗完全是两个量级。我们在计算权重时把“平均消息字节数”也纳入进来，每台网关统计最近 1 分钟的消息总字节数，除以连接数得到平均开销，作为等开销均衡的依据之一。

3.4 一致性哈希与粘性连接：同一用户永远落在同一节点

虽然连接层的动态权重解决了新连接的分配问题，但更大的隐患是存量连接的路由一致性。

你可以想一个场景：用户 A 在手机 App 上连着网关节点 1，后续发送的每条消息都带有连接会话（Session）。如果负载均衡器把用户 A 的下一条消息转发到了网关节点 2，网关节点 2 上没有用户 A 的会话数据，就需要跨节点查询用户状态，或者直接拒绝连接让客户端重连。跨节点查询会让路由层的压力成倍增加，这是非常常见的即时通讯调优坑点。

我们用的方案是：一致性哈希 + 虚拟节点 + 粘性会话。

整体思路是：网关节点根据 IP 和端口哈希到一致性哈希环上，每个物理节点生成 256 个虚拟节点分散在环上，客户端连接时根据用户 ID 哈希到环上的某个位置，顺时针找到最近的虚拟节点，这个虚拟节点对应的物理节点就是用户应该连接的网关。

这样做的核心价值在于：同一个用户经过哈希计算，总是路由到同一个物理节点，不需要跨节点查会话。当某个节点扩缩容时，只有该节点附近的哈希槽位上的用户需要重连，影响面被局限在一个很小的范围内，这比传统取模哈希（取模后节点变化会打乱所有映射）要平滑得多。

重连时的粘性路由也做了处理。客户端重连时在协议包里带上自己的 userId，接入网关按一致性哈希重新计算目标节点。如果目标节点就是当前节点，直接复用旧 Session；如果目标节点是其他节点，则通过 Redis 路由表找到旧的连接信息，做异步迁移，避免重连风暴。

3.5 等开销负载均衡与硬件负载均衡(如F5)的适用场景

在完善软件负载均衡的同时，我们也评估了硬件负载均衡方案，比如 F5 这种专用设备。F5 的优势是性能极高、稳定性极强，适合作为入口处的流量分发器，把进入机房的流量统一调度。缺点也很明显：价格贵、配置复杂、扩展不够灵活。以我们目前的业务规模来说，Nginx 四层 + 应用层自研权重已经完全够用，F5 不是必需的，但如果是大型系统需要承载百万级长连接，F5 作为最高层入口仍然是值得考虑的选择。

真正的均衡，要让每一台机器花费的“实际开销”大致相等，而不是连接数相等或者请求数相等。这也是为什么应用层必须自己做一层负载感知——只有应用才知道自己当前的处理压力和资源占用，把这种信息反馈给负载均衡器，才能做真正意义上的等开销负载均衡。

4. 内存资源优化：从 JVM 到堆外内存的全方位排查

4.1 先定位问题：内存到底被谁吃掉了

负载均衡优化之后，连接分布均匀了，但内存问题依然存在，甚至因为单机连接数提升而更加突出。生产环境的网关节点用的是 8GB 内存容器，JVM 堆设置 4GB，堆外预留 4GB。故障时我们通过监控发现，堆外内存的使用率长期在 90% 以上，堆内 GC 后老年代也经常上涨到 70%。

先用 jcmd 命令查看堆外内存分布：

jcmd VM.native_memory summary

输出中能看到几大块：Netty 的 Direct Buffer 内存池（占比最大）、线程栈、编译器、类元数据。在连接数上升到 5 万以上时，Netty 的堆外内存池几乎吃掉了 3GB 空间，这就是 OOM 的最大元凶。

然后我们用 jstat 看 GC 日志，发现 Full GC 频繁到每 10 分钟一次，老年代空间根本回收不动。正常情况下老年代应该大部分是长期存活的对象（长连接会话对象），但我们的老年代里充斥着大量一次性消息对象，这些对象本应在年轻代就被回收，因为消息量太大、创建速度太快，对象晋升到老年代的比例过高。

4.2 堆内优化：对象复用与缓冲区分层

堆内内存优化的核心思路只有两个字：复用。高并发场景下频繁创建对象是内存膨胀的根源。

消息编解码对象的复用。每条消息从接收字节流到解析成业务对象，中间会创建大量的中间对象：ByteBuffer、字符串、Map、List。我们用 ThreadLocal 缓存了这些对象池，在线程处理完一条消息后不释放，而是清空内部状态后放回池中，下一条消息直接复用。实测下来，消息处理线程的 GC 压力降低了约 30%。

共享消息内容复用。群聊广播是一条消息投递给 N 个接收方，原来的实现是每个投递任务都复制一条完整的消息对象，等于一条 1KB 的消息在内存里膨胀成 1000 份 1KB。我们改成共享消息体 + 引用计数，所有投递任务只保存消息的引用和接收方列表，只有消息从所有接收方的待发送队列中移除后，内存才真正释放。这一步优化效果非常明显，群聊场景的内存占用直接下降了一半以上。

缓冲区也做分层。原来的架构里，一条消息从接入网关注入到消息处理层，中间要经过多级缓冲：Nginx 的 socket buffer、Netty 的 eventloop buffer、业务层的队列 buffer、Kafka producer 的 buffer。每一级 buffer 都存在积压条数过多的问题，占满了大量内存。我们调整了各级缓冲的水位限制：单条消息超过 512KB 的直接走独立的文件通道，不再在内存队列里排队，避免大消息把内存队列全部占满。

4.3 Netty 内存池与堆外内存管控

Netty 的高性能依赖堆外内存（Direct Memory），但堆外内存不受 JVM 堆大小控制，如果管理不当，很容易吃光机器内存。我们针对 Netty 做了一系列参数调整：

开启并调优 Netty 内存池。Netty 默认使用 PooledByteBufAllocator，但很多参数是保守的。我们把 arena 数量从默认的 2*CPU 核数 调整为 CPU 核数/2，避免过多的内存池碎片；把 maxOrder（内存块分级深度）从默认 11 调整为 9，减少大块内存的碎片化。

限制单条连接的读缓冲和写缓冲。默认情况下 Netty 会根据水位自适应调整缓冲区大小，但在消息洪峰时，缓冲区会一路膨胀，单条连接写缓冲区可能涨到几 MB，几百条连接就把内存吃光了。我们把写缓冲水位上限设为 512KB，读缓冲设为 64KB，超过水位的消息直接触发背压机制，让发送端放慢发送速度。

ThreadLocal 的使用约束。Netty 的 EventLoop 线程池是内存分配的关键路径，我们在接入层代码里规定：任何消息处理不得脱离 EventLoop 线程创建新的 ByteBuf，必须使用 Channel 的 allocator 来分配，否则会出现操作系统内存分配不均甚至泄漏。

内存监控方面，我们打开了 JVM 的 Native Memory Tracking（NMT），并设置了 MaxDirectMemorySize 上限，默认是等于堆大小，我们调整为 2GB。超过上限时 Netty 会抛出 OutOfMemoryError 而不是静默地占用记忆。实际运行后我们发现这个上限太紧，又调到 2.5GB，留出 1.5GB 的余量给其他堆外开销。

4.4 内存监控与泄漏排查实录

调优过程中遇到一个很棘手的堆外内存持续上涨问题。即使线上流量降下来了，堆外内存还是只涨不降，最终把机器打 OOM。我们怀疑是 Netty 的 ByteBuf 泄漏，用下面这套方法和流程排查：

打开 Netty 的泄漏检测。在 JVM 参数里加 -Dio.netty.leakDetection.level=paranoid，这是最严格的检测级别，会在每次访问 ByteBuf 时记录访问栈，一旦检测到未释放的缓冲区，立刻在日志中打印创建点栈。

跑压测复现。用压测工具模拟 2 万并发连接持续发送消息，同时观察监控面板上的堆外内存曲线和日志中的泄漏告警。

根据告警栈定位。Netty 把泄漏创建点的完整堆栈打印出来后，我们立刻定位到问题：一段业务代码把 ByteBuf 从 Netty 的解码器中取出后放到业务队列里，但业务队列消费失败时会直接丢弃消息，丢弃时忘记调用 release() 方法释放缓冲区。

修复方式是对所有丢弃路径统一加 try-finally 释放，同时在上游统一引用计数管理。修复之后，压测 8 小时，堆外内存曲线平稳如一条直线。

这里强烈建议所有使用 Netty 的团队：生产环境一定要打开 paranoid 泄漏检测跑一轮压测，正常运行时可以调回 simple 模式，检测有性能损耗但安全很多。

5. 完整压测数据与调优结果对比

5.1 压测方案与场景设计

为了验证一组组合拳的效果，我们搭建了一套与生产等价的压测环境：3 台 8 核 16GB 的接入网关节点、2 台 8 核 16GB 的消息消费者节点、1 套 Kafka 集群（3 节点）、1 套 Redis 集群（3 节点主从）。全链路压测覆盖了登录、单聊、群聊、系统公告四个核心场景。

压测工具选的是一次性能压测平台，每次压测前先跑 5 分钟预热脚本，让 JIT 充分编译，再开始正式压测。每个场景压 15 分钟，记录 P99 延迟、吞吐量、内存水位和 GC 次数。对比组是调优前的旧版本代码，控制变量法逐项验证。

5.2 关键指标对比

压测数据最让我意外的是 P99 延迟从 850ms 降到 45ms。仔细分析原因，延迟的大头不在消息处理本身，而在排队：消息在同步链路上排队等下游返回，一条消息平均要等好几次数据库和 Redis 的响应。改造成异步削峰后，消息写入 Kafka 就算“发送成功”，客户端感知的延迟自然就下来了。这个结果也验证了“削峰的本质是降低端到端的排队时间”这个判断。

5.3 资源成本核算

调优后我们用同样的 Pod 规格承载了双倍流量，这意味着如果保持原来的流量规模，可以对资源做缩容。经过核算，网关节点从 24 个缩到 12 个，消息消费者从 8 个缩到 4 个，整体机器成本下降约 50%。每月的云资源账单下降了大约 40%，这个投入产出比，老板是很满意的。

当然，削峰和异步化不是没有代价。消息从同步变异步之后，实时性打了折扣。我们通过压测确认，对于即时通讯场景来说，45ms 的 P99 延迟完全在可接受范围内，用户感知不到差异。如果未来有对实时性极其敏感的业务（比如音视频信令），需要单独走低延迟通道，不能一刀切全走队列。

6. 常见问题与排查技巧实录

6.1 限流阈值怎么调才能不误杀

分布式限流最常见的坑是阈值设置不当。阈值设小了，正常用户高峰期直接被拒绝；设大了，限流失去意义，下游照样被打爆。

我们的做法是动态阈值 + 分级限流。给每个下游系统设置一个红线水位（比如 Redis 的 CPU 使用率 70%），当水位超过红线时，限流阈值自动下调 20%；水位降下来后逐步恢复。分级限流则是按照用户等级和消息类型设不同的限制：系统公告限流最宽松，群聊消息限流最严格，VIP 用户有更高的配额。实际运行效果稳定，基本没有误杀正常消息。

6.2 一致性哈希热点用户怎么处理

一致性哈希虽然有虚拟节点，但架不住某些用户或群的消息量巨大，把某个物理节点打爆。我们的解决方案是“热点分离”：通过消息量统计，自动把发送频率超过阈值的热点用户/热点群标记为“热点对象”，它们的消息路由不走一致性哈希，而是直接通过消息队列分发到消息处理层的空闲节点。这个方案相当于把热点流量从通用哈希环上摘除，单独处理。

6.3 堆外内存泄漏排查五板斧

很多团队遇到堆外内存上涨就束手无策，这里分享一套排查顺序：

先确认是不是 Netty 的缓冲区泄漏。打开 leakDetection 的 paranoid 级别，跑一轮压测，看日志有没有泄漏告警。

用 jcmd VM.native_memory summary 查看堆外内存按类型分布，定位是 Direct Buffer、线程栈还是其他类别。

排查系统调用参数。用 jstack 抓线程栈，看看是否有大量线程阻塞在 epoll_wait 上，线程数过多也会占大量内存。

查看 GC 日志确认是不是堆内对象晋升异常，堆内晋升到老年代的对象越多，JVM 对堆外内存的管理压力越大。

最后，如果所有常规手段都查不到，可以在压测环境用 valgrind 跟踪 JVM 的原生内存分配再做深入排查。

6.4 断线重连与粘性路由冲突怎么办

另一个遇到过的问题是：客户端因为网络抖动断线后立即重连，如果重连请求被负载均衡器分配到了新的节点，而旧节点的会话还没过期，两个节点同时存在同一用户的会话状态，消息可能被重复推送或丢失。

我们的解法是重连请求必须带 userId，网关层判断该 userId 是否有活跃 Session：如果有且会话未过期，强制先关闭旧连接再做新连接，同时把离线数据从旧节点同步到新节点；如果没有则直接建立新连接。这相当于在应用层做了一次“会话所有权转移”，结合一致性哈希的粘性路由，基本解决了重连导致的重复消息问题。

这里再补充一个小技巧：客户端的重连要做随机退避，不要所有客户端断线后同时重连，否则会产生“重连风暴”，把刚刚空出来的带宽瞬间打满。我们的重连退避策略是：第一次重连立即执行，失败后按 1s、2s、4s、8s 递增，最长不超过 30s，并在重连前加上随机抖动。这个策略上线后，断线重连的成功率和资源消耗都改善了很多。

写在最后的经验体会

整个调优项目持续了大约一个月，核心产出不是那几个量化指标，而是让我重新理解了承载高并发的本质：不单是提高单机的绝对性能，而是让整个系统的每一步都在可控的范围内排队、缓冲、均衡，用可控的手段吸收掉不可控的流量波动。

我个人在实际操作中最深的一条体会是：性能调优永远不要拍脑袋改参数。每改一个参数，都要有压测数据支撑，每次压测只改一个变量，对比分析后再动下一个。我们在调优过程中走过弯路——同时改了限流阈值、Netty 参数和 GC 参数，结果出了问题根本不知道是哪一项导致的，只能全部回滚重来。一次只改一个变量，这个习惯帮我省下了至少一周的排查时间。

最后再分享一个小技巧：这套调优方案不止适用于即时通讯系统，凡是存在瞬时流量洪峰、长连接、高并发消息处理的场景——比如直播弹幕、物联网设备接入、实时协作编辑——都可以复用同样的思路。核心就三句话：削峰让流量变平，均衡让负载变匀，内存优化让系统变稳。把这三件事做好，大部分高并发问题都会迎刃而解。