在负载均衡情况下,释放掉后端服务器后,会话请求还一直尝试之前的ip。请问是什么原因?
[ error ] [2]stream_socket_client(): unable to connect to tcp://172.19.191.91:2918
这台172.19.191.91 gateway都已经释放了, 重启主服务器,重启gateway服务器,重启这台服务器
还一直报这个错,配置文件有缓存吗?
这个应该是SLB层转发策略或者健康配置检查的设定有问题
之前分布式部署用的是多台Gateway,多台BusinessWorker,觉得不合理(主从都配置了一样的)。
现在的做了如下配置: SLB层已经做了配置,/wss 的请求全部到主服务器,主服务器配置Gateway;4台从服务器只配置BusinessWorker。 重启了所有服务(线上的)。
问题是: 主服务器Gateway端口已改成4000, 主从服务器都已重启, 4台从服务器还是有非常多的报错日志:沿用之前的配置逻辑,[ error ] [2]stream_socket_client(): unable to connect to tcp://172.19.191.x:2918
4台从服务器的报错请求 172.19.191.x:2918 是之前遗留的? 都8个小时了,还在报错。
如果是转发策略或者健康检查问题,应该体现在最新的配置上,4000之类的端口问题。
2918端口是gateway机器的的内部监听端口吧? 以及根据描述,这么看应该不是SLB这边的问题。 按理说不论是下线gateway集群的服务器还是下线businessworker集群的服务器,任意一方都能自动感知这一事件并自动切断与对方的通信,你尝试把 register 服务也重启下试试看。
register服务 Gateway(端口改成了4000)都配置在主服务器上;从服务器只配置BusinessWorker。 主从服务器的workman,php-fpm,nginx都重启了。一直找不到报错的缘由,报错逻辑还是几小时前的配置。
底层有什么配置缓存吗?
@614: 2918端口是几个小时之前的配置,当时主从都配了gateway
先确定好这个问题:原来配置的gateway的2918,即现在的4000是gateway的对外暴露的监听端口啊? 如果是这样那么从服务器 businessworker 为什么要连接这个端口呢?
之前是:1主4从都配有gateway,暴露的监听端口是29xx; 修改之后只有1主服务器gateway的4000端口对外监听。我也是纳闷的问题是:从服务器 businessworker为什么还一直去连接29xx端口。
@614:1天了,从服务器 businessworker为什么还一直去连接29xx端口,能帮我看看吗
你抓包看下谁在连
@614:我看了日志,外网的真实用户,ip都不一样。这个还有缓存或者其他什么原因吗?
@614:就算是用户保持在聊天室不操作,收到服务器的报错响应,会重连,连到SLB,SLB分配到新的gateway,暴露的端口只有新的40xx,为什么是1天前的配置监听端口29xx
1、gatewayworker 本身没有什么额外的配置缓存类的东西,各端的通信地址均交由register服务托管,上线或下线服务都是实时更新的; 2、综合上下文看,前面有SLB这层,那么这个gateway端口就不应该对外暴露啊,应该只暴露给SLB就好。 3、没有具体上下文,一切都不好说,日志是一方面,根据你前后的各种错误提示,建议你最好tcpdump 抓包再看看确认是否内网机器或者脚本在连接gateway端口,要么就摘掉机器一步一步摸排,肯定能找出原因。
@614: 非常感谢,用了tcpdump后就没有报错了,难道是局域网拓扑问题
这个应该是SLB层转发策略或者健康配置检查的设定有问题
之前分布式部署用的是多台Gateway,多台BusinessWorker,觉得不合理(主从都配置了一样的)。
现在的做了如下配置:
SLB层已经做了配置,/wss 的请求全部到主服务器,主服务器配置Gateway;4台从服务器只配置BusinessWorker。
重启了所有服务(线上的)。
问题是:
主服务器Gateway端口已改成4000,
主从服务器都已重启,
4台从服务器还是有非常多的报错日志:沿用之前的配置逻辑,[ error ] [2]stream_socket_client(): unable to connect to tcp://172.19.191.x:2918
4台从服务器的报错请求 172.19.191.x:2918 是之前遗留的? 都8个小时了,还在报错。
如果是转发策略或者健康检查问题,应该体现在最新的配置上,4000之类的端口问题。
2918端口是gateway机器的的内部监听端口吧? 以及根据描述,这么看应该不是SLB这边的问题。
按理说不论是下线gateway集群的服务器还是下线businessworker集群的服务器,任意一方都能自动感知这一事件并自动切断与对方的通信,你尝试把 register 服务也重启下试试看。
register服务 Gateway(端口改成了4000)都配置在主服务器上;从服务器只配置BusinessWorker。
主从服务器的workman,php-fpm,nginx都重启了。一直找不到报错的缘由,报错逻辑还是几小时前的配置。
底层有什么配置缓存吗?
@614: 2918端口是几个小时之前的配置,当时主从都配了gateway
先确定好这个问题:原来配置的gateway的2918,即现在的4000是gateway的对外暴露的监听端口啊? 如果是这样那么从服务器 businessworker 为什么要连接这个端口呢?
之前是:1主4从都配有gateway,暴露的监听端口是29xx; 修改之后只有1主服务器gateway的4000端口对外监听。我也是纳闷的问题是:从服务器 businessworker为什么还一直去连接29xx端口。
@614:1天了,从服务器 businessworker为什么还一直去连接29xx端口,能帮我看看吗
你抓包看下谁在连
@614:我看了日志,外网的真实用户,ip都不一样。这个还有缓存或者其他什么原因吗?
@614:就算是用户保持在聊天室不操作,收到服务器的报错响应,会重连,连到SLB,SLB分配到新的gateway,暴露的端口只有新的40xx,为什么是1天前的配置监听端口29xx
1、gatewayworker 本身没有什么额外的配置缓存类的东西,各端的通信地址均交由register服务托管,上线或下线服务都是实时更新的;
2、综合上下文看,前面有SLB这层,那么这个gateway端口就不应该对外暴露啊,应该只暴露给SLB就好。
3、没有具体上下文,一切都不好说,日志是一方面,根据你前后的各种错误提示,建议你最好tcpdump 抓包再看看确认是否内网机器或者脚本在连接gateway端口,要么就摘掉机器一步一步摸排,肯定能找出原因。
@614: 非常感谢,用了tcpdump后就没有报错了,难道是局域网拓扑问题