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

背景:

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

 

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

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

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

 

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

 

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

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

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

 

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

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

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

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

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

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

 

相关代码:

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

 

时隔多日补充:

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

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

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

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

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

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

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

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

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

解决方案

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

原文链接:https://www.cnblogs.com/imyjy/p/7097595.html

原创文章,作者:优速盾-小U,如若转载,请注明出处:https://www.cdnb.net/bbs/archives/18526

(0)
上一篇 2023年11月27日
下一篇 2023年11月27日

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

优速盾注册领取大礼包www.cdnb.net
/sitemap.xml