redis呼叫二維條碼時的不斷重新整理排查分析

2022-04-01 13:03:38

一、背景和現象

專案是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找到和瀏覽器一樣的亂數。此次排除到，我的服務都，沒有問題。倒是曲折的排查過程更豐富我的邏輯思路。

以上就是redis呼叫二維條碼時的不斷重新整理排查分析的詳細內容，更多關於redis呼叫二維條碼不斷重新整理排查的資料請關注it145.com其它相關文章！

redis呼叫二維條碼時的不斷重新整理排查分析

目錄

一、背景和現象

二、分析

三、排查

熱門文章