数据库缓存一致性问题与解决方案 问题描述 在数据库系统中，为了提升读性能，常引入缓存层（如Redis）来存储热点数据。然而，当数据同时存在于缓存和数据库中时，如何保证用户读取的数据始终是最新的（即缓存与数据库的数据一致性）成为一个关键问题。例如，在更新数据库后，若缓存未同步更新，后续请求可能读到脏数据。 核心挑战 并发操作 ：多个线程或服务同时读写数据库和缓存。 操作原子性 ：数据库更新和缓存更新非原子操作，可能中途失败。 顺序问题 ：先更新缓存还是先更新数据库？顺序不同会导致一致性问题。 解决方案的演进过程 1. 方案一：先更新数据库，再删除缓存（Cache-Aside Pattern） 步骤 ： 应用更新数据库数据。 删除缓存中对应的键（Key）。 后续读请求发现缓存缺失，从数据库加载新数据并回填缓存。 优点 ：简单易实现，避免同时更新缓存的复杂性。 风险 ： 删除缓存失败时，缓存会长期保留旧数据。 并发场景下可能短暂不一致（如读请求在删除缓存后、回填前读到旧值）。 2. 方案二：先删除缓存，再更新数据库 步骤 ： 删除缓存。 更新数据库。 问题 ：高并发时，若线程A删除缓存后，线程B在A更新数据库前读到旧值并回填缓存，会导致缓存永久脏数据。 3. 方案三：延迟双删（针对方案二的问题） 步骤 ： 删除缓存。 更新数据库。 休眠短暂时间（如500ms），再次删除缓存。 目的 ：清除并发过程中可能被回填的旧数据。 缺点 ：休眠时间难以精确设定，降低吞吐量。 4. 方案四：基于数据库事务日志的异步更新（如Canal） 原理 ： 数据库更新后，事务日志（如MySQL的binlog）记录变更。 日志订阅工具（如Canal）解析日志，异步更新缓存。 优点 ：解耦应用与缓存同步逻辑，保证最终一致性。 缺点 ：系统复杂度高，有延迟。 5. 方案五：加分布式锁 步骤 ： 写操作前获取分布式锁。 更新数据库并删除缓存。 读操作若缓存缺失，加锁后从数据库加载数据。 优点 ：强一致性保证。 缺点 ：锁竞争影响性能，需权衡一致性与效率。 总结与选择建议 追求性能 ：优先采用方案一（Cache-Aside），结合重试机制或消息队列补偿删除失败的情况。 强一致性场景 ：使用方案五（分布式锁），但需评估性能损耗。 高并发写场景 ：方案四（异步同步）可降低应用压力，接受短暂延迟。 关键原则 ：根据业务对一致性的要求（强一致性/最终一致性）和性能需求，选择平衡点，并通过监控和重试机制降低故障影响。