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

一、背景和现象

项目是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调用二维码不断刷新排查的资料请关注我们其它相关文章！