|
|
51CTO旗下网站
|
|
移动端
创建专栏

缓存,并发更新的大坑?

《缓存,究竟是淘汰,还是修改?》发出后,有朋友提到,高并发的情况下,缓存的更新可能存在问题,今天简单聊聊这个话题。

作者:58沈剑|2018-07-06 15:04

缓存,究竟是淘汰,还是修改?》发出后,有朋友提到,高并发的情况下,缓存的更新可能存在问题,今天简单聊聊这个话题。

缓存,并发更新的大坑?

业务场景:

  • 调用第三方服务,例如微信,一般会分配一个token,每次访问接口需要带上这个token;
  • 这个token是有有效期的,当token过期时,需要去重新认证申请;
  • 也可以在token过期前重新申请,但此时旧token会失效。

常见实现方式,如图:

缓存,并发更新的大坑?

  • 把token放在缓存中,每次带上token去调用接口;
  • 如果token过期,需要去申请新token;
  • 申请完新token,需要把新token更新到缓存里。

高并发下可能存在的问题,如图:

  • 取旧token,访问接口,发现token过期;
  • 并发请求,取旧token,访问接口,也发现token过期;
  • 去申请新token1;
  • 并发申请新token2(此时token1会过期);
  • 把token1放入缓存,同时使用token1访问接口(此时token1已经过期),发现token1过期,可能会递归申请新token3(此时token2过期);
  • 把token2放入缓存,同时使用token2访问接口(此时token2已经过期),发现token2过期,可能会递归申请新token4(此时token3过期);

额,高并发请求导致相互失效。

常见解决方案,如图:

  • 线上s1和s2只从缓存读取token
  • 更新token异步,asy-Master定期更新token,避免并发更新
  • 使用shadow-master保证token更新高可用,asy-Master挂了,asy-Backup顶上

潜在缺点:

  • s1/s2/asy-master直接调用同一个缓存实例,如果缓存实例变更,可能需要同步变更,导致耦合。

潜在优化:

  • asy-Master利用多线程,实现在s1/s2里,保证高可用;
  • redis里用一个时间戳表示token的更新时间,更新token时,查看token的时间戳,如果token刚更新过,并发的请求便不再更新。

文字虽短,希望问题描述清楚了,希望大家有收获。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

【编辑推荐】

  1. 如何优雅的「打断」你的线程?
  2. 一分钟理解线程安全
  3. 进程内缓存,究竟怎么玩?
  4. 缓存,你真的用对了么?
  5. 缓存,究竟是淘汰,还是修改?
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多