我们在游戏公司使用 Netty3.2.1 进行客户端和服务器之间的连接管理。我们的目标是改进
- 能够处理网络中断等突发情况，并且必须能够尽快从中恢复。
- 在不丢弃现有连接套接字的情况下增加单个服务器可以处理的连接数。
Blip 场景 在实时环境中，由于 ISP 故障可能会出现 blip，因此所有现有客户端（我们的客户端在现有连接中断后重新连接）连接将同时中断和重新连接。例如，如果一个服务器连接了 25000 个客户端，在 blip 期间，所有 25000 个客户端都试图同时连接回服务器，这给服务器带来了巨大的压力。由于 Netty 旧版本不提供启用/禁用OP_ACCEPT的功能，我们开始限制超过 100 个并发连接 ssl 握手限制的连接。当超过限制时，我们会暂停老板线程几秒钟。我们还没有准备好使用提供该功能的 Netty 4.0 Beta 版本。
我们在压力测试期间观察到的其他情况是，如果服务器上有大量传入连接，则接受所有传入连接并稳定需要花费大量时间（25 K 连接大约 30 分钟，所有 25 K 尝试连接在同一时间） 。但是如果我们慢慢增加负载，netty 能够在非常短的时间内（大约 3 到 5 分钟）轻松地接受所有连接。我们希望构建系统，以便我们希望能够灵活地处理突发事件。
- 我在现有的 Netty Jar 中添加了一些日志，当客户端在巨大负载期间断开连接时，它似乎在 read() 方法中失败。
- 使用 Netty3.6 Final jar ，没有太大帮助
- 将使用执行处理程序帮助吗？
- 禁用限制会导致服务器出现 OOM 异常。
请提出解决此问题的任何可能方法。还有其他方法可以限制连接吗？
设置详细信息和配置
客户端- JMeter 框架 - 2 GB 机器负载 - 50000 个客户端每秒消息数 - 12000 条消息/秒。消息是客户端问候和服务器问候作为字符串。所有机器上的 ulimit 为 1,00,000
服务器- 12 个核心、HT 和 48 GB ram 工作线程 - 50 个（HT 的核心数量的两倍，核心数量变为 24 个）Linux 机器的所有 TCP 内部缓冲区都配置为使用峰值限制。
我们的管道处理程序具有以下处理程序
- pipeline.addLast(sslHadler) - 内置处理程序中的 Netty
- pipeline.addLast(messageEncoder) - 只是对字节进行编码和解码，并根据需要将它们转换为消息帧。
- pipeline.addLast(messageDecoder)
- pipeline.addLast(Businesshandler)