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

背景:

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

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

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

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

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

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

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

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

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

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

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

  

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

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

  

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

相关代码:

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

时隔多日补充:

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

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

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

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

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

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

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

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

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

  

解决方案

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

上一篇:Java面试中hashCode()与equals(Object obj)方法关系的准确回答


下一篇:Android一对多蓝牙连接示例APP