一篇关于Redis的读写一致问题

一、普通删除 在数据更新过程中,大家无非使用两种方法进行缓存和数据库的更新 先删除缓存,再更新数据库先更新数据库,再更新缓存 那这两种方法究竟有什么不同呢? 1

一、普通删除

在数据更新过程中,大家无非使用两种方法进行缓存和数据库的更新

  • 先删除缓存,再更新数据库
  • 先更新数据库,再更新缓存

那这两种方法究竟有什么不同呢?

1. 先删除缓存

在这里插入图片描述

问题:此时缓存有了旧数据,在下次修改此数据之前,所有请求获取的都是旧数据,导致读写不一致

2. 后删除缓存

在这里插入图片描述

问题1:在小明修改数据库到删除缓存这段时间,所有请求都是旧数据

问题2:如果缓存删除失败,后续所有请求都是旧数据(这个问题开启事务的话,就可以解决)

二、双删策略

在普通删除策略中,大家会发现后删缓存策略是比较好的一种,但还是存在一点问题,所以提出了双删策略

关于这个地方我是存在疑问的,因为我认为双删并不会比后删缓存策略更好,反而增加了一次数据库查询的操作。但有的博客却提了这个策略,我就在这里提一下,大家可以在评论进行交流

1. 普通双删

在这里插入图片描述

问题:因为线程调度一些问题导致查询后写入缓存停止,会导致旧缓存依旧存在

2. 延迟双删

在这里插入图片描述

这样的话看似把普通双删的问题给解决了,但并没有完全解决,反而引发新的问题。

问题:延时时长问题,时间太长导致性能下降,时间太短又会跟普通双删一样

三、读写锁

读写锁根据字面意思就知道是加锁,因此效率肯定比不加锁效率低,但是可以完全避免旧数据读取的发生。

  • 读写锁是读读共享,读写和写写互斥的

    在这里插入图片描述

四、异步通知

1. 消息中间件异步通知

在这里插入图片描述

  • 对于这个博主认为是把延迟双删的延迟给优化了,不再占用本线程的时间,只不过部分请求会导致旧数据。

2.Canal

Canal是一个开源的数据库数据增量订阅和消费组件,用于实时捕获数据库的变更并将其传递给其他系统。具体而言,Canal主要用于解决数据库之间的数据同步和实时数据分析需求。 Canal支持对MySQL、Oracle等主流数据库进行增量数据订阅和消费。它通过解析数据库的日志(如MySQL的binlog或Oracle的redo log),实时捕获数据库的变更操作,然后将变更数据以事件的形式发送给订阅者。可以将这些变更数据用于数据同步、实时数据仓库、搜索引擎索引更新、缓存更新等应用场景。 Canal的主要特性包括:

  • .数据库无侵入:Canal通过解析数据库日志来捕获数据变更,不需要对数据库进行任何修改,不会对数据库的性能产生影响。
  • 实时的增量数据:Canal能够几乎实时地捕获到数据库的变更操作,并以事件的形式进行传递,保证了数据的实时性。
  • 灵活的订阅和过滤:Canal支持基于数据库、表、列级别的订阅和过滤,可以按需选择需要同步的数据,减少数据传输和处理的压力。
  • 多种协议支持:Canal支持多种数据传输协议,如基于TCP的简单文本协议、Kafka、RocketMQ等,可以根据具体需求选择适合的协议进行数据传输。
  • 高可用和容错:Canal支持多节点部署,通过主备模式或者集群模式来保证高可用性和容错性。

五. 总结

总体来说这几种方式各有优缺点,不过现在主要用的就是普通删除中的后删缓存的方法,如果一致性要求比较高的话,可以用读写锁的方式,如果没有那么强的一致性要求,可以使用后删缓存或者异步通知的方式。

结语

每个人都有自己独特的才华和潜能,在这个广袤的世界上,你的存在是有意义的。无论你是谁,你的背景如何,你所处的环境怎样,只要你敢于跨出舒适区,付出努力,追求卓越,你就能够开创属于自己的辉煌。

以上就是关于Redis的读写一致问题的详细内容,更多关于Redis读写一致的资料请关注好代码网其它相关文章!

您可能有感兴趣的文章
Redis数据结构SortedSet的底层原理解析

redis主从哨兵模式如何实现一主二从

RediSearch加RedisJSON大于Elasticsearch的搜索存储引擎

Redis如何存储对象

Redis唯一ID生成器的如何实现