MySQL/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的内存管理和垃圾回收压力，影响系统的性能和稳定性。
无法应对异常情况：如果在键过期和实际删除之间发生系统故障或者网络中断等情况，可能会导致数据不一致或者缓存失效的问题。
扯远了，回到正轨。。
2. 先写 MySQL , 再删 Redis
对于一些可以允许系统出现短时间不一致的场景还是可以使用的，但对于一些强一致的场景就不太适用了，比如秒杀、库存扣减等业务。
对于这个方法，还有一种特殊的场景，就是请求发出时，缓存刚好失效，可能会引发的错误。
实际上这种遇到的概率是非常小的，一是缓存刚好失效，二是请求B从数据库查到数据，且回写缓存的耗时，要比请求A写数据库且删除缓存的时间要长。这在实际开发中遇到的概率极低。
3. 先写MySQL，通过BinLog，异步更新 Redis
在这个方法中，这个查询的请求是不会回写数据到Redis中的。
对于这个方法，会保证MySQL和Redis的最终一致性，但是如果中途请求B需要查询数据，如果缓存无数据，就直接查DB;如果缓存有数据，查涧的数据也会存在不一致的情况。
所以这个方案，是实现最终一致性的终极解决方案，但是不能保证实时性。
几种方案的对比
1. 先写 Redis ， 后写MySQL
数据没有落到数据库中你们安心吗，hxd，万一数据库宕机了，我们只靠缓存那不是开玩笑吗，正式环境中使用这种方法，就要提桶跑路了
2. 先写 MySQL, 后写 Redis
对于并发量不大、不要求强一致的使用还是挺不错的，但缺点是怕Redis突然挂了。。
3. 先删 Redis， 再写 MySQL
呃，这个的话好像没什么可以用的场景，一般都没人考虑这种吧（如有，欢迎补充！！）
4. 先删 Redis，再写 MySQL ,再删 Redis
好，但想要优雅的话，还需要支出额外的维护成本（消息队列。。）。
5. 先写 MySQL, 再删 Redis
推荐，高并发场景适用。
6. 先写 MySQL,通过 BinLog 异步更新 Redis
说使用，没试过，但这种对异地容灾、数据汇总等场景可能会较好一些。
总结一下
对于实时性要求高的，可以使用“先写 MySQL, 再删 Redis”。
对于要求强一致的，可以使用“先写 MySQL,通过 BinLog 异步更新 Redis”。
其它的之后再补充，这里就先结束了！
下回见！！！