缓存架构设计，从此不再发愁

Posted 2021-04-15 架构师之路

架构师之路年终总结（五）-缓存篇

缓存是互联网系统架构中必不可少的一环，之前花大精力系统性的写了10篇，缓存架构设计相关的文章，欢迎回顾。

1.《》
缓存，可以分为：进程内缓存，缓存服务。文章介绍了：
（1）什么是进程内缓存
（2）进程内缓存的优缺点
（3）进程内缓存保存一致性的3种方案
（4）到底什么时候用进程内缓存

文章也说明，大部分业务场景，不应该用进程内缓存，而应该用缓存服务，而如今最常见的缓存服务是redis和memcache，遂引出了第二篇文章。

2.《》
没有最正确，只有最适合。从源码的角度看，到底啥时候用redis，啥时候用memcache。文章介绍了：
（1）复杂数据结构，选择redis
（2）不要把redis当DB和MQ使用
（3）高可用，真的需要么？
（4）内存分配、虚拟内存、网络模型、线程模型上看redis和memcache的差异与选型。

不管是redis还是memcache，缓存服务，有很多误用，遂引出了第三篇文章。

3.《》
这篇文章介绍了，缓存的一些“值得商榷”的用法：
（1）服务之间，通过缓存传递数据真的合适么？
（2）缓存服务，真的不需要考虑高可用么？
（3）调用方缓存数据，真的合适么？
（4）多个服务，公用缓存实例真的合适么？

了解了常见用法，那么对于缓存的读写，淘汰，一致性有什么常见的问题呢？遂引出了接下来的几篇文章。

4.《》
这个问题问的人很多，《》一文也提到了此问题：
（1）修改缓存，可能会使得代价过高，重复计算
（2）修改缓存，在并发写时，可能数据不一致

结论：应该淘汰缓存，而不是更新缓存。

明确了淘汰，还是修改，接下来需要明确的是：先操作数据库，还是先操作缓存。

5. 先操作数据库，还是先操作缓存?
关于这个问题，行业有两种不同的实践，大家根据自己的业务场景选择使用哪一种。

《》
观点：应该先操作数据库，再淘汰缓存
原因：否则，读写并发会导致数据不一致

《》
观点：应该先淘汰缓存，再操作数据库
原因：否则，原子性被破坏时，会导致数据不一致

不管先操作数据库，还是先操作缓存，其实都解决不了“写后立刻读，脏数据库入缓存”的问题。

什么是“写后立刻读，脏数据库入缓存”问题？
答：发生写请求后（不管是先操作DB，还是先淘汰Cache），在主从数据库同步完成之前，如果有读请求，都可能发生读Cache Miss，读从库把旧数据存入缓存的情况。此时怎么办呢？遂引出了下一篇文章。

6.《》
缓存与数据库的不一致，本质是由主从数据库延时引起的，有没有办法优化主从数据库的一致性呢？遂引出了下一篇文章。

7.《》
文章提出了三种优化方案，最后一个方案挺有意思，一个很巧妙的方法。

8.番外篇
《》
这是一篇聊思路的文章，技术人，不要只会使用，知其然并知其所以然。

这个缓存系列10篇，希望整体的思路是清晰的。

架构师之路-分享通俗易懂的技术文章

推荐阅读：

《》

《》

《》

《》

思路比结论重要。

帮忙转发、收藏、好看一下。