微信开发中遇到的access_token坑 ,access_token失效和刷新

这真是一个巨大的坑,为了避免以后踩到同样的坑和帮助刚接触这块的同学快速脱坑,我花了些时间研究问题的来龙去脉,提供了一个不太完美的解决方案,以及未来规划的完美解决方案。

问题现象

在开发微信jssdk的图像接口功能时,测试环境和回归环境都ok。但是更新到预发布环境后,功能就异常了,一直报图片下载失败。最后快到发布时间时,功能又恢复正常了。于是按照常规流程进行了发布。过了两天,收到线上反馈的问题:用户刚开始还能正常传图,用着用着就突然报错说传图失败,然后就一直不能用了。我们在测试环境模拟测试,功能又是正常的:(

查找原因

这种偶现的问题一般都很难迅速定位到具体原因,而且本地和测试环境正常,预发布环境和线上异常,但是又不能进行调试。于是只能根据代码逻辑进行猜测性判断和尝试修复,中间走了大量的弯路,最后发现,删除存储access_token的redis值,再使用时功能正常。

技术分析

问题暂时解决了,但这不是长久之计。于是我花了点时间阅读官方文档,发现这果真是个大坑啊!官方文档原文如下:

第一个红色框里的内容,我测试了三次,第一次连续请求13遍,access_token发生了变化;第二次连续请求12遍,access_token发生了变化;第三次连续请求19遍,access_token发生了变化。(坑一)

第二个红色框里的内容,我们有开发环境,测试环境,回归环境,预发布环境,正式环境,都是同一套代码,同一个微信号,相当于每个环境都是单独的中控服务器。(坑二)

现场还原

搞清楚问题后,我们通过一些手段尝试性的触发问题现象:

1、测试环境下,清空access_token的redis数据。

2、正常测试,功能ok,查看access_token的redis内容,这里假设值为A。

3、手动调用接口刷新access_token,大概十几次后,值变化为B。

4、再次正常测试,发现功能异常(因为此时存储在redis的access_token已经过期)。

5、清空access_token的redis数据,再次测试,功能又恢复正常。

现在问题终于变成必现的了:)

解决方案

现在我们搞清楚问题的原因是存储在redis的access_token可能在很短的时间内过期(因为有太多中控服务器啦),但是我们一般设置的有效期都接近或等于7200s,这就导致一旦出现问题的话,如果不清理redis,问题就会持续2小时左右,这简直就是灾难!

目前想到的比较理想的解决方案就是:服务器发现功能异常时,刷新access_token并更新redis,然后再次调用接口。这种容错机制本来是微信的事-_-!

未来规划

正如开头所说,这的确是个巨坑,未来只能期望微信获取access_token的接口能够完善:

1、说好的2小时过期时间,就得保证2小时内不过期

2、返回的过期时间字段为还剩多少秒过期,而不是每次都返回7200s

然而微信并没有

你可能感兴趣的:(微信)