在 Redis 缓存与后端数据库并存的架构里，要维持两侧数据的一致性，通常采用哪些策略？这些策略各自的适用场景和潜在问题是什么？

回答思路

1. 【回答框架 1】缓存与数据库数据不一致的根本原因是同时存在两份数据副本，更新操作无法原子地覆盖两边。常见的一致性保障方案包括先更新数据库、再删除缓存（Cache Aside），该方案在并发场景下可能因读请求先读到旧数据并回填缓存而导致短暂不一致，业界通常通过延迟双删或设置过期时间来缓解。
2. 【回答框架 2】另一种策略是先更新缓存、再异步或同步更新数据库（Write Behind），可以降低读延迟，但存在数据库更新失败时缓存成为脏数据的风险，通常需要在消息队列或事件总线上做最终一致性补偿。
3. 【回答框架 3】对于强一致要求，可借助分布式锁或事务消息，在更新数据库时同步锁定缓存对应的 key，确保读请求在更新完成前不读到旧值，但代价是吞吐量下降和锁竞争，因此只适合对一致性要求极高的核心链路。
4. 【回答框架 4】方案选择需结合业务的读写比例、对不一致的容忍度和性能预算。若读多写少且允许秒级延迟，优先使用 Cache Aside 加过期时间；若写多或要求强一致，则需引入更重的一致性机制，并通过监控和补偿任务减少残余不一致。
5. 【关键点 1】Cache Aside 模式为当前主流，核心是更新数据库后删除缓存，并依赖缓存过期兜底。
6. 【关键点 2】延迟双删可降低并发下读写交错导致的短期脏数据概率，但无法完全消除。
7. 【关键点 3】分布式锁或事务消息能提供更强一致，但会牺牲性能和复杂度，需结合实际业务收益决定。
8. 【关键点 4】最终一致性方案必须配合缓存过期时间，避免脏数据长期驻留。
9. 【易错点 1】先更新数据库再更新缓存的做法容易产生并发覆盖，不建议采用。
10. 【易错点 2】缓存不存在时并发回填可能击穿缓存，需配合互斥锁或空值缓存缓解。
11. 【易错点 3】依赖单一缓存过期机制并不能保证所有场景下的一致性，只能作为兜底而非主方案。