缓存的双写一致性实现方案

对于实时性要求不高的数据，在 Redis 作为缓存的情况下，保证 Redis 和数据库数据的一致性，可以选择缓存更新策略，常见的方案包括：

1. Cache Aside（旁路缓存，推荐）

适用场景：数据读取多、实时性要求不高的场景（比如商品详情、用户信息等）。

工作流程

查询数据：
- 先查 Redis，如果缓存命中，直接返回。
- 如果缓存未命中（Cache Miss），则查询数据库。
更新缓存：
- 将数据库查询结果写入 Redis，并设置过期时间（TTL）。
修改数据：
- 先更新数据库，再删除 Redis 缓存（而不是直接更新 Redis）。
下次查询：
- 由于缓存被删除，下一次请求会触发数据库查询，并重新写入缓存。

为什么删除缓存而不是更新缓存？

数据库和 Redis 更新非原子，可能导致缓存和数据库数据不一致。
延迟双删策略：
- 第一次删除缓存（更新数据库后）。
- 短暂延迟（如 500ms）后，再次删除缓存，确保高并发场景下缓存不会被旧值回写。

示例代码

// 读取数据
public String getDataFromCache(Long id) {String key = "data:" + id;String value = redisTemplate.opsForValue().get(key);if (value != null) {return value; // 直接返回缓存数据}// 缓存未命中，查询数据库value = database.queryById(id);// 写入 Redis，并设置过期时间redisTemplate.opsForValue().set(key, value, Duration.ofMinutes(10));return value;
}// 更新数据
public void updateData(Long id, String newValue) {// 先更新数据库database.updateById(id, newValue);// 删除 Redis 缓存redisTemplate.delete("data:" + id);// 延迟 500ms 再次删除，防止并发问题new Timer().schedule(new TimerTask() {@Overridepublic void run() {redisTemplate.delete("data:" + id);}}, 500);
}

优点

✅ 适用于读多写少的业务场景，能有效减少数据库压力。
✅ 避免缓存和数据库数据不一致的问题（先删缓存）。
✅ 结合延迟双删策略，在高并发情况下也能减少不一致。

2. Write Through（写穿透）

适用场景：读写比例均衡，对一致性要求高的场景。

工作流程

写入数据时：
- 先写入数据库，然后同步更新 Redis。
读取数据时：
- 直接从 Redis 读取数据，不需要查询数据库。

示例代码

public void updateData(Long id, String newValue) {// 先更新数据库database.updateById(id, newValue);// 同步更新 RedisredisTemplate.opsForValue().set("data:" + id, newValue, Duration.ofMinutes(10));
}

优点

✅ 读性能高，数据实时同步，减少不一致问题。
✅ 适用于读写并发均衡的业务（如用户状态、账户余额）。

缺点

❌ 写入数据时，Redis 也要同步更新，增加了写操作的延迟。
❌ 如果 Redis 更新失败，可能导致缓存和数据库数据不一致。

3. Write Behind（异步写回，适用于高吞吐写入场景）

适用场景：写入频繁、对数据实时性要求不高的场景，如日志收集、订单队列等。

工作流程

数据先写入 Redis（不会立刻写数据库）。
后台异步任务（定时任务、MQ 消费者等）批量更新数据库。
当 Redis 数据过期或容量不足时，需要持久化到数据库。

示例代码

public void writeData(Long id, String newValue) {// 先写入 RedisredisTemplate.opsForValue().set("data:" + id, newValue);// 记录变更到队列messageQueue.send("update-db", id);
}// 定时任务（或 MQ 消费者）批量更新数据库
@Scheduled(fixedRate = 5000)
public void batchUpdateDatabase() {List<Long> ids = messageQueue.receive("update-db");if (!ids.isEmpty()) {database.batchUpdate(ids);}
}

优点

✅ 高吞吐写入，减少数据库压力（因为数据库只需批量写入）。
✅ 适用于日志、订单、点击数据等高并发写入的业务。

缺点

❌ 数据持久化到数据库有延迟，不适用于实时性要求高的业务。
❌ 断电或 Redis 故障可能导致数据丢失，需要配合持久化方案（AOF、RDB、MQ）。

4. 总结

方案	适用场景	一致性	读性能	写性能	复杂度
Cache Aside（推荐）	读多写少，数据实时性要求不高（如商品详情）	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐
Write Through	读写比例均衡，数据一致性要求高（如用户状态）	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐
Write Behind	写多读少，允许短时间数据延迟（如日志、订单）	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐