聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

穿透类缓存Cache使用,这一篇就够了!

2021-12-24 02:12 浏览: 1929 次 我要评论(0 条) 字号:

有些成熟的技术方案,用不着创新,固化下来的模式(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)先操作数据库,再淘汰缓存;

任何技术方案的设计,都是折衷。
架构师之路-分享可落地的技术文章
相关文章
架构师之路,20年干货精选

希望大家有启示,求帮


网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复