【MySQL/Redis】如何实现缓存一致-编程知识

不实用的方案

1. 先写 MySQL , 再写 Redis

2. 先写 Redis ，再写MySQL

3. 先删 Redis，再写 MySQL

实用的方案

1. 先删 Redis，再写 MySQL, 再删 Redis

2. 先写 MySQL , 再删 Redis

3. 先写MySQL，通过BinLog，异步更新 Redis

几种方案的对比

总结一下

在日常的工作和学习中，我们可能经常会看到关于 MySQL 和 Redis 如何才能保证缓存一致的问题，本篇文章就来带你了解一下，这到底是个什么东西。话不多说，直接开整~~

为了防止有些盆友不太了解什么是缓存一致及为什么要这么做，我先来小小的解释一下:

MySQL/Redis缓存一致性是指在使用MySQL作为持久化数据库和Redis作为缓存系统的应用场景中，确保当数据在MySQL中发生更改时，这些更改能够被及时、正确地反映到Redis的缓存中。保持缓存一致性是为了避免出现以下情况：

脏读：从缓存中读取到了已经过期或者已经被删除的数据。
不可重复读：在短时间内连续两次读取相同的数据，但得到的结果不一致。
幻读：因为并发操作导致读取的数据与实际存储的数据不同。

好了先来个图，大概解释一下有哪些方法（这里给出的方法只是基于M/R读写删除相关的，其它中间件或者锁等方法，等俺下次补充）：

我们来一个个的看，先说这个不实用的方案，之所以说它不实用并不是否定这个方法的作用，毕竟存在即合理嘛，只是说它们在一些特定的场景中才会发挥出作用。

（注：以下图解都是以时序图解释的，相信大家都知道吧~~）

不实用的方案

1. 先写 MySQL , 再写 Redis

相信大家从图中就可以看出为什么说这是一个不推荐的方法了，两个请求都是先写MySQL，再写Redis，再并发的场景下，就可能会发生MySQL中的数据更新了，但Redis中还是旧值的情况。值得注意的一点是，再这个场景下，对于读请求，一般的处理都是先读Redis，没有的话再去数据库中查询，但是这个读请求并不会更新Redis中的数据。即，读请求不会更新Redis。

2. 先写 Redis ，再写MySQL

和前一种的方法一样，这里就不多做解释了，看图想一想就会明白。同样是在高并发的场景下会出现一些问题。

3. 先删 Redis，再写 MySQL

这里需要提醒一下，请求A是一个更新操作，请求B是一个读操作（在这个场景下，请求B是会将读到的数据回写到Redis中的）。

这个可能出现缓存不一致的处理方案，在日常开发中是经常会发生的。

因为更新操作可能耗时会比较久，所以在请求A 删除了缓存后，请求B的读请求可能会在这期间执行，而且查询操作还是很快的。剩下的看图就可以理解了。

实用的方案

1. 先删 Redis，再写 MySQL, 再删 Redis

这就是我们经常可用听到的“缓存双删”、“延迟双删除”等词。

这种方法看起来好像真的可以解决缓存不一致的问题，但是对于这个延迟删除缓存，我们到底该什么时间删呢？

以下有几个可供参考的方法：

定时任务： 可以在应用程序中设置一个定时任务，在第一次删除缓存后延迟指定的时间，然后执行第二次删除缓存的操作。呃，这个说白了就是让请求A 的最后一次删除缓存操作等待一段时间再去执行。
异步处理： 在更新数据库成功后，启动一个异步任务（例如使用 RabbitMQ、Kafka 等消息队列或者线程池），该任务在延迟指定的时间后执行第二次删除缓存的操作。
Redis过期机制：设置Redis键的过期时间（TTL）为一个较短的值，这样即使在第二次删除之前有新请求将旧数据写入缓存，也会在短时间内自动过期并被删除。

对于第一个方法，可能是一个“好用”，但不实用的方法，这种只需要一个sleep xxx ms，就能完成的功能，可不就是好用吗（doge）。说它不实用是因为它不可控，具体的就不说了。

然而，尽管存在这些不可控因素，定时任务仍然是实现延迟双删等策略的一种常见方法。毕竟哪有那么多的高并发的场景啊，还有就是我们程序员“懒”，功能实现了就行了

异步处理这个方法感觉是以上几个方法中，较好的，实现了功能的同时还保证了稳定。但是麻烦。。。因为需要添加一个新的组件。

下面是这个方法需要注意的几个点：

定义异步任务：首先，你需要定义一个异步任务，这个任务负责在数据库更新后执行第二次删除Redis缓存的操作。这个任务可以是一个实现了特定接口或者继承了特定类的类，具体取决于你使用的编程语言和框架。

更新数据库并触发异步任务：当需要更新数据库时，首先执行第一次删除Redis缓存的操作，然后进行数据库的更新。在数据库更新成功后，立即触发定义好的异步任务。这通常可以通过以下方式实现：

使用消息队列（如RabbitMQ、Kafka等）：将一个消息发送到队列中，消息的内容包含了需要删除的缓存键或者其他相关的信息。然后，有一个消费者服务监听这个队列，接收到消息后执行第二次删除缓存的操作。
使用线程池或者异步执行框架：直接在应用程序中创建一个新的线程或者任务，将其提交到线程池或者异步执行框架中。这个新任务会在后台运行，并在延迟指定的时间后执行第二次删除缓存的操作。

实现异步任务逻辑：在异步任务的实现中，需要包含以下逻辑：

延迟执行：根据业务需求，设置一个合适的延迟时间。这个时间应该足够长，以覆盖从第一次删除缓存到数据库更新完成之间的时间窗口，但又不能太长，以免影响数据的一致性。
删除缓存：在延迟时间过后，执行第二次删除Redis缓存的操作。这通常涉及到与Redis服务器的通信，使用适当的Redis客户端库来发送删除命令。

处理异常和重试：在异步任务的执行过程中，可能会遇到各种异常情况，如网络中断、Redis服务器故障等。为了保证数据的一致性和系统的稳定性，需要实现适当的异常处理和重试机制。例如，如果删除缓存失败，可以尝试重新发送删除命令，或者记录错误日志并通知运维人员。

具体消息对列的使用，等之后再说吧。

对于第三种方法，我感觉还没第一种好，他的一下问题如下：

数据一致性问题：延迟双删策略的主要目的是确保在更新数据库后，能够及时删除相关的Redis缓存，以避免数据不一致。而Redis的过期机制是基于时间的，它不能精确地与数据库更新操作同步，因此可能会导致在键过期和实际删除之间的时间窗口内，新的请求查询到旧的数据库数据并将其放入缓存。
过期时间设置复杂性：为了使用过期机制替代延迟双删，需要为每个缓存键设置一个合适的过期时间，这个时间需要考虑到数据库更新的频率、网络延迟、系统负载等因素，设置起来可能会比较复杂和难以准确预测。
内存管理问题：如果大量缓存键在同一时间过期，可能会引发Redis的内存管理和垃圾回收压力，影响系统的性能和稳定性。
无法应对异常情况：如果在键过期和实际删除之间发生系统故障或者网络中断等情况，可能会导致数据不一致或者缓存失效的问题。

扯远了，回到正轨。。