缓存架构，一篇足够？
缓存是互联网系统架构中必不可少的一环，近一个月，写了一些缓存的文字。
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.《缓存与数据库不一致，怎么办？》
大量的读者反问“为什么不set缓存”，大家可以按照顺序阅读，留言过多，就不一一回复了。
缓存与数据库的不一致，本质是由主从数据库延时引起的，有没有办法优化主从数据库的一致性呢？遂引出了下一篇文章。
7.《主从数据库不一致，怎么办？》
文章提出了三种优化方案，最后一个方案挺有意思，一个很巧妙的方法。
8.番外篇
《到底选redis还是memcache，面试官究竟想考察啥？》
这是一篇聊思路的文章，技术人，不要只会使用，知其然并知其所以然。
这个缓存系列，写了约1个月，兴致勃勃的启动，心情低落的收尾，后续，再换一个话题好了。
希望整体的思路是清晰的，如果有收获，可以赞个鸡腿。