在《究竟先操作缓存，还是数据库?》，有同学在评论提出，相关方案违背了“Cache Aside Pattern”的原则，故今天聊一聊Cache Aside Pattern。

另外，在讨论技术方案时，尽量不说：

“你是错的，应该怎么样”

“facebook不是这样，所以你是错的”

画外音：凭什么facebook就是真理?它的方案只是适合它的业务而已。

说明适用场景，说明来龙去脉，说明前因后果，比具体使用什么方案更重要。

什么是“Cache Aside Pattern”?

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

对于读请求

先读cache，再读db

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

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

如上图：

先从cache中尝试get数据，结果miss了

再从db中读取数据，从库，读写分离

最后把数据set回cache，方便下次读命中

画外音：这一点上，与《究竟先操作缓存，还是数据库?》说的是一致的。

对于写请求

淘汰缓存，而不是更新缓存

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

如上图：

(1)第一步要操作数据库，第二步操作缓存

画外音：这一点上，与《究竟先操作缓存，还是数据库?》说的不一致，也是评论反驳比较激烈的地方。

(2)缓存，采用delete淘汰，而不是set更新

画外音：这一点上，与《缓存，究竟是淘汰，还是修改?》说的是一致的。

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

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

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

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

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

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

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

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

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

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

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

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

写请求淘汰了缓存

写请求操作了数据库(主从同步没有完成)

读请求读了缓存(cache miss)

读请求读了从库(读了一个旧数据)

读请求set回缓存(set了一个旧数据)

数据库主从同步完成

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

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

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

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

修改数据库成功了

淘汰缓存失败了

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

如何解决这类问题呢?

答：详见《究竟先操作缓存，还是数据库?》。

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