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

Flying_Fish_roe2024-09-13 0:04

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

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

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

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

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

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

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

  1. Cache Aside（旁路缓存模式） ：

    • 读 ：应用先从缓存中获取数据，如果缓存中没有命中，则从数据库加载数据，并将数据写入缓存。

    • 写 ：在更新数据时，先更新数据库，然后删除缓存。

    这种模式下的常见问题是：当多个并发请求同时操作缓存和数据库时，容易导致数据不一致的问题。

  2. Write Through（写穿缓存模式） ：

    • 数据的写操作同时写入缓存和数据库，以确保缓存与数据库的一致性。

    这种模式的缺点是：每次写操作都涉及缓存更新和数据库操作，可能会增加延迟。

  3. Write Behind（异步写缓存模式） ：

    • 数据首先写入缓存，缓存更新后异步更新数据库。

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

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

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

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

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

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

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

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

  • 场景描述 ：

    1. 线程 A 从缓存中读取到数据。

    2. 线程 B 更新了数据库，并删除了缓存。

    3. 线程 A 将读取到的旧数据重新写入缓存，覆盖了线程 B 的更新。

  • 导致的问题：线程 B 的更新被覆盖，缓存中的数据成了旧的脏数据。

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

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

实现代码示例：

java 复制代码 
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. 再次删除缓存，确保在并发读写情况下，缓存不会保存旧值。

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

java 复制代码 
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 实现，常用的方式有：

  1. Redis 的 SETNX 命令：用于加锁。
  2. Redis 的 Lua 脚本：用于保证锁的原子性释放。
java 复制代码 
// 加锁
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());
}

注意事项：

  • 使用 Redis 实现分布式锁时要确保锁的原子性，并设置合理的锁过期时间，避免死锁问题。
6. 总结

缓存一致性问题

在高并发分布式系统中是非常常见且棘手的问题。常见的解决方法包括使用分布式锁、延迟双删、互斥锁等手段来确保缓存与数据库的数据一致性。每种方案都有其适用场景和优缺点，开发者需要根据具体业务场景选择最合适的方案。

关键点：

  • 使用分布式锁保证缓存和数据库更新的顺序性。
  • 延迟双删策略确保在并发下缓存与数据库的最终一致性。
  • 根据业务需求选择适当的缓存更新策略，并结合实际场景优化锁的使用和缓存策略。
相关推荐
大厂小码哥31 分钟前
图解Redis 01 | 初识Redis
数据库·redis·缓存
Lill_bin10 小时前
Ribbon简介
分布式·后端·spring cloud·微服务·云原生·ribbon
Zy_blog11 小时前
【kafka】消息队列
分布式·kafka
.生产的驴14 小时前
SpringBoot 消息队列RabbitMQ 消息转换器 改变消息的发送格式 节省内存
java·spring boot·分布式·后端·rabbitmq·java-rabbitmq
编程经验分享14 小时前
Windows 安装 ZooKeeper 以及 IDEA 安装 zoolytic 连接工具
分布式·zookeeper·云原生
Pdh胖大海16 小时前
Redis如何实现分布式锁
redis·分布式
我的程序快快跑啊18 小时前
redis:全局ID生成器实现
数据库·redis·缓存
84869811918 小时前
Spring为什么要用三级缓存解决循环依赖？
java·spring·缓存
huisheng_qaq18 小时前
【kafka-01】kafka安装和基本核心概念
大数据·分布式·kafka·消息队列·消息中间件
littleschemer21 小时前
Go缓存系统
缓存·go·cache·bigcache
热门推荐
01RAG 实践- Ollama+RagFlow 部署本地知识库02组基轨迹建模 GBTM的介绍与实现（Stata 或 R）032024年高教社杯数学建模国赛C题超详细解题思路分析04CCF-CSP认证考试 202406-3 文本分词 100分题解05苍穹外卖面试总结06【2024数模国赛赛题思路公开】国赛B题思路丨附可运行代码丨无偿自提07【立创EDA-PCB设计基础】6.布线铺铜实战及细节详解08Coze扣子平台完整体验和实践（附国内和国际版对比）09【2024高教社杯全国大学生数学建模竞赛】B题 生产过程中的决策问题——解题思路 代码 论文102024 高教社杯 数学建模国赛 （A题）深度剖析|“板凳龙” 闹元宵|数学建模完整代码+建模过程全解全析