并发下access_token存在脏写隐患

[sinchie]

AccessToken类中getToken方法。如果token缓存过期了，就从服务端获得并存到缓存。
假如有三个请求同时发现token已过期，都去微信服务器拿新的token。因为网络是有延迟的，并不能保证最后一个请求就刚好是最后一个存到缓存里。所以有脏写隐患。导致后面的带的都是脏token请求失败。

继续看了下retryMiddleware这个请求中间，如果发现token错误就再去重新获得token。。。感觉这是脏写的无限循环，请求量小了 可能没啥。但是并发多了，很有可能爆出这个隐患。

[overtrue]

嗯，稍后我来搞定它

[odirus]

除了在并发这个问题外。

再补充一个问题（现象），微信 AccessToken 可能会在规定时间（目前是两小时）内出现异常失效的情况（当时为了确认这个问题，专门做了一些测试，并且把服务器上面的日志进行了详细地对比分析，发现的确有这种可能），所以建议提供一种 AcessToken 过期的反馈接口，当业务调用返回 AccessToken 错误的时候，能够进入重新获取 AccessToken 的流程，在这个流程里面统一实现重新获取、高并发脏写的问题 。

[awesee]

@odirus $token = $accessToken->getToken($force_refresh);
getToken 方法有一个参数可以强制刷新，业务调用发现AccessToken失效可以再次请求强制刷新，另外控制好强制刷新频率，比如强制刷新最多5分钟一次。

[greedying]

可以搞个服务，专门去请求token。弄个消息队列啥的。

[overtrue]

脏写其实不存在，我去研究了缓存组件的代码，它其实不会出现锁的问题，> https://github.com/doctrine/cache/blob/master/lib/Doctrine/Common/Cache/FileCache.php#L251-L260

现在的问题其实只是读不到的时候导致的重试增加了 API 调用，这个我考虑增加一个配置，可配置重试次数来解决。

[overtrue]

配置项增加：

• max_retries 最大重试次数，默认2，设置为0 AccessToken 过期不重试

[sinchie]

超哥，脏写隐患还是存在的，缓存组件保证了单次写是原子操作，但还是不够的。
假如三个php进程同时去微信拿token，因为网络原因并不能保证，刚好就是最后一个请求拿到的token，最后一个去存缓存。

[greedying]

其实这里有个问题，就是为什么会有三个php进程去同时拿token呢。应该只交给一个进程去做这件事。

我相信如果请求量大了，做这么一个进程不是问题。请求量小的话，不用管

所谓脏写问题，其实单个组件是没法解决的，因为没法确定使用的缓存类型，也就无法确保缓存的读取和写入是原子的。还是要从架构上解决这个问题。

[sinchie]

@greedying nginx php-fpm模式三个php进程同时去拿token，在并发量稍微大点的时候应该很正常。所以单个组件确实解决不了问题，要从构架上改变。

[overtrue]

@dawniii 如果量大的情况就调整重试次数吧，完全不想重试就改成 0

[sinchie]

$app['access_token'] = function () {
        return new AccessToken(
            $this['config']['app_id'],
            $this['config']['secret'],
            $this['cache']
        );
    };

我的想法是写一个AccessToken子类，并重写getToken方法，再覆盖到容器里。这样就可以使用自己独立的token服务，这个服务单线维护token的获取更新。这样就算是在多台机器部署也不是问题了。

当然流量很小的项目就不用这么做了，或者超哥直接做个接口能重写getToken方法？这样可能更方便。

[overtrue]

getToken & setToken 本来就是 public 的，$app->access_token->getToken(); 即可，重写的话直接创建一个你自己的 AccessToken 类就好了，有这几个方法就好了，3.1 就不打算增加接口了：

public function getToken($forceRefresh = false)
public function getAppId()
public function getSecret()
public function getQueryName()

[ghost]

我也建议是在 cron 里，单进程方式定期更新 AccessToken。而 middleware 的检查只是多一重保险。

[never615]

@greedying gre @overtrue
貌似微信的这个token就算是请求了新的,之前旧的没有过期也不会失效的?这样的话,业务量小其实是没有关系

还有微信会文档就有说,微信有可能主动让token失效,这样的话任何使用token的地方都应该处理token失效然后重新请求这件事,不能单纯依靠缓存时间没过就有效.

并且这中情况的错误响应都是固定的40014,invalid access_token这种.所以是不是?