【Redis】实际代码如何保证Redis与Mysql的一致性

一、前言

当今最流行的缓存中间件当属redis了，由于redis是基于内存操作，性能优越，所以被广泛使用。

使用缓存的一般步骤如下：

1. 先查询缓存，如果缓存命中，直接返回数据
2. 如果缓存不命中，则查询数据库返回数据，并将查询到的数据放入缓存中

但是当我们想要更新数据时，这时可能会出现缓存与数据库中的数据不一致问题，这里面有各种更新缓存的操作，比如先更新缓存、再更新数据库或先更新数据库、再更新缓存，这里不一一列举了，可查阅站内大神写的 https://segmentfault.com/a/1190000041998615

二、延迟双删方案

在我们内部一般是通过先更新数据，再删除缓存，再延迟删除的方案来更新缓存的，这样可以使缓存与数据库达到最终一致性。伪代码如下

tx.begin();  // 开启事务
boolean result = updateDB(data);
if (result) {
    boolean cacheResult = deleteCache(dataId);  // 删除缓存
    if (!cacheResult) {
        tx.rollback();  // 回滚事务
        return;
    }
} else {
    tx.rollback();  // 回滚事务
    return;
}
tx.commit();  // 提交事务

// 将dataId放入延迟队列，通过异步地方式再次删除该缓存
// 异步删除缓存失败可以进行重试，如果失败次数达到n，则发送告警信息
delayQueue.offer(dataId);  

这种方案优缺点很明显，优点就是实现简单，缺点就是只能让缓存和数据库达到最终一致性，仍然可能出现一小段时间的不一致。

三、分布式锁方案

那如果真的有某些场景想要达到强一致性，这里我们内部选择的是使用分布式锁（为了不引入其他组件，使用redis来实现分布式锁）。

那代码如何来实现缓存与数据库的强一致性，伪代码如下：

3.1 查询数据

Object result = getCache(dataId);    // 查询缓存

if (result == null) {                // 缓存未命中

    RLock lock = getRLock();         // 获取分布式锁
    lock.lock();

    try {     
        result = getCache(dataId);    // 再次查询缓存，如果命中缓存，直接返回
        if (result != null) 
            return result;
        
        result = queryDB(dataId);    // 查询数据库
        putCache(dataId, result);    // 将查询结果置入缓存中
    } finally {
        lock.unlock();  // 释放锁
    }
}

return result;

3.2 更新数据

// 获取分布式锁
RLock lock = getRLock();
lock.lock();

try {
    tx.begin();                         // 开启事务
    boolean result = updateDB(data);    // 更新数据库
    if (result) {                       // 如果更新数据库成功
        boolean cacheResult = deleteCache(dataId);  // 删除缓存
        if (!cacheResult) {             // 删除缓存失败
            tx.rollback();              // 回滚事务
            return;
        }
    } else {                            // 更新数据库失败
        tx.rollback();                  // 回滚事务
        return;
    }
    tx.commit();                        // 提交事务
} finally {
    lock.unlock();                      // 释放锁
}

上面的伪代码还有许多可以优化的地方，这里只是把核心部分贴出来，仅供参考。

3.3、存在的问题

一旦引入分布式锁，也将引入新的问题

• 如果是单点redis，无法保证高可用
• 如果是redis哨兵或集群模式，极端情况下会存在锁丢失（在主从切换时，master还没来的及将锁信息同步到slave时，master挂掉，slave切换为master，此时锁丢失）的情况

如何作出取舍？(个人偏向于使用单独的单点Redis来做分布式锁，因为在需要强一致性的前提下，当该用作分布式锁的redis挂掉时，该业务将无法继续进行，个人认为也相对合理)

四、总结

在`不同的应用场景下使用不同的实现方案来保证数据库和缓存的一致性：

1. 在不需要强一致性的场景下，首选第一种方案，其实现简单、效率高，不需要引入分布式锁
2. 而需要强一致性的场景下，无奈只能选择第二种方案，但分布式锁的引入不仅降低了性能，也增加了维护难度