【成为架构师3-18】缓存：并发更新造成token相互失效的问题

系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。

业务场景引入

前面讲的都是缓存和数据库在一起的情况，但有时候部分业务场景是只有缓存而没有数据库的，比如说微信的access_token获取的场景：

1. 微信对调用方都需求一个access_token，只有携带这个token，才能调用接口
2. token是具有有效期的（微信的7200s，两小时），如果token失效，那么调用方应该重新去申请token
3. 也可以在token过期前主动申请，但是只有当前token有效，上一个token会失效

并发更新造成递归申请

如果请求发现缓存里的token过期了，那么它去申请新的token，再把这个token写回缓存，并用此token去进行接口调用。

现在来考虑一种极端情况：

假设有A，B两个请求，A发现token过期了，那么它就去申请token，这里命名为token1，在这个时间内，B自然也发现token过期了，B也去申请token，这里是token2，A获得token1之后把token1写回缓存，再用token1去调用接口，此时就会发现token1也提示过期了，那么它就会再去申请token3。

对于B来说，它申请完token2，把token2写入缓存，用token2去调用接口，发现token2过期了（因为A这个时候申请了token3），它就再去申请token4。

这样子上述过程就陷入了递归调用之中，从外部来看就是不停地申请token，不停地失效这样子的诡异情况。

解决方案

递