Redis与数据库一致性

Redis与数据库一致性

在高并发系统中，Redis作为缓存与数据库的配合使用几乎是标配，但两者的数据一致性问题却常常成为开发与面试中的焦点。

本文将拆解业界最常用、最可靠的“缓存与数据库一致性方案”，从核心逻辑到并发处理，全方位解析其原理与实践。

一、核心原则：数据库是“唯一数据源”

无论缓存如何设计，数据库始终是数据的最终存储载体，缓存（Redis）仅作为“加速读取的临时空间”。这一原则是解决一致性问题的前提——所有数据变更必须先保证数据库的准确性，再同步处理缓存。

二、最经典方案：“先更库，再删缓存”

这一方案源于“缓存旁路模式（Cache Aside Pattern）”的变种，是平衡性能与一致性的最优解，具体流程如下：

1. 读取操作（Read）：缓存优先，未命中则回写

• 先查询Redis，若命中则直接返回结果；
• 若未命中，查询数据库，将结果写入Redis（并设置合理过期时间），再返回。

作用：通过缓存减少数据库访问压力，过期时间则为数据一致性提供“兜底保障”——即使缓存未及时更新，也会在过期后自动加载最新数据。

2. 插入操作（Create）：先存库，再写缓存

• 先将数据插入数据库，确保数据落地；
• 直接将数据写入Redis（无需先查缓存）。

理由：新插入的数据在Redis中一定不存在，直接写入可避免首次读取时的“缓存未命中”，提升性能。

3. 更新操作（Update）：先更库，再删缓存

• 先更新数据库，保证底层数据最新；
• 删除Redis中对应的缓存键（而非直接更新缓存）。

关键逻辑： 删除缓存而非更新缓存，是为了避免“并发更新冲突”——若两个请求同时更新数据，直接更新缓存可能导致“旧值覆盖新值”。而删除缓存后，后续读取会自动从数据库加载最新数据并重建缓存，确保一致性。

4. 删除操作（Delete）：先删库，再删缓存

• 先从数据库中删除数据，彻底移除源数据；
• 删除Redis中对应的缓存键。

注意：此处的“删缓存”是为了避免缓存残留旧数据。即使删除数据库后缓存删除失败，过期时间也会在未来清除旧缓存，最终保证数据一致。

三、并发场景：如何保证安全？

高并发下，多个请求同时操作同一数据时，需通过“数据库锁”+“缓存幂等性”确保安全：

1. 数据库层面：用乐观锁防脏写

• 在数据表中添加version字段（版本号），每次更新时：
  1. 先查询数据获取当前version（如version=3）；
  2. 执行更新：UPDATE ... SET ..., version=4 WHERE id=? AND version=3；
  3. 检查影响行数：若>0则成功；若=0说明并发冲突，自旋重试（限制重试次数）。

优势：乐观锁通过版本号判断冲突，而非阻塞读取，性能远高于悲观锁（如行锁），适合高并发场景。

2. 缓存层面：利用删除操作的幂等性

• Redis的del key操作天然幂等——删除不存在的键不会产生副作用。
• 即使多个请求同时删除同一缓存，也不会导致数据不一致，避免了并发操作的异常。

3. 极端情况：异步重试兜底

若数据库更新成功，但缓存删除失败（如网络波动），可通过“异步队列”记录删除任务，后台线程不断重试，直到缓存删除成功。这一机制确保了“最终一致性”。

四、为什么这是最优解？

1. 简单可靠：无需复杂的分布式事务，仅通过“先操作数据库，再处理缓存”的顺序即可避免大部分一致性问题；
2. 性能均衡：删除缓存比更新缓存更轻量，且乐观锁对读取操作无阻塞，兼顾性能与安全性；
3. 普适性强：适用于绝大多数业务场景（如电商商品、用户信息等），仅在金融级强一致场景需额外补充（如分布式锁）。