本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
这两年的面试，缓存基本上是必考的知识点。而一致性又是重中之重，很多人都是在这个知识点上被难住了。今天，我们一起来简单说说缓存一致性之Cache Aside（旁路缓存）模式。
场景的缓存模式，一般有 3 种：
Cache Aside（旁路缓存）、Read/Write Through（读写穿透）、Write Behind Caching（异步缓存写入）。
缓存模式，简单来说就是利用时间局限性原理，通过空间换时间来达到加速数据获取的目的。
缓存的读写性能很高，预热快，在数据访问存在性能瓶颈或遇到突发流量，系统读写压力大增时，可以快速部署上线，同时在流量稳定后，也可以随时下线，从而使系统的可扩展性大大增强。
但是，在系统中引入缓存后，会增加系统的复杂度。其中，我们今天要讲的一致性就是其中的缓存付出的一个代价。
Cache Aside 模式中，业务应用方对于写，是更新 DB 后，直接将 key 从 cache 中删除，然后由 DB 驱动缓存数据的更新；而对于读，是先读 cache，如果 cache 没有，则读 DB，同时将从 DB 中读取的数据回写到 cache。
这种模式的特点是，业务端处理所有数据访问细节，同时利用 Lazy 计算的思想，更新 DB 后，直接删除 cache 并通过 DB 更新，确保数据以 DB 结果为准，则可以大幅降低 cache 和 DB 中数据不一致的概率。
如果没有专门的存储服务，同时是对数据一致性要求比较高的业务，或者是缓存数据更新比较复杂的业务，这些情况都比较适合使用 Cache Aside 模式。微博发展初期，不少业务采用这种模式，这些缓存数据需要通过多个原始数据进行计算后设置。在部分数据变更后，直接删除缓存。同时，使用一个 Trigger 组件，实时读取 DB 的变更日志，然后重新计算并更新缓存。如果读缓存的时候，Trigger 还没写入 cache，则由调用方自行到 DB 加载计算并写入 cache。
旁路缓存模式很简单，但是其中的细节，基本上能难倒一大批人！不管是 Redis 还是 Memcached 用起来感觉很简单，但是当涉及到一致性问题的时候，总是没有完美的方案，那是因为高性能和强一致性从来都是有冲突的！
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » 缓存一致性之Cache Aside（旁路缓存）模式