調用redis的時候二維碼不斷刷新的排查

1、背景和現象。

項目是PHP開發的，點擊登陸的時候就根據隨機數生成了二維碼，緩存在了redis。用戶用微信掃描了二維碼分析出須要請求的連接，而後微信瀏覽器就請求了服務器，服務器經過了隨機數認證。正當請求了以後，服務器就拿服務器找出來的的APPID去微信服務器請求。微信准許登錄，服務器修改狀態。這個時候websocket服務器修改了狀態，把修改狀態的事告訴瀏覽器，瀏覽器變動狀態。若是沒有websocket的狀況下，瀏覽器不斷的詢問服務器是否修改了狀態，不能設置得太頻繁因此慢。扯遠了，這裏關鍵就是說生成的二維碼一直在變，不知道怎麼回事。redis+sentinel+haproxy的模型作好了，就切換到項目使用。能夠打開頁面，本覺得徹底正常，誰知道在二維碼登陸的時候，二維碼一直在刷新。

 

2、分析。

用戶在頁面上請求，二維碼就生成存在redis裏面。頁面在獲取，獲取不到就繼續請求。問題可能出如今redis的讀寫權限上面。

 

3、排查。

一、把redis的配置指向以前用的redis，空出redis集羣來調試。經過haproxy登陸redis，模擬真實場景，而後用set命令。定義了一個鍵值。在用get讀取出來，能讀出值。說明在haproxy上讀寫都不成問題。

 

既然在用命令行讀寫沒問題，能夠試試用PHP讀寫有沒有問題。

二、編輯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執行看看，

一樣沒問題。暫時排除讀寫權限問題。

三、其實能夠先不作以上兩個步驟的排查。都還沒肯定是否是真的是redis的問題。這一步找到集羣中的master，而後直接在項目的配置文件中設置指向master，這樣就避開了haproxy，能夠肯定是否是haproxy的問題。

問題也沒有解決，那就只能先排除haproxy的問題了。難道是redis集羣的問題？

四、那就用一樣的方法建立一個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

五、用之前端口映射的那種方式新建一個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」這種網絡方式的問題。和原來那種不一樣的只是映射的端口，那就是這個端口的問題了。

六、排查到這一步，問題漸漸冒出來了。應該是5268這個端口已經被綁定，換其餘端口都不行。或者是配置文件綁定，或者是代碼綁定。配置文件全在個人掌握中，這個能夠排除。由於在正式環境是用6379這個端口，那麼代碼綁定這個也排除了。作這樣一種假設，項目對redis的請求能夠跟着個人配置隨時變，可是swoole沒重啓一次就固定一次。

先不想那麼多，趕忙重啓websocket服務器，問題果真沒了。

原來是頁面請求二維碼的時候代碼就生成，存在了redis裏面。可是websocket從redis裏面一直沒有獲取到，由於他的端口一直是舊的那個，頁面的隨機數一直都是在redis找不到同樣的，因此一直刷新，如此循環。重啓了swoole了以後，他請求的那個redis也是配置文件裏面最新的，因此能成功在redis找到和瀏覽器同樣的隨機數。這次排除到，個人服務都，沒有問題。卻是曲折的排查過程更豐富個人邏輯思路。

 

 

 

個人博客即將搬運同步至騰訊雲+社區，邀請你們一同入駐：https://cloud.tencent.com/developer/support-plan