分布式锁-缓存一致性问题-失效模式-编程新知

分布式锁-缓存一致性问题-失效模式

news/2024/10/4 3:32:54/文章来源:https://blog.csdn.net/Flying_Fish_roe/article/details/142007344

分布式锁与缓存一致性问题：失效模式

在分布式系统中，缓存一致性问题是一个复杂且常见的挑战。尤其是当我们使用缓存来加速数据访问时，确保缓存与底层数据库之间的数据一致性变得尤为重要。在实际系统中，由于并发、缓存失效策略以及数据的异步处理，可能会导致缓存和数据库数据不一致，进而影响业务系统的正确性。

为了应对这一问题，分布式锁常常被用来保障在高并发场景下，多个节点对同一数据的更新操作不会发生冲突。分布式锁能够确保只有一个线程或进程能够执行特定的业务逻辑，而其他请求则需要等待锁释放。然而，即便使用了分布式锁，缓存与数据库之间依然可能出现不一致的情况，尤其是在涉及缓存更新的场景中。

1. 缓存与数据库的一致性

缓存与数据库一致性问题常见于以下场景：

写操作时：当应用程序对数据库写入新的数据时，缓存中可能还存有旧数据，如果不及时更新或删除缓存，则可能出现脏读现象。
读操作时：在高并发环境下，多个线程可能会同时访问缓存和数据库，缓存的数据可能已经过期或被更新，但依然被读出，导致脏数据返回给用户。

2. 常见的缓存更新策略

在分布式系统中，缓存一致性通常有以下几种策略：

Cache Aside（旁路缓存模式）：
- 读：应用先从缓存中获取数据，如果缓存中没有命中，则从数据库加载数据，并将数据写入缓存。
- 写：在更新数据时，先更新数据库，然后删除缓存。

这种模式下的常见问题是：当多个并发请求同时操作缓存和数据库时，容易导致数据不一致的问题。
Write Through（写穿缓存模式）：
- 数据的写操作同时写入缓存和数据库，以确保缓存与数据库的一致性。

这种模式的缺点是：每次写操作都涉及缓存更新和数据库操作，可能会增加延迟。
Write Behind（异步写缓存模式）：
- 数据首先写入缓存，缓存更新后异步更新数据库。

此模式的风险在于：如果异步更新失败，数据可能会丢失，且在高并发场景下会出现一致性问题。

3. 失效模式：缓存不一致的典型场景

失效模式是指缓存与数据库出现短暂的不一致状态的典型场景。常见的情况包括：

更新缓存失败：数据库更新成功，但缓存删除或更新失败，导致缓存中存有旧数据。
缓存回源延迟：缓存数据失效后，如果多个请求同时回源数据库更新缓存，可能出现缓存击穿，甚至导致缓存和数据库不一致。
并发读写问题：多个线程并发操作缓存和数据库时，可能导致缓存未及时更新或被覆盖。

4. 分布式锁与缓存一致性问题

在分布式系统中，分布式锁可以在一定程度上解决缓存与数据库的一致性问题，但它也有其局限性。典型的分布式锁与缓存不一致的场景如下：

4.1 更新数据库并删除缓存场景下的并发问题

让我们看一个常见的场景：应用在更新数据库后，会删除缓存，让下一个请求重新从数据库中获取数据并更新缓存。然而，在高并发环境下，这种方式容易产生缓存不一致问题：

场景描述：
1. 线程 A 从缓存中读取到数据。
2. 线程 B 更新了数据库，并删除了缓存。
3. 线程 A 将读取到的旧数据重新写入缓存，覆盖了线程 B 的更新。
导致的问题：线程 B 的更新被覆盖，缓存中的数据成了旧的脏数据。

解决方案：使用分布式锁保证更新数据库和缓存操作的顺序性。下面是具体的步骤：

获取分布式锁。
先更新数据库，再删除缓存。
释放分布式锁。

实现代码示例：

import redis.clients.jedis.Jedis;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;public class CacheConsistencyService {private Jedis jedis;private Lock lock = new ReentrantLock();public CacheConsistencyService(Jedis jedis) {this.jedis = jedis;}// 更新数据库并删除缓存的操作public void updateData(String key, String newValue) {// 加锁，确保更新过程是原子性的lock.lock();try {// 更新数据库updateDatabase(key, newValue);// 删除缓存，确保下一次从数据库读取新的值jedis.del(key);} finally {// 释放锁lock.unlock();}}// 模拟数据库更新private void updateDatabase(String key, String newValue) {System.out.println("Updating database with key: " + key + " and value: " + newValue);}// 从缓存或数据库读取数据public String getData(String key) {// 先从缓存获取String value = jedis.get(key);if (value == null) {// 缓存不存在，从数据库加载value = loadFromDatabase(key);// 更新缓存jedis.set(key, value);}return value;}// 模拟从数据库读取数据private String loadFromDatabase(String key) {System.out.println("Loading data from database for key: " + key);return "DBValueFor" + key;}
}

解释：

使用 ReentrantLock 或 Redis 分布式锁来确保只有一个线程能执行更新操作，从而避免多个线程导致数据不一致问题。
在锁的保护下，更新数据库后立即删除缓存，确保缓存中不会存有过期数据。

4.2 延迟双删策略

为了解决缓存和数据库的并发更新问题，另一种较为常见的策略是延迟双删策略：

策略描述：当更新数据库后，先删除缓存，等待一段时间后再次删除缓存，以避免并发情况下的缓存不一致问题。
实现流程：
1. 更新数据库。
2. 删除缓存。
3. 等待 500ms（可根据业务情况调整）。
4. 再次删除缓存，确保在并发读写情况下，缓存不会保存旧值。

延迟双删策略的代码实现：

public class CacheServiceWithDelayedDeletion {private Jedis jedis;public CacheServiceWithDelayedDeletion(Jedis jedis) {this.jedis = jedis;}// 更新数据库并删除缓存public void updateData(String key, String newValue) {// 更新数据库updateDatabase(key, newValue);// 删除缓存jedis.del(key);// 延迟一段时间再次删除缓存try {Thread.sleep(500); // 等待500ms} catch (InterruptedException e) {Thread.currentThread().interrupt();}// 再次删除缓存jedis.del(key);}// 模拟数据库更新private void updateDatabase(String key, String newValue) {System.out.println("Updating database with key: " + key + " and value: " + newValue);}
}

策略优点：

即使在高并发场景下，也能有效避免旧数据重新被写入缓存的情况。

策略缺点：
延迟的时间窗口设置不当可能会影响缓存的准确性。时间过短，无法解决并发问题；时间过长，影响系统性能。

5. 分布式锁的实现

分布式锁可以使用 Redis 实现，常用的方式有：

Redis 的 SETNX 命令：用于加锁。
Redis 的 Lua 脚本：用于保证锁的原子性释放。

// 加锁
public boolean acquireLock(String key, String requestId, int expireTime) {String result = jedis.set(key, requestId, "NX", "EX", expireTime);return "OK".equals(result);
}// 释放锁
public boolean releaseLock(String key, String requestId) {String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " +"return redis.call('del', KEYS[1]) " +"else return 0 end";Object result = jedis.eval(script, Collections.singletonList(key), Collections.singletonList(requestId));return "1".equals(result.toString());
}