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

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

二、分析

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

三、排查

1、把redis的配置指向之前用的redis，空出redis集群來調(diào)試。通過haproxy登錄redis，模擬真實(shí)場景，然后用set命令。定義了一個(gè)鍵值。在用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); //結(jié)果：bool(true)
?>

執(zhí)行結(jié)果，

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

同樣沒問題。暫時(shí)排除讀寫權(quán)限問題。

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

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

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

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、用以前端口映射的那種方式新建一個(gè)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)問題依舊。現(xiàn)在也可以暫時(shí)排除host="net”這種網(wǎng)絡(luò)方式的問題。和原來那種不同的只是映射的端口，那就是這個(gè)端口的問題了。

6、排查到這一步，問題漸漸冒出來了。應(yīng)該是5268這個(gè)端口已經(jīng)被綁定，換其他端口都不行。或者是配置文件綁定，或者是代碼綁定。配置文件全在我的掌握中，這個(gè)可以排除。因?yàn)樵谡江h(huán)境是用6379這個(gè)端口，那么代碼綁定這個(gè)也排除了。做這樣一種假設(shè)，項(xiàng)目對redis的請求可以跟著我的配置隨時(shí)變，但是swoole沒重啟一次就固定一次。

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

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

以上就是redis調(diào)用二維碼時(shí)的不斷刷新排查分析的詳細(xì)內(nèi)容，更多關(guān)于redis調(diào)用二維碼不斷刷新排查的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論