一、背景和現(xiàn)象

項目是PHP開發(fā)的，點擊登錄的時候就根據(jù)隨機數(shù)生成了二維碼，緩存在了redis。用戶用微信掃描了二維碼分析出需要請求的鏈接，然后微信瀏覽器就請求了服務器，服務器通過了隨機數(shù)認證。正當請求了之后，服務器就拿服務器找出來的的APPID去微信服務器請求。微信準許登陸，服務器修改狀態(tài)。這個時候websocket服務器修改了狀態(tài)，把修改狀態(tài)的事告訴瀏覽器，瀏覽器變更狀態(tài)。如果沒有websocket的情況下，瀏覽器不斷的詢問服務器是否修改了狀態(tài)，不能設置得太頻繁所以慢。扯遠了，這里關鍵就是說生成的二維碼一直在變，不知道怎么回事。redis+sentinel+haproxy的模型做好了，就切換到項目使用?？梢源蜷_頁面，本以為完全正常，誰知道在二維碼登錄的時候，二維碼一直在刷新。

二、分析

用戶在頁面上請求，二維碼就生成存在redis里面。頁面在獲取，獲取不到就繼續(xù)請求。問題可能出現(xiàn)在redis的讀寫權限上面。

三、排查

1、把redis的配置指向之前用的redis，空出redis集群來調試。通過haproxy登錄redis，模擬真實場景，然后用set命令。定義了一個鍵值。在用get讀取出來，能讀出值。說明在haproxy上讀寫都不成問題。

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

2、編輯PHP腳本，執(zhí)行。

<?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)
?>

執(zhí)行結果，

如此一來，PHP讀寫也不成問題。那就用apache執(zhí)行看看，

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

3、其實可以先不做以上兩個步驟的排查。都還沒確定是不是真的是redis的問題。這一步找到集群中的master，然后直接在項目的配置文件中設置指向master，這樣就避開了haproxy，可以確定是不是haproxy的問題。

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

4、那就用同樣的方法創(chuàng)建一個redis，打上去看有沒有問題。因為這種方式跟平時的網(wǎng)絡方式有點不同。首先去配置文件的目錄復制配置文件，改端口。創(chuàng)建了之后改項目配置指向的時候，發(fā)現(xiàn)問題還在，那就可以排除集群的兼容性?？赡苁且驗閔ost="net”的這種網(wǎng)絡方式。

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

發(fā)現(xiàn)問題依舊?，F(xiàn)在也可以暫時排除host="net”這種網(wǎng)絡方式的問題。和原來那種不同的只是映射的端口，那就是這個端口的問題了。

6、排查到這一步，問題漸漸冒出來了。應該是5268這個端口已經(jīng)被綁定，換其他端口都不行?；蛘呤桥渲梦募壎ǎ蛘呤谴a綁定。配置文件全在我的掌握中，這個可以排除。因為在正式環(huán)境是用6379這個端口，那么代碼綁定這個也排除了。做這樣一種假設，項目對redis的請求可以跟著我的配置隨時變，但是swoole沒重啟一次就固定一次。

先不想那么多，趕緊重啟websocket服務器，問題果然沒了。

原來是頁面請求二維碼的時候代碼就生成，存在了redis里面。但是websocket從redis里面一直沒有獲取到，因為他的端口一直是舊的那個，頁面的隨機數(shù)一直都是在redis找不到一樣的，所以一直刷新，如此循環(huán)。重啟了swoole了之后，他請求的那個redis也是配置文件里面最新的，所以能成功在redis找到和瀏覽器一樣的隨機數(shù)。此次排除到，我的服務都，沒有問題。倒是曲折的排查過程更豐富我的邏輯思路。

以上就是redis調用二維碼時的不斷刷新排查分析的詳細內容，更多關于redis調用二維碼不斷刷新排查的資料請關注腳本之家其它相關文章！