系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
前面讲的都是缓存和数据库在一起的情况，但有时候部分业务场景是只有缓存而没有数据库的，比如说微信的access_token获取的场景：
微信对调用方都需求一个access_token，只有携带这个token，才能调用接口token是具有有效期的（微信的7200s，两小时），如果token失效，那么调用方应该重新去申请token也可以在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，不停地失效这样子的诡异情况。
递归调用的问题在于，申请token这一操作由请求本身来完成（它发现失效就自己去请求，调用某个方法也属于是它自己去请求），我们可以将token的申请单独拎出来进行管理，设置一个专门管理token缓存的服务。 而且可以使用影子主技术来保证它的高可用。
那么这里又引入了两个新问题：
它违背了淘汰缓存而不是修改缓存这一模式使用和修改两个服务依赖于一个缓存实例，存在耦合但任何脱离业务的架构都是耍流氓
在这个案例里，读写服务耦合于一个缓存是更好的设计，它避免了并发更新带来的token相互失效的问题。
因为token不存储在数据库当中，修改缓存而不是淘汰也没有关系。
上一篇回顾：【成为架构师3-17】缓存：数据一致性优化二次淘汰法 下一篇更精彩：【成为架构师3-19】缓存：究竟是选择redis还是memcache
