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

栏目: IT技术 · 发布时间: 5年前

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

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

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