Cache Design
Last updated
Was this helpful?
Last updated
Was this helpful?
From 58沈剑 架构师之路 1 week ago
架构师之路年终总结（五）-缓存篇
缓存是互联网系统架构中必不可少的一环，之前花大精力系统性的写了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，读从库把旧数据存入缓存的情况。此时怎么办呢？遂引出了下一篇文章。
这个缓存系列10篇，希望整体的思路是清晰的。
架构师之路-分享通俗易懂的技术文章
推荐阅读：
思路比结论重要。
帮忙转发、收藏、好看一下。
6.《》 缓存与数据库的不一致，本质是由主从数据库延时引起的，有没有办法优化主从数据库的一致性呢？遂引出了下一篇文章。
7.《》 文章提出了三种优化方案，最后一个方案挺有意思，一个很巧妙的方法。
8.番外篇 《》 这是一篇聊思路的文章，技术人，不要只会使用，知其然并知其所以然。
《》
《》
《》
《》
