Gateway結合thinkphp，使用很久了，突然發(fā)現一個問題
在負載均衡情況下，釋放掉后端服務器后，會話請求還一直嘗試之前的ip。請問是什么原因？
[ error ] [2]stream_socket_client(): unable to connect to tcp://172.19.191.91:2918
這臺172.19.191.91 gateway都已經釋放了，
重啟主服務器，重啟gateway服務器，重啟這臺服務器
還一直報這個錯，配置文件有緩存嗎？
2個回答
之前分布式部署用的是多臺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個小時了，還在報錯。
如果是轉發(fā)策略或者健康檢查問題，應該體現在最新的配置上，4000之類的端口問題。
-
phpcreeper 2019-11-15
2918端口是gateway機器的的內部監(jiān)聽端口吧？ 以及根據描述，這么看應該不是SLB這邊的問題。
按理說不論是下線gateway集群的服務器還是下線businessworker集群的服務器，任意一方都能自動感知這一事件并自動切斷與對方的通信，你嘗試把 register 服務也重啟下試試看。 -
阿拉丁 2019-11-15
register服務 Gateway（端口改成了4000）都配置在主服務器上；從服務器只配置BusinessWorker。
主從服務器的workman，php-fpm，nginx都重啟了。一直找不到報錯的緣由，報錯邏輯還是幾小時前的配置。 -
-
-
phpcreeper 2019-11-15
先確定好這個問題：原來配置的gateway的2918，即現在的4000是gateway的對外暴露的監(jiān)聽端口??？ 如果是這樣那么從服務器 businessworker 為什么要連接這個端口呢？
-
阿拉丁 2019-11-15
之前是：1主4從都配有gateway，暴露的監(jiān)聽端口是29xx； 修改之后只有1主服務器gateway的4000端口對外監(jiān)聽。我也是納悶的問題是：從服務器 businessworker為什么還一直去連接29xx端口。
-
-
-
-
阿拉丁 2019-11-16
@614:就算是用戶保持在聊天室不操作，收到服務器的報錯響應，會重連，連到SLB，SLB分配到新的gateway，暴露的端口只有新的40xx，為什么是1天前的配置監(jiān)聽端口29xx
-
phpcreeper 2019-11-16
1、gatewayworker 本身沒有什么額外的配置緩存類的東西，各端的通信地址均交由register服務托管，上線或下線服務都是實時更新的；
2、綜合上下文看，前面有SLB這層，那么這個gateway端口就不應該對外暴露啊，應該只暴露給SLB就好。
3、沒有具體上下文，一切都不好說，日志是一方面，根據你前后的各種錯誤提示，建議你最好tcpdump 抓包再看看確認是否內網機器或者腳本在連接gateway端口，要么就摘掉機器一步一步摸排，肯定能找出原因。 -
