一、背景和現象。
項目是PHP開發的，點選登入的時候就根據随機數生成了二維碼，緩存在了redis。使用者用微信掃描了二維碼分析出需要請求的連結，然後微信浏覽器就請求了伺服器，伺服器通過了随機數認證。正當請求了之後，伺服器就拿伺服器找出來的的APPID去微信伺服器請求。微信準許登陸，伺服器修改狀态。這個時候websocket伺服器修改了狀态，把修改狀态的事告訴浏覽器，浏覽器變更狀态。如果沒有websocket的情況下，浏覽器不斷的詢問伺服器是否修改了狀态，不能設定得太頻繁是以慢。扯遠了，這裡關鍵就是說生成的二維碼一直在變，不知道怎麼回事。redis+sentinel+haproxy的模型做好了，就切換到項目使用。可以打開頁面，本以為完全正常，誰知道在二維碼登入的時候，二維碼一直在重新整理。
二、分析。
使用者在頁面上請求，二維碼就生成存在redis裡面。頁面在擷取，擷取不到就繼續請求。問題可能出現在redis的讀寫權限上面。
三、排查。
1、把redis的配置指向之前用的redis，空出redis叢集來調試。通過haproxy登入redis，模拟真實場景，然後用set指令。定義了一個鍵值。在用get讀取出來，能讀出值。說明在haproxy上讀寫都不成問題。
既然在用指令行讀寫沒問題，可以試試用PHP讀寫有沒有問題。
2、編輯PHP腳本，執行。
<?php
$redis = new redis();
$result = $redis->connect('**.**.**.**', 6379);
$result = $redis->auth('******');
$result = $redis->set('test',"renhaoqiang");
$result = $redis->get('test');
var_dump($result); //結果：bool(true)
?>
執行結果，
如此一來，PHP讀寫也不成問題。那就用apache執行看看，
同樣沒問題。暫時排除讀寫權限問題。
3、其實可以先不做以上兩個步驟的排查。都還沒确定是不是真的是redis的問題。這一步找到叢集中的master，然後直接在項目的配置檔案中設定指向master，這樣就避開了haproxy，可以确定是不是haproxy的問題。
問題也沒有解決，那就隻能先排除haproxy的問題了。難道是redis叢集的問題？
4、那就用同樣的方法建立一個redis，打上去看有沒有問題。因為這種方式跟平時的網絡方式有點不同。首先去配置檔案的目錄複制配置檔案，改端口。建立了之後改項目配置指向的時候，發現問題還在，那就可以排除叢集的相容性。可能是因為host="net”的這種網絡方式。
docker run -d --net="host" -v /etc/localtime:/etc/localtime -v /etc/timezone:/etc/timezone -v /Redis-cluster/5379:/data -v /usr/local/configurefiles/redis-cluster/etc/redis-5379.conf:/usr/local/redis/etc/redis.conf --name redis-5379 **.**.**.**:5000/redis:3.2 redis-server /usr/local/redis/etc/redis.conf
5、用以前端口映射的那種方式建立一個redis，端口5267。
docker run -d -p 5267:6379 -v /etc/localtime:/etc/localtime -v /etc/timezone:/etc/timezone -v /RedisData:/data -v /usr/local/configurefiles/redis/etc:/usr/local/redis/etc --name redis **.**.**.**:5000/redis:3.2 redis-server /usr/local/redis/etc/redis.conf
發現問題依舊。現在也可以暫時排除host="net”這種網絡方式的問題。和原來那種不同的隻是映射的端口，那就是這個端口的問題了。
6、排查到這一步，問題漸漸冒出來了。應該是5268這個端口已經被綁定，換其他端口都不行。或者是配置檔案綁定，或者是代碼綁定。配置檔案全在我的掌握中，這個可以排除。因為在正式環境是用6379這個端口，那麼代碼綁定這個也排除了。做這樣一種假設，項目對redis的請求可以跟着我的配置随時變，但是swoole沒重新開機一次就固定一次。
先不想那麼多，趕緊重新開機websocket伺服器，問題果然沒了。
原來是頁面請求二維碼的時候代碼就生成，存在了redis裡面。但是websocket從redis裡面一直沒有擷取到，因為他的端口一直是舊的那個，頁面的随機數一直都是在redis找不到一樣的，是以一直重新整理，如此循環。重新開機了swoole了之後，他請求的那個redis也是配置檔案裡面最新的，是以能成功在redis找到和浏覽器一樣的随機數。此次排除到，我的服務都，沒有問題。倒是曲折的排查過程更豐富我的邏輯思路。
我的部落格即将搬運同步至騰訊雲+社群，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan