本文描述了在基于Netty的Socket服务中遇到的一个问题，即服务端channelInactive方法被误触发，导致错误的宕机警报。经过排查，发现原因是服务重启时未正常关闭连接，而在后续请求转发时触发异常。解决方案是增加channel.isActive()检查，确保连接活跃。然而，之后又出现逻辑服务误报分发服务宕机的情况，经过分析发现是因为测试环境中两个服务都开放了外网连接，导致逻辑服务无法区分正常连接和异常连接。最终解决方案是让分发服务在连接逻辑服务时发送身份标识，使逻辑服务能正确识别连接来源。
背景：
一个中小型H5游戏，后端使用基于 netty 的socket服务
服务端 分为 分发服务器 & 业务服务器，业务服务器可负载
用户客户端与分发服务器连接
分发服务器再作为客户端与每台业务服务器连接
为了方便快速得知服务宕机的情况，我打算在服务器上做一个宕机通知
因为 分发服务器与业务服务器都处于连接状态，在连接断开时都会触发 channelInactive 方法，所以我预想的是
一旦分发服务器宕机，则业务服务器可以监听到连接断开，然后做出警报通知
反之亦然，用分发服务器做业务服务器的宕机警报
代码写完测试过后，功能可以没什么问题，于是更新至线上，过了一天以后，问题就来了
我收到了 业务服务器的警报，说分发服务器宕机了，紧张的我打开游戏看了看，毛事没有，分发服务器好好的，连接也是正常的
看了一下日志，业务服务器的 channelInactive 方法确实被触发了。但是是什么原因导致触发的呢？
// 问题先记下来，正在解决中。。解决完了回来更新。
问题找到了，是因为重启业务服务时，直接kill了进程，导致，分发服务与业务服务之间的socket没有正常断开连接，随后的某个时刻，分发服务收到了一个请求，试图将请求转发到此业务服务时，就出现了异常并触发了断开连接，所以
最低0.47元/天 解锁文章
967
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
