腾讯云网站制作教程,企业做推广哪些网站比较好,主要干啥,百度关键词推广费用目录
不实用的方案
1. 先写 MySQL , 再写 Redis
2. 先写 Redis #xff0c; 再写MySQL
3. 先删 Redis#xff0c;再写 MySQL
实用的方案
1. 先删 Redis#xff0c;再写 MySQL, 再删 Redis
2. 先写 MySQL , 再删 Redis
3. 先写MySQL#xff0c;通过BinLog#xff0…
目录
不实用的方案
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的内存管理和垃圾回收压力影响系统的性能和稳定性。无法应对异常情况如果在键过期和实际删除之间发生系统故障或者网络中断等情况可能会导致数据不一致或者缓存失效的问题。 扯远了回到正轨。。
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”。
