对服务器端缓存故障的处理方法的体会

发布时间：2023-03-31 11:14:23 所属栏目：经验来源：

导读：缓存失效情况举例

看下这个段位代码：

local value = get _ from _ cache(key)

If not value then

value = query _ db(sql)

set _ to _ cache(value， timeout ＝ 100)

end

return value

为

缓存失效情况举例

看下这个段位代码：

local value = get _ from _ cache(key)

If not value then

value = query _ db(sql)

set _ to _ cache(value， timeout ＝ 100)

end

return value

为什么会出现峰值呢？想象一下，在cache失效的瞬间，如果并发请求有1000条同时到了 query_db(sql) 这个函数会怎样？没错，会有1000个请求打向数据库。这就是缓存失效瞬间引起的风暴。它有一个英文名，叫 "dog-pile effect"。

怎么解决？自然的想法是发现缓存失效后，加一把锁来控制数据库的请求。具体的细节，春哥在lua-resty-lock的文档里面做了详细的说明，我就不重复了，请看这里。多说一句，lua-resty-lock库本身已经替你完成了wait for lock的过程，看代码的时候需要注意下这个细节。

代码侵入性比较强，需要双写两份存储，任何对DB的数据变更，都需要同时更新缓存，代码层面后期可维护程度不高

用户请求线程里同步调用缓存，对缓存存在强以来，遇到缓存超时等异常时，没有办法做到有效的重试，遇到异常给用户返回系统错误、操作失败等信息，严重影响用户体验

RDS数据订阅消费，轻松解决缓存失效

在这个架构里面，缓存更新流程如下：

1.业务完成DB更新后即返回请求

2.数据订阅通过日志解析方式实时解析并订阅DB的增量更新数据，当发现DB有数据更新时，将增量数据推送给下游消费者

3.下游消费业务一旦接收到增量更新数据，即调用消费线程进行缓存更新

（编辑：汽车网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!