3. 长连接与短连接策略：Netty线程模型调优、连接池大小配置、心跳机制优化、连接超时设置
说到Apollo的长连接，我得先跟你聊聊一个有意思的现象。
很多团队用Apollo，配置一多，客户端一多，就开始出幺蛾子。连接断开、配置更新延迟、客户端频繁重连……说白了，都是长连接这块没玩明白。
我个人习惯，在调优之前，先搞清楚一个核心问题：Apollo到底用的是什么连接模型？
3.1 长连接 vs 短连接：Apollo的选择
Apollo客户端和服务端之间，用的是长连接。不是轮询，不是短连接。
为什么？你想想看，配置中心的核心场景是“实时推送”。如果每次拉配置都建一次TCP连接，那延迟和开销都受不了。尤其是几千个客户端同时在线的时候，短连接会直接把服务端打趴下。
我记得有一次帮一家电商公司做优化，他们客户端数量从500涨到3000，结果服务端频繁报“Too many open files”。一查，原来是短连接模式下，TIME_WAIT状态的连接堆积如山。换成Apollo的长连接后，问题直接消失。
3.2 Netty线程模型调优
Apollo服务端底层用的是Netty。Netty的线程模型，说白了就是Reactor模式。但很多人把它用成了“单线程模式”，那性能肯定上不去。
3.2.1 线程模型的核心参数
Netty有两个关键线程组：
- Boss Group： 负责接受新连接。一般1个线程就够了。
- Worker Group： 负责处理IO读写。这个才是性能瓶颈所在。
我建议的配置方式：
// 服务端Netty配置示例
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup(
Runtime.getRuntime().availableProcessors() * 2
);
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 1024)
.childOption(ChannelOption.SO_KEEPALIVE, true)
.childOption(ChannelOption.TCP_NODELAY, true);
3.2.2 避坑指南：Netty的“伪共享”问题
我曾经遇到过一个诡异的问题：线程数从8加到16，性能反而下降了。查了半天，发现是Netty的ChannelHandler里用了共享变量，导致CPU缓存行失效。
解决方案很简单：用@Sharable注解标注无状态的Handler，或者用ThreadLocal隔离状态。
3.3 连接池大小配置
连接池大小，不是越大越好。你想想看，每个连接都要占用文件描述符、内存缓冲区。连接太多，GC压力就上来了。
3.3.1 客户端连接池
Apollo客户端默认使用HttpClient连接池。我一般这样配：
# apollo-env.properties
apollo.connectTimeout=5000
apollo.readTimeout=10000
apollo.maxConnections=50
apollo.maxConnectionsPerRoute=20
这几个参数的含义：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| connectTimeout | 5000ms | 建立连接的超时时间。太短容易误判，太长浪费资源。 |
| readTimeout | 10000ms | 读取数据的超时时间。长连接场景下，这个值可以设大一点。 |
| maxConnections | 50 | 总连接数上限。根据客户端数量调整，一般50-200之间。 |
| maxConnectionsPerRoute | 20 | 每个路由的最大连接数。防止某个服务端被打爆。 |
3.4 心跳机制优化
长连接最怕什么？死连接。客户端以为连接还活着，实际上服务端早就把连接关了。这时候就需要心跳机制来保活。
3.4.1 Netty的心跳配置
Apollo服务端默认启用了IdleStateHandler。我建议这样配：
// 服务端心跳配置
pipeline.addLast(new IdleStateHandler(
0, // readerIdleTime：读空闲时间，0表示不检测
0, // writerIdleTime：写空闲时间，0表示不检测
60, // allIdleTime：所有类型空闲时间，单位秒
TimeUnit.SECONDS
));
客户端的心跳配置：
// 客户端心跳配置
pipeline.addLast(new IdleStateHandler(
45, // 45秒没有读，触发读空闲事件
0, // 不检测写空闲
0, // 不检测所有空闲
TimeUnit.SECONDS
));
3.4.2 心跳间隔怎么定？
我一般遵循“三分之一原则”：
- 如果服务端连接超时是180秒，那心跳间隔设为60秒
- 如果服务端连接超时是120秒，那心跳间隔设为40秒
这样即使一次心跳丢失，还有两次重试机会。
3.5 连接超时设置
连接超时，是长连接策略里最容易忽略的一环。很多人只设了“连接超时”，却忘了“读取超时”和“写入超时”。
3.5.1 三层超时模型
| 超时类型 | 推荐值 | 作用 |
|---|---|---|
| connectTimeout | 3-5秒 | 建立TCP连接的最大等待时间 |
| readTimeout | 10-30秒 | 等待服务端响应的最大时间 |
| writeTimeout | 5-10秒 | 发送数据的最大等待时间 |
我建议的配置方式：
// 客户端连接配置
HttpClientBuilder builder = HttpClientBuilder.create();
builder.setConnectionTimeToLive(30, TimeUnit.SECONDS);
builder.setMaxConnTotal(50);
builder.setMaxConnPerRoute(20);
RequestConfig config = RequestConfig.custom()
.setConnectTimeout(5000) // 连接超时5秒
.setSocketTimeout(15000) // 读取超时15秒
.setConnectionRequestTimeout(3000) // 从连接池获取连接的超时
.build();
3.5.2 超时后的处理策略
超时了怎么办？不是简单地重试就完事了。我建议：
- 第一次超时： 等待1秒后重试
- 第二次超时： 等待2秒后重试
- 第三次超时： 等待4秒后重试
- 超过3次： 断开连接，重新建立长连接
这种指数退避策略，能有效防止“重试风暴”。
3.6 知识体系总览
说了这么多，我画了一张图帮你理清思路：
这张图把整个长连接策略串起来了。从Netty线程模型到底层的心跳和超时，每个环节都环环相扣。你调优的时候，别只盯着一个点，要全局考虑。
好了，长连接这块就聊到这儿。记住一句话：连接不是越多越好，心跳不是越快越好，超时不是越短越好。找到那个平衡点，你的Apollo就能跑得又稳又快。