Cache Aside Pattern：纠结个啥？旁路缓存就这么用！（第79讲）

《架构师之路：架构设计中的100个知识点》

79.Cache Aside Pattern

有不少朋友问我，缓存到底怎么操作？

有些成熟的技术方案，用不着创新，固化下来的模式（pattern），学就完了。Cache Aside Pattern 就是旁路缓存的行业最佳实践。大部分情况下，照着用就完了。

什么是“Cache Aside Pattern”？

旁路缓存方案的经验实践，这个实践又分读实践，写实践。

画外音：与旁路缓存对应的，是穿透缓存。

读实践是怎么样的？

对于读请求：

图片

1. 先读cache，再读db；

2. 如果，cache hit，则直接返回数据；

3. 如果，cache miss，则访问db，并将数据set回缓存；

写实践是怎么样的？

对于写请求：

图片

1. 淘汰缓存，而不是更新缓存；

2. 先操作数据库，再淘汰缓存；

Cache Aside Pattern为什么建议淘汰缓存，而不是更新缓存？

如果更新缓存，在并发写时，可能出现数据不一致。

图片

如上图所示，如果采用set缓存。

在1和2两个并发写发生时，由于无法保证时序，此时不管先操作缓存还是先操作数据库，都可能出现：

1. 请求1先操作数据库，请求2后操作数据库；

2. 请求2先set了缓存，请求1后set了缓存；

导致，数据库与缓存之间的数据不一致。

所以，Cache Aside Pattern建议，delete缓存，而不是set缓存。

Cache Aside Pattern为什么建议先操作数据库，再操作缓存？

如果先操作缓存，在读写并发时，可能出现数据不一致。

图片

如上图所示，如果先操作缓存。

在1和2并发读写发生时，由于无法保证时序，可能出现：

1. 写请求淘汰了缓存；

2. 写请求操作了数据库（主从同步没有完成）；

3. 读请求读了缓存（cache miss）；

4. 读请求读了从库（读了一个旧数据）；

5. 读请求set回缓存（set了一个旧数据）；

6. 数据库主从同步完成；

导致，数据库与缓存的数据不一致。

所以，Cache Aside Pattern建议，先操作数据库，再操作缓存。

Cache Aside Pattern方案存在什么问题？

如果先操作数据库，再淘汰缓存，在原子性被破坏时：

1. 修改数据库成功了；

2. 淘汰缓存失败了；

导致，数据库与缓存的数据不一致。

Cache Aside Pattern总结：

对于读请求：

1. 先读cache，再读db；

2. 如果，cache hit，则直接返回数据；

3. 如果，cache miss，则访问db，并将数据set回缓存；

对于写请求：

1. 淘汰缓存，而不是更新缓存；

2. 先操作数据库，再淘汰缓存；

潜在问题：

写操作原子性被破坏时，数据库与缓存的数据不一致。

知其然，知其所以然。

思路比结论更重要。

==全文完==

做过架构合集吗？

《流量从10万到10亿，一定会遇到的80个架构问题（8000字长文）》

沈老师，发文频率怎么降低了？

额，我仍是日更，平台更新了推送规则，即使关注也收不到推送。

解决办法：【点架构师之路>点右上角“…”>设为星标】，这样就能第一时间收到啦。

近期架构好文，第一时间收到了吗？

《4类缓存常见误用？（第78讲）》

《慎用！进程内缓存（第77讲）》

《feed流，读扩散，写扩散？（第76讲）》

最近在做什么？

《40岁，创业2个月了，人生总得做点啥...》

创业ing，一年至少50场活动，欢迎大家加入。