【高并发基础】Cache Aside 缓存模式背后的思想

1. 前言

《凤凰架构》一书中介绍了一种缓存实现方式 —— Cache Aside。大部分业务开发，不需要缓存与数据库的强一致性，Cache Aside 应该是首选方案。下文根据书中的内容进行整理及理解。文末会给出 Cache Aside 模式的应用。

2. 缓存污染

作者阐述了四种缓存风险：除了缓存击穿、穿透、雪崩，即是 缓存污染
特别的，缓存污染多是由开发者更新缓存不规范造成的。

2.1 造成污染的时机

• 两个请求 A、B并发写数据库且写缓存key k，具体步骤如下
  • 此时 key k 对应的值是 default
  • A 更新数据库，把数据改为 hi
  • B 更新数据库，数据值改为 hello
  • B 更新缓存，缓存的值改为 hello
  • A 更新缓存， 缓存的值改为 hi
  • 至此，缓存中保留的是旧数据 hi, 与数据库的值 hello 不一致，所以就被污染了。

2.2 解决缓存污染

• 更新操作不更新缓存，而是使缓存失效
• 查询的时候如果没有缓存，查询数据库，并填入缓存

2.2.1 优点

• 缓存没有更新操作，只有删除和新增

  • 不再需要考虑多次写操作，触发的缓存写的时序问题

• 只有读数据库才写缓存

  • 多次读操作，数据是安全的

3. Cache Aside 的实现

• 读数据时，先读缓存，如果有就返回。没有再读数据源，将数据放到缓存
• 写数据时，先写数据源，然后让缓存失效

4. Cache Aside 的遗留问题

Cache Aside 不能保 证一致性上绝对不出问题，回顾2.1，制造以下的场景：

• 两个请求 A 查询key，请求B更新key
  • 请求A查询缓存 key, 没有值
  • 请求A查询数据库 key 的值为 hello
  • 请求B更新数据库 key为 hi
  • 请求B清除掉 key 的缓存
  • 请求A写入 key 的缓存为hello
  • 至此，缓存中保留的是旧数据 hello, 与数据库的值 hi 不一致。

书中说这种情况发生的概率是比较少的，但是我认为如果缓存的值是来自于一个慢查询，这可能并不是偶发事件。

5. 一致性问题

Cache Aside 并不能保证强一致性，不然也就不会有 Paxos 这种复杂的共识算法了。

6. 后记

以后缓存的实现，尽量采用 Cache Aside 模式。好处有两个，一个是标准化的实现，大家读代码更流畅。二是职责分离的体现，只有读操作，读不到值才会触发更新缓存，排查其他问题的切入口就变清晰了。