面试题：缓存设计 - 高并发场景下缓存更新策略

Question

在高并发场景下，有哪些常见的缓存更新策略，各自的优缺点是什么？请举例说明如何根据业务场景选择合适的缓存更新策略。

Answer 1

常见缓存更新策略及优缺点

1. 先更新数据库，再更新缓存
   • 优点：逻辑简单，容易理解和实现。
   • 缺点：在高并发场景下，可能出现缓存和数据库数据不一致问题。例如两个请求同时更新数据，请求A更新数据库后，请求B也更新数据库，此时请求B先更新缓存，请求A后更新缓存，导致缓存中的数据是旧的。
2. 先删除缓存，再更新数据库
   • 优点：相对实现较为简单，能在一定程度上保证数据一致性。
   • 缺点：存在短暂的数据不一致窗口。如果在删除缓存后，更新数据库前，有读请求进来，会从数据库读到旧数据并写入缓存，导致缓存和数据库数据不一致。例如电商商品库存更新场景，在删除库存缓存后，更新数据库库存前，有查询库存请求，就可能读到旧库存并重新缓存。
3. 先更新数据库，再删除缓存
   • 优点：在大多数场景下能保证数据一致性，是较常用的策略。
   • 缺点：在极端情况下（如删除缓存失败），也可能出现数据不一致。比如数据库更新成功，但由于网络等原因缓存删除失败，此时缓存数据就是旧的。
4. 基于订阅binlog异步更新缓存
   • 优点：对业务侵入性小，能保证最终一致性，适合数据一致性要求不是特别高的高并发场景。
   • 缺点：架构复杂，需要引入额外的组件（如canal模拟slave获取binlog），有一定的延迟。例如在新闻资讯类应用，对新闻内容缓存更新允许一定延迟的场景适用。

根据业务场景选择合适策略

1. 读多写少且数据一致性要求极高场景：如银行账户余额查询更新，适合采用先更新数据库，再删除缓存策略，并对删除缓存失败的情况进行重试等补偿机制，以最大程度保证数据一致性。
2. 读多写少且数据一致性要求相对没那么高场景：如商品浏览量统计，可采用基于订阅binlog异步更新缓存策略，利用其对业务侵入小，能保证最终一致性的特点，且对偶尔短暂的数据不一致可接受。
3. 写多读少场景：如后台管理系统对数据的修改，可采用先删除缓存，再更新数据库策略，因其实现简单，虽然存在短暂不一致窗口，但由于写操作多，读操作少，不一致情况影响范围小。