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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.《主从数据库不一致，怎么办？》
文章提出了三种优化方案，最后一个方案挺有意思，一个很巧妙的方法。

8.番外篇
《到底选redis还是memcache，面试官究竟想考察啥？》
这是一篇聊思路的文章，技术人，不要只会使用，知其然并知其所以然。

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

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

推荐阅读：

《“立体化监控告警平台”-年终总结（一）》

《“区块链与比特币”-年终总结（二）》

《“杀熟杀豪与互联网推荐”-年终总结（三）》

《“读写扩散、消息系统”-年终总结（四）》

思路比结论重要。

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