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

内容简介：缓存架构设计，从此不再发愁

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

缓存是互联网系统架构中必不可少的一环，之前花大精力系统性的写了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篇，希望整体的思路是清晰的。

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

推荐阅读：

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

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

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

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

思路比结论重要。

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

以上所述就是小编给大家介绍的《缓存架构设计，从此不再发愁》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 还为模拟流量测试发愁吗？！滴滴开源RDebug流量回放工具！
• 你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗？看完图解就不愁了
• 献给还在为涨薪发愁的Java程序员们的一篇文章
• 还在为英语学习发愁吗？身为程序员的你可能需要这样一份“宝典”（上）
• 还在为万圣节穿什么发愁？AI给出的这份穿搭建议你敢试试吗
• 轻松学会HTTP缓存（强缓存，协商缓存）

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。