基于netty的socket服务端触发了channelInactive方法，但实际连接没有断开的问题

背景：

一个中小型H5游戏，后端使用基于 netty 的socket服务

 

服务端 分为 分发服务器 & 业务服务器，业务服务器可负载

　　用户客户端与分发服务器连接

　　分发服务器再作为客户端与每台业务服务器连接

 

为了方便快速得知服务宕机的情况，我打算在服务器上做一个宕机通知

 

因为 分发服务器与业务服务器都处于连接状态，在连接断开时都会触发 channelInactive 方法，所以我预想的是

　　一旦分发服务器宕机，则业务服务器可以监听到连接断开，然后做出警报通知

　　反之亦然，用分发服务器做业务服务器的宕机警报

 

代码写完测试过后，功能可以没什么问题，于是更新至线上，过了一天以后，问题就来了

　　我收到了 业务服务器的警报，说分发服务器宕机了，紧张的我打开游戏看了看，毛事没有，分发服务器好好的，连接也是正常的

　　看了一下日志，业务服务器的 channelInactive 方法确实被触发了。但是是什么原因导致触发的呢？

　　

　　// 问题先记下来，正在解决中。。解决完了回来更新。

　　问题找到了，是因为重启业务服务时，直接kill了进程，导致，分发服务与业务服务之间的socket没有正常断开连接，随后的某个时刻，分发服务收到了一个请求，试图将请求转发到此业务服务时，就出现了异常并触发了断开连接，所以就产生了分发服务与当前业务服务断开连接的假象，其实是与以前已经关闭的业务服务断开，当前的连接是正常的。

　　

解决方案：在分发请求之前，验证 channle.isActive()。如果false，则主动做出相应处理。

 

相关代码：

 

时隔多日补充:

　　自从根据上面的做法实施过后的几天里,  错误的宕机警报确实减少了, 且上线后的正式服务没有再有过误报的情况了.... 但是...

　　测试服误报逻辑服务宕机的问题没有了, 但是却出现了逻辑服务误报分发服务宕机的情况.并且当我查看后发现分发服务和逻辑服务都是好好的, 也不存在上面所说的老连接未正常断开的情况!!!...WTF...冤冤相报何时了????

　　随后我陷入了沉思, 为什么正式服好好的, 测试服却会出现这种问题??? 他们有什么区别?

　　经过我交警脑汁的思考,排错....终于我还是发现了一个问题!!

　　　　正式服: 分发服务开放外网链接, 逻辑服务只允许内网连接(也就是只允许分发服务连接)

　　　　测试服: 分发服务与逻辑服务皆允许外网连接且都开放了端口(因为贪图方便, 放在一台服务器上了)

　　　　因为从正常逻辑上讲, 只有分发服务才会去连接逻辑服务, 所以逻辑服务默认只要是连接了我的那就是分发服务, 并且在任何连接断开时发出警报!!

　　　　由此引发问题: 因为开放了外网端口, 所以有许多网络爬虫啊, 端口扫描等等奇奇怪怪的连接发生, 然而逻辑服务却傻乎乎的把他们当成是分发服务......并且在连接中断后发出警报!

　　就这样, 问题终于找到了, 然后就要去解决了, 怎么解决呢? ...那就让逻辑服务好好擦亮眼睛吧!

　　

解决方案

　　分发服务在连接逻辑服务成功后, 需要发送一个指令告诉逻辑服务: 我是分发服务, 我的身份是*****, 这样逻辑服务就知道这个连接是谁了!