有些成熟的穿透存技术方案，用不着创新，类缓固化下来的使用模式(pattern)，学就完了。篇够例如，穿透存穿透类缓存的类缓使用，“Cache Aside Pattern”就是使用很好的实践沉淀，故今天聊一聊Cache Aside Pattern。篇够

画外音：就好像“设计模式”，穿透存它就是类缓沉淀下来的设计方法。

什么是使用“Cache Aside Pattern”?

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

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

读实践是怎么样的?

对于读请求：

(1)先读cache，再读db;

(2)如果，cache hit，则直接返回数据;

(3)如果，cache miss，则访问db，云服务器并将数据set回缓存;

如上图：

(1)先从cache中尝试get数据，结果miss了;

(2)再从db中读取数据，从库，读写分离;

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

写实践是怎么样的?

对于写请求：

(1)淘汰缓存，而不是更新缓存;

(2)先操作数据库，再淘汰缓存;

如上图：

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

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

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)先操作数据库，再淘汰缓存;

任何技术方案的设计，都是WordPress模板折衷。

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

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