在缓存系统中&＃xff0c;缓存总有失效的时候&＃xff0c;比如我们经常使用的 Memcache 和 Redis &＃xff0c;都会设置超时时间&＃xff1b;而一旦缓存到了超时时间失效之后&＃xff0c;如果此时再有大量的并发向数据库发起请求&＃xff0c;就会造成服务器卡顿甚至是系统当机。这就是 Dog Pile Effect 。
避免这样的 Dog Pile 效应&＃xff0c;通常有两种方法&＃xff1a;
使用独立的更新进程
使用独立的进程&＃xff08;比如 cron job&＃xff09;去更新缓存&＃xff0c;而不是让 web 服务器即时更新数据缓存。举个例子&＃xff1a;一个数据统计需要每五分钟更新一次&＃xff08;但是每次计算过程耗时1分钟&＃xff09;&＃xff0c;那么可以使用 cron job 去计算这个数据&＃xff0c;并更新缓存。这样的话&＃xff0c;数据永远都会存在&＃xff0c;即使不存在也不用担心产生 Dog Pile 效应&＃xff0c;因为客户端没有更新缓存的操作。这种方法适合不需要即时运算的全局数据。但对用户对象、朋友列表、评论之类的就不太适用。
使用“锁”
除了使用独立的更新进程之外&＃xff0c;我们也可以通过加“锁”&＃xff0c;每次只允许一个客户端请求去更新缓存&＃xff0c;以避免 Dog Pile 效应。
处理过程大概是这样的&＃xff1a;
A 请求的缓存没命中
A 请求“锁住”缓存 key
B 请求的缓存没命中
B 请求需要等待直到“锁”释放
A 请求完成&＃xff0c;并且释放“锁”
B 请求缓存命中&＃xff08;由于 A 的运算&＃xff09;
lua-resty-lock - 基于共享内存的非阻塞锁实现。
首先&＃xff0c;我们先来消除下大家对锁的抗拒&＃xff0c;事实上这把共享内存锁非常轻量。第一&＃xff0c;它是非阻塞的&＃xff0c;也就是说锁的等待并不会导致 NGINX Worker 进程阻塞&＃xff1b;第二&＃xff0c;由于锁的实现是基于共享内存的&＃xff0c;且创建时总会设置一个过期时间&＃xff0c;因此这里不用担心会发生死锁&＃xff0c;哪怕是持有这把锁的 NGINX Worker Crash 了。
那么&＃xff0c;接下来我们只要利用这把锁按如下步骤来更新缓存即可&＃xff1a;
- 检查某个 Key 的缓存是否命中&＃xff0c;如果 MISS&＃xff0c;则进入步骤 2。
- 初始化 resty.lock 对象&＃xff0c;调用 lock 方法将对应的 Key 锁住&＃xff0c;检查第一个返回值&＃xff08;即等待锁的时间&＃xff09;&＃xff0c;如果返回 nil&＃xff0c;按相应错误处理&＃xff1b;反之则进入步骤 3。
- 再次检查这个 Key 的缓存是否命中&＃xff0c;如果依然 MISS&＃xff0c;则进入步骤 4&＃xff1b;反之&＃xff0c;则通过调用 unlock 方法释放掉这把锁。
- 通过数据源&＃xff08;这里特是 Redis&＃xff09;查询数据&＃xff0c;把查询到的结果缓存起来&＃xff0c;最后通过调用 unlock 方法释放当前 Hold 住的这把锁。
具体代码实现请参考&＃xff1a;lua-resty-lock#for-cache-locks
当数据源故障的时候怎么办&＃xff1f;NO_DATA&＃xff1f;
同样&＃xff0c;我们以上面的代码片段为例&＃xff0c;当 Redis 返回出现 err 的时候&＃xff0c;此时的状态即不是 MISS 也不是 NO_DATA&＃xff0c;而这里统一把它归类到 NO_DATA 了&＃xff0c;这就可能会引发一个严重的问题&＃xff0c;假设线上这么一台 Redis 挂了&＃xff0c;此时&＃xff0c;所有更新缓存的操作都会被标记为 NO_DATA 状态&＃xff0c;原本旧的拷贝可能还能用的&＃xff0c;只是可能不是最新的罢了&＃xff0c;而现在却都变成空数据缓存起来了。
那么如果我们能在这种情况下让缓存不过期是不是就能解决问题了&＃xff1f;答案是 yes。
lua-resty-shcache - 基于 ngx.shared.DICT 实现了一个完整的缓存状态机&＃xff0c;并提供了适配接口
恩&＃xff0c;这个库几乎解决了我们上面提到的所有问题&＃xff1a;
- 内置缓存锁实现
- 故障时使用陈旧的拷贝 - STALE
所以&＃xff0c;不想折腾的话&＃xff0c;直接用它就是的。
参考&＃xff1a;
[1] 如何处理 Dog Pile Effect
[2] 浅谈 ngx_lua 在 UPYUN 的应用
京公网安备 11010802041100号