目录
  • 一、背景和现象
  • 二、分析
  • 三、排查

一、背景和现象

项目是php开发的,点击登录的时候就根据随机数生成了二维码,缓存在了redis。用户用微信扫描了二维码分析出需要请求的链接,然后微信浏览器就请求了服务器,服务器通过了随机数认证。正当请求了之后,服务器就拿服务器找出来的的APPID去微信服务器请求。微信准许登陆,服务器修改状态。这个时候websocket服务器修改了状态,把修改状态的事告诉浏览器,浏览器变更状态。如果没有websocket的情况下,浏览器不断的询问服务器是否修改了状态,不能设置得太频繁所以慢。扯远了,这里关键就是说生成的二维码一直在变,不知道怎么回事。redis+sentinel+haproxy的模型做好了,就切换到项目使用。可以打开页面,本以为完全正常,谁知道在二维码登录的时候,二维码一直在刷新。

二、分析

用户在页面上请求,二维码就生成存在redis里面。页面在获取,获取不到就继续请求。问题可能出现在redis的读写权限上面。

三、排查

1、把redis的配置指向之前用的redis,空出redis集群来调试。通过haproxy登录redis,模拟真实场景,然后用set命令。定义了一个键值。在用get读取出来,能读出值。说明在haproxy上读写都不成问题。

redis调用二维码时的不断刷新排查分析

redis调用二维码时的不断刷新排查分析

既然在用命令行读写没问题,可以试试用PHP读写有没有问题。

2、编辑PHP脚本,执行。

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,可以http://www.cppcns.com确定是不是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/timezoneOiqxLVfj -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调用二维码不断刷新排查的资料请关注我们其它相关文章!