架构师-如何保证redis和数据库的一致性

薛定谔的猫1981

于 2024-10-07 08:17:36 发布

阅读量697

点赞数 11

分类专栏：系统架构文章标签：数据库 redis 缓存

本文链接：https://blog.csdn.net/sadfasdfsafadsa/article/details/142696996

版权

系统架构专栏收录该内容

47 篇文章 2 订阅

订阅专栏

概述

在分布式系统中，保证Redis和MySQL之间的数据一致性是一个复杂且重要的问题。由于Redis是内存数据库，而MySQL是磁盘数据库，它们的特性和持久化方式不同，因此需要特殊的注意和处理来确保数据的一致性。

以下是一些常见的方法来保证Redis和MySQL之间的数据一致性：

双写模式：在进行写操作时，先将数据写入MySQL，然后再将数据写入Redis。这种方式可以保证MySQL中的数据一定会被同步到Redis中，但是对于读操作来说效率较低。
异步更新：在进行写操作时，只将数据写入MySQL，然后异步地将数据写入Redis。这种方式可以提高写入操作的效率，但是可能会导致Redis中的数据与MySQL中的数据存在一定的延迟。
通过消息队列实现数据同步：可以使用消息队列（如Kafka、RabbitMQ等）来实现MySQL和Redis之间的数据同步。当MySQL中的数据发生变化时，将变化的数据写入消息队列，然后Redis订阅消息队列，根据消息内容更新自己的数据。这种方式可以实现异步更新，并且解耦了MySQL和Redis之间的直接依赖。
定期全量同步：定期从MySQL中读取全量数据，然后覆盖Redis中的数据。这种方式可以保证Redis中的数据与MySQL中的数据完全一致，但是对于大数据量的情况下可能会影响性能。
使用分布式事务：在一些场景下，可以使用分布式事务来保证Redis和MySQL之间的数据一致性。例如，可以使用基于XA协议的分布式事务管理器（如Seata）来协调Redis和MySQL之间的数据更新操作。
需要根据具体的业务场景和需求选择合适的数据一致性方案，并进行相应的设计和实现。同时，还需要考虑各种异常情况下的处理，如网络故障、节点宕机等，以确保系统在异常情况下依然能够保持数据一致性。

解决方案

1.基于 MQ 异步同步更新，消息队列+异步重试-比如基于 RocketMQ 的可靠性消息通信，来实现最终一致

2.还可以直接通过 Canal （阿里的一款开源框架）组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面。

3.延时双删

缓存延时双删

删除缓存重试机制

读取biglog异步删除缓存

一般情况下，Redis 用来实现应用和数据库之间读操作的缓存层，主要目的是减少数据库 IO，还可以提升数据的 IO 性能。这是它的整体架构

当应用程序需要去读取某个数据的时候，首先会先尝试去 Redis 里面加载，如果命中就直接返回。如果没有命中，就从数据库查询，查询到数据后再把这个数据缓存到 Redis 里面。

在这样一个架构中，会出现一个问题，就是一份数据，同时保存在数据库和 Redis里面，当数据发生变化的时候，需要同时更新 Redis 和 Mysql，由于更新是有先后顺序的，并且它不像 Mysql 中的多表事务操作，可以满足 ACID 特性。所以就会出现数据一致性问题。

在这种情况下，能够选择的方法只有几种

先更新数据库，再更新缓存

先删除缓存，再更新数据库

如果先更新数据库，再更新缓存，如果缓存更新失败，就会导致数据库和 Redis中的数据不一致。

如果是先删除缓存，更新数据库，理想情况是应用下次访问 Redis 的时候，发现 Redis 里面的数据是空的，就从数据库加载保存到 Redis 里面，那么数据是一致的。但是在极端情况下，由于删除 Redis 和更新数据库这两个操作并不是原子的，所以这个过程如果有其他线程来访问，还是会存在数据不一致问题

如果需要在极端情况下仍然保证 Redis 和 Mysql 的数据一致性，就只能采用最终一致性方案。

消息队列+异步重试基于 RocketMQ 的可靠性消息通信，来实现最终一致

因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制

删除缓存重试流程

Canal 组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面

因为这里是基于最终一致性来实现的，如果业务场景不能接受数据的短期不一致性，那就不能使用这个方案来做

异步更新缓存(基于订阅binlog的同步机制)

MySQL binlog增量订阅消费+消息队列+增量数据更新到redis读Redis

热数据基本都在Redis写MySQL:增删改都是操作MySQL更新Redis数据：MySQ的数据操作binlog，来更新到Redis：

1)数据操作主要分为两大块：一个是全量(将全部数据一次写入到redis)一个是增量(实时更新)。

这里说的是增量,指的是mysql的update、insert、delate变更数据。

2)读取binlog后分析，利用消息队列,推送更新各台的redis缓存数据。

这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。

其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。

这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。

当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis

重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。其实，还可以这样优化：通过数据库的binlog来异步淘汰key。

以mysql为例吧

● 可以使用阿里的canal将binlog日志采集发送到MQ队列里面

● 然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性

延时双删
```
redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)

```
先删除缓存，再更新数据库，当更新数据后休眠一段时间再删除一次缓存。

这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。

这种方案还算可以，只有休眠那一会（比如就那1秒），可能有脏数据，一般业务也会接受的。但是如果第二次删除缓存失败呢？缓存和数据库的数据还是可能不一致，对吧？给Key设置一个自然的expire过期时间，让它自动过期怎样？那业务要接受过期时间内，数据的不一致咯？还是有其他更佳方案呢？
延时双删策略在高并发环境下，通过在第一次删除缓存后延时一段时间进行第二次删除缓存，确保缓存和数据库中的数据一致，避免并发操作带来的数据不一致问题。步骤是：先删除Redis缓存数据，再更新Mysql，延迟几百毫秒再删除Redis缓存数据，这样就算在更新Mysql时，有其他线程读了Mysql，把老数据读到了Redis中，那么也会被删除掉，从而把数据保持⼀致
弱一致性和强一致性

数据同步过程中，会存在短暂的延迟，这属于正常的现象。

在分布式架构中很难实现数据强一致性

弱一致性：主从之间数据允许不一致性；

强一致性：主从之间数据必须一致性；如果实现成本是非常高，会设计到一些锁的技术，

最终一致性：短暂的数据延迟是允许的，但是最终数据是需要一致; —在分布式中做数据同步需要经过网络传输的，网络传输数据需要一定的时间，所以数据短暂的延迟是允许的，但是最终数据一定达成一致。

延迟是很难避免的，优化减少延迟的时间。公司中数据同步延迟优化在 10-30 毫秒。

Canal详解

Canal 是阿里巴巴开源的数据库变更捕获（CDC）解决方案，主要用于监控数据库的变更，并将这些变更推送到其他数据存储、消息队列等目标端。以下是对 Canal 的详细解释：

方案二：还可以直接通过 Canal 组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面。
延时双删有啥作用？
- 为了使得缓存和数据库数据最终一致。
为什么要删除缓存数据，而不是修改？
- 如果是修改，并发修改数据场景，先改缓存的有可能后改库，先改库的也可能后改缓存。
为什么要睡眠延时一段时间？
- 读写分离是解决高并发比较有效的方案，但是缓存/库的主从是异步更新数据的。
- 睡眠一段时间，就是为了库和缓存能实现数据主从同步。
延时双删能确保缓存和数据库最终一致吗？
- 不能确保。
- 只能通过延时最大程度上提高数据的最终一致的概率。
- 如果缓存和数据库负载很高，主从同步很慢，很有可能不能在延时的时间内实现同步。
脏读怎么办？
- 确实有这问题，要知道这是最终一致，并不是强一致，最后一次删除就是为了最终一致^_^！
- 所以要确保你的业务场景能忍受数据最终一致的缺陷，实在不行你读主库呗。
- 优化业务逻辑的设计，具体请参考下文的：通过业务设计加强数据一致性 章节。
为什么要有第一次删除缓存？
1> 删除脏读。
2> 提前实现其它操作的数据最终一致。
- 延时双删有 4 个步骤，全部执行完才能实现数据最终一致，可能会比较慢！
- 延时双删第三个步骤延时等待是比较漫长的，有可能在等待时间超时前，数据就已经完成同步了。在并发环境中，如果其它并发环节增加第一次删除，可能会提前实现前面操作的数据最终一致，不用等延时双删四个步骤都完成。

采用缓存延迟双删策略最多在X毫秒内读取的数据是老数据，在X毫秒之后读取的数据都是最新的数据。X的具体值如何确定那就需要根据自身的业务了来确定。

延迟双删策略只能保证最终的一致性，不能保证强一致性

如何实现延迟双删

延迟双删策略主要是为了维护数据一致性，特别是在高并发的情况下。它确保了在写入数据库之前，缓存数据被删除，然后在延迟一段时间后再次删除缓存，以应对以下情况：

数据修改并发问题：如果多个请求同时尝试修改数据库中的数据，而缓存中的数据没有被删除，就有可能导致数据不一致。某个请求可能会在缓存中获取旧数据并写入数据库，然后其他请求又读取了旧数据，从而导致数据不一致。
缓存与数据库同步问题：即使写入数据库是同步的，缓存的删除可能是异步的，这意味着缓存中的数据可能在数据库写入之后仍然存在，导致不一致性。

延迟双删策略通过以下步骤解决了这些问题：

删除缓存：首先，缓存中的数据被删除，确保了缓存中不再有旧数据。
写入数据库：然后，数据被写入数据库，以确保数据的持久性。
休眠一段时间：在写入数据库后，应用程序等待一段时间。这个等待时间是为了确保在这段时间内，所有可能的读取操作都能够访问数据库中的最新数据，而不再访问缓存。
再次删除缓存：最后，在休眠时间结束后，再次删除缓存。这可以确保即使有一些读取操作仍然从缓存中获取数据，它们也会获得最新的数据。

以下是一个使用Java代码实现延迟双删策略的示例：

import java.util.concurrent.TimeUnit;
public class CacheManager {
    public void deleteCache(String key) {
        // 删除缓存的实现
        // 请根据您的缓存库的具体方法来删除缓存数据
    }
    public void writeToDatabase(String data) {
        // 写入数据库的实现
        // 请根据您的数据库访问库来执行写入操作
    }
    public void delayDoubleDelete(String key, String data, long delayTimeInSeconds) {
        // 先删除缓存
        deleteCache(key);
        // 写入数据库
        writeToDatabase(data);
        // 休眠一段时间（根据业务需求设置的延迟时间）
        try {
            TimeUnit.SECONDS.sleep(delayTimeInSeconds);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        // 再次删除缓存
        deleteCache(key);
    }
    public static void main(String[] args) {
        CacheManager cacheManager = new CacheManager();
        String key = "example_key";
        String data = "example_data";
        long delayTimeInSeconds = 5; // 延迟时间为5秒
        cacheManager.delayDoubleDelete(key, data, delayTimeInSeconds);
    }
}

上述代码示例中，我们创建了一个CacheManager类，其中包含了删除缓存和写入数据库的方法，以及delayDoubleDelete方法来执行延迟双删策略。在main方法中演示了如何使用它来执行延迟双删操作。确保根据您的实际需求和缓存库、数据库库的具体方法来实现deleteCache和writeToDatabase方法。请注意，这只是一个简单的示例，实际实现可能需要考虑错误处理、并发控制和合适的延迟时间。延迟时间的选择应根据应用的需求来确定，以确保足够的时间供所有可能的读取操作从数据库中获取最新数据。

Redis延迟双删是为了解决网络延迟导致指令没有正常执行的问题。当通过Redis发送一个删除指令时，由于网络延迟的存在，Redis服务器可能无法立即执行该指令。为了避免出现误删的情况，延迟双删就被用来保证删除操作的可靠性。

延迟双删的原理是在执行删除指令之前，先将要删除的键值对设置一个过期时间。为了确保过期时间能够足够长，一般会设置为比较长的时间，例如1秒。然后再执行第二次删除操作，确保键值对被删除。

为什么要删第一次呢？这是因为在Redis中，删除操作是立即返回的，即使实际上删除操作并没有立即执行。所以，通过第一次删除来触发过期时间的设置，并立即返回。然后在网络延迟结束后，再执行第二次删除操作来真正删除键值对。

延迟双删的好处在于能够保证删除操作的可靠性。即使在网络延迟的情况下，也能够有效地删除键值对，避免出现误删的情况。在实际应用中，延迟双删可以用于解决分布式锁的问题，保证锁的正常释放。

总之，延迟双删是为了解决网络延迟导致指令没有正常执行的问题，并保证删除操作的可靠性。通过设置过期时间和执行两次删除操作，可以有效地避免误删和确保删除的可靠性。这是Redis在处理删除操作时的一种常用策略。