天天看點

調用redis的時候二維碼不斷重新整理的排查

一、背景和現象。

項目是PHP開發的,點選登入的時候就根據随機數生成了二維碼,緩存在了redis。使用者用微信掃描了二維碼分析出需要請求的連結,然後微信浏覽器就請求了伺服器,伺服器通過了随機數認證。正當請求了之後,伺服器就拿伺服器找出來的的APPID去微信伺服器請求。微信準許登陸,伺服器修改狀态。這個時候websocket伺服器修改了狀态,把修改狀态的事告訴浏覽器,浏覽器變更狀态。如果沒有websocket的情況下,浏覽器不斷的詢問伺服器是否修改了狀态,不能設定得太頻繁是以慢。扯遠了,這裡關鍵就是說生成的二維碼一直在變,不知道怎麼回事。redis+sentinel+haproxy的模型做好了,就切換到項目使用。可以打開頁面,本以為完全正常,誰知道在二維碼登入的時候,二維碼一直在重新整理。

二、分析。

使用者在頁面上請求,二維碼就生成存在redis裡面。頁面在擷取,擷取不到就繼續請求。問題可能出現在redis的讀寫權限上面。

三、排查。

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

調用redis的時候二維碼不斷重新整理的排查
調用redis的時候二維碼不斷重新整理的排查

既然在用指令行讀寫沒問題,可以試試用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)

?>

調用redis的時候二維碼不斷重新整理的排查

執行結果,

調用redis的時候二維碼不斷重新整理的排查

如此一來,PHP讀寫也不成問題。那就用apache執行看看,

調用redis的時候二維碼不斷重新整理的排查

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

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

調用redis的時候二維碼不斷重新整理的排查
調用redis的時候二維碼不斷重新整理的排查

問題也沒有解決,那就隻能先排除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找到和浏覽器一樣的随機數。此次排除到,我的服務都,沒有問題。倒是曲折的排查過程更豐富我的邏輯思路。

我的部落格即将搬運同步至騰訊雲+社群,邀請大家一同入駐:https://cloud.tencent.com/developer/support-plan

繼續閱讀