边缘缓存模式 Cache-Aside Pattern

按照业务需求, 在业务层缓存一定的数据以提升性能. 同时还要保持缓存数据和底层数据的一致性.

解决的问题

业务端通过缓存一定的数据避免重复访问底层, 从而拉升性能. 然而缓存数据和底层数据可能存在不一致, 业务端必须实现一定的缓存失效策略来尽可能保证一致性.

方案

很多缓存系统提供read-through, write-through/write-behind这样的基本操作.

• read-through 就是先读缓存, 没找到就去底层拉数据, 然后更新缓存, 拉升读效率
• write-through/write-behind 就是先写缓存, 如果缓存没命中, 就直接去底层那数据. 如果缓存命中的话, 那么业务线程就更新缓存内的数据, 后台线程把一段时间内积累的更新一次性刷回底层. 拉升写效率

类似这样的缓存系统对业务端都是透明的, 有特殊需求的话, 业务端很可能就要制定自己的失效策略, 以及决策是否使用写时缓存.

read-through

决策问题

• 缓存的TTL 需要根据应用需求配置合理的TTL, 如果太短造成缓存连续失效, 那么这样的缓存就没有存在的意义. 如果太长有可能影响客户的使用体验. 缓存数据的选取也是一个问题, 传统上有LRU Clock-Pro等算法来帮助我们选取需要缓存的数据. 在实际应用中, 静态数据是必然可以被缓存在客户端的, 同时根据业务形态我们可以缓存周期性变化的数据,如一个每日凌晨更新的统计数据表. 类似的更新策略不能太复杂.

• 缓存预分配 是否在应用启动前预分配, 甚至预先拉取数据. 如果这么做可以有效的提升启动时的性能. 在系统复杂低时主动拉取数据, 主动开辟大缓存空间等. 实际实现可能涉及到复杂的策略, 所以需要小心权衡

• 一致性 由于不保证缓存和底层数据一致, 所以部分输出的结果可能是陈旧的, 业务是否能够接受这样的结果?

• 本地缓存共享 在多进程情况下, 本地的多个进程可能都持有同一个数据的缓存. 但缓存内的数据却可能不一致, 这一方面带来了不一致性, 另外一方面也带来了空间上的浪费. 在同一台物理机上的进程是否应该共享缓存. 整个系统因此变的复杂和更难维护是否可以可以接受的?