缓存一致性之Cache Aside（旁路缓存）模式

这两年的面试，缓存基本上是必考的知识点。而一致性又是重中之重，很多人都是在这个知识点上被难住了。今天，我们一起来简单说说缓存一致性之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 用起来感觉很简单，但是当涉及到一致性问题的时候，总是没有完美的方案，那是因为高性能和强一致性从来都是有冲突的！

： » 缓存一致性之Cache Aside（旁路缓存）模式