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

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

二、分析

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

三、排查

1、把redis的配置指向之前用的redis，空出redis集群來(lái)調(diào)試。通過(guò)haproxy登錄redis，模擬真實(shí)場(chǎng)景，然后用set命令。定義了一個(gè)鍵值。在用get讀取出來(lái)，能讀出值。說(shuō)明在haproxy上讀寫(xiě)都不成問(wèn)題。

既然在用命令行讀寫(xiě)沒(méi)問(wèn)題，可以試試用PHP讀寫(xiě)有沒(méi)有問(wèn)題。

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é)果，

如此一來(lái)，PHP讀寫(xiě)也不成問(wèn)題。那就用apache執(zhí)行看看，

同樣沒(méi)問(wèn)題。暫時(shí)排除讀寫(xiě)權(quán)限問(wèn)題。

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

問(wèn)題也沒(méi)有解決，那就只能先排除haproxy的問(wèn)題了。難道是redis集群的問(wèn)題？

4、那就用同樣的方法創(chuàng)建一個(gè)redis，打上去看有沒(méi)有問(wèn)題。因?yàn)檫@種方式跟平時(shí)的網(wǎng)絡(luò)方式有點(diǎn)不同。首先去配置文件的目錄復(fù)制配置文件，改端口。創(chuàng)建了之后改項(xiàng)目配置指向的時(shí)候，發(fā)現(xiàn)問(wè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)問(wèn)題依舊?，F(xiàn)在也可以暫時(shí)排除host="net”這種網(wǎng)絡(luò)方式的問(wèn)題。和原來(lái)那種不同的只是映射的端口，那就是這個(gè)端口的問(wèn)題了。

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

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

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

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

最新評(píng)論