Redis 如何保持和 MySQL 数据一致

本文探讨了MySQL和Redis在不同场景下的应用策略,包括数据持久性和一致性处理、并发读写操作优化,以及如何在高并发环境下实现数据的异步写入,确保系统的稳定性和数据的准确性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.MySQL持久化数据,Redis只读数据

redis在启动之后,从数据库加载数据。

读请求:

不要求强一致性的读请求,走redis,要求强一致性的直接从mysql读取

写请求:

数据首先都写到数据库,之后更新redis(先写redis再写mysql,如果写入失败事务回滚会造成redis中存在脏数据)

2.MySQL和Redis处理不同的数据类型

  • MySQL处理实时性数据,例如金融数据、交易数据

  • Redis处理实时性要求不高的数据,例如网站最热贴排行榜,好友列表等

在并发不高的情况下,读操作优先读取redis,不存在的话就去访问MySQL,并把读到的数据写回Redis中;写操作的话,直接写MySQL,成功后再写入Redis(可以在MySQL端定义CRUD触发器,在触发CRUD操作后写数据到Redis,也可以在Redis端解析binlog,再做相应的操作)

在并发高的情况下,读操作和上面一样,写操作是异步写,写入Redis后直接返回,然后定期写入MySQL

几个例子:

1.当更新数据时,如更新某商品的库存,当前商品的库存是100,现在要更新为99,先更新数据库更改成99,然后删除缓存,发现删除缓存失败了,这意味着数据库存的是99,而缓存是100,这导致数据库和缓存不一致。

解决方法:

这种情况应该是先删除缓存,然后在更新数据库,如果删除缓存失败,那就不要更新数据库,如果说删除缓存成功,而更新数据库失败,那查询的时候只是从数据库里查了旧的数据而已,这样就能保持数据库与缓存的一致性。

2.在高并发的情况下,如果当删除完缓存的时候,这时去更新数据库,但还没有更新完,另外一个请求来查询数据,发现缓存里没有,就去数据库里查,还是以上面商品库存为例,如果数据库中产品的库存是100,那么查询到的库存是100,然后插入缓存,插入完缓存后,原来那个更新数据库的线程把数据库更新为了99,导致数据库与缓存不一致的情况

解决方法:

遇到这种情况,可以用队列的去解决这个问,创建几个队列,如20个,根据商品的ID去做hash值,然后对队列个数取摸,当有数据更新请求时,先把它丢到队列里去,当更新完后在从队列里去除,如果在更新的过程中,遇到以上场景,先去缓存里看下有没有数据,如果没有,可以先去队列里看是否有相同商品ID在做更新,如果有也把查询的请求发送到队列里去,然后同步等待缓存更新完成。

这里有一个优化点,如果发现队列里有一个查询请求了,那么就不要放新的查询操作进去了,用一个while(true)循环去查询缓存,循环个200MS左右,如果缓存里还没有则直接取数据库的旧数据,一般情况下是可以取到的。

在高并发下解决场景二要注意的问题:

1、读请求时长阻塞

由于读请求进行了非常轻度的异步化,所以一定要注意读超时的问题,每个读请求必须在超时间内返回,该解决方案最大的风险在于可能数据更新很频繁,导致队列中挤压了大量的更新操作在里面,然后读请求会发生大量的超时,最后导致大量的请求直接走数据库,像遇到这种情况,一般要做好足够的压力测试,如果压力过大,需要根据实际情况添加机器。

2、请求并发量过高

这里还是要做好压力测试,多模拟真实场景,并发量在最高的时候QPS多少,扛不住就要多加机器,还有就是做好读写比例是多少

3、多服务实例部署的请求路由

可能这个服务部署了多个实例,那么必须保证说,执行数据更新操作,以及执行缓存更新操作的请求,都通过nginx服务器路由到相同的服务实例上

4、热点商品的路由问题,导致请求的倾斜

某些商品的读请求特别高,全部打到了相同的机器的相同丢列里了,可能造成某台服务器压力过大,因为只有在商品数据更新的时候才会清空缓存,然后才会导致读写并发,所以更新频率不是太高的话,这个问题的影响并不是很大,但是确实有可能某些服务器的负载会高一些。

保持 Redis 缓存 MySQL 数据库之间的数据一致性是高并发系统设计中的关键问题之一。由于 Redis 通常用于缓存加速访问,而 MySQL 是持久化存储的核心数据库,两者在读写速度、数据结构事务支持上存在差异,因此需要采用合理的策略来降低数据一致的风险。 ### 同步更新 同步更新是最直接的方式,在写入 MySQL 的同时更新 Redis 缓存。这种方式的优点是实现简单,但缺点是在操作过程中存在短暂的窗口期可能导致数据一致。例如,在更新 MySQL 后但在更新 Redis 前如果发生异常,Redis 中的数据仍然是旧值[^2]。 ### 异步更新 异步更新通过引入消息队列(如 RabbitMQ、Kafka)将 MySQL 的变更事件发布到队列中,由消费者监听并更新 Redis。这种方式降低了对主业务逻辑的影响,提高了系统的吞吐量,但由于存在消费延迟,可能造成一定时间内的数据一致[^2]。 ### 延时双删策略 延时双删是一种优化策略,适用于读多写少的场景。其基本流程是在更新 MySQL 前删除 Redis 缓存,执行完数据库操作后再次延时删除 Redis 缓存。这样可以减少因数据库更新缓存删除之间的时间差而导致的不一致风险。以下是一个伪代码示例: ```java public void write(String key, Object data) { redis.delKey(key); db.updateData(data); Thread.sleep(500); // 延迟一段时间再删除一次 redis.delKey(key); } ``` 该方法通过两次删除缓存的操作,尽可能确保在数据库更新完成后缓存也失效,从而避免脏读[^4]。 ### Binlog 订阅机制 利用 MySQL 的 Binlog 功能订阅数据库的变更事件,并通过中间件(如 Canal、Debezium)捕获这些变更,进而更新 Redis。这种方案能够实现实时或近实时的一致性保证,适用于对一致性要求较高的场景[^2]。 ### 最佳实践建议 - **优先使用 Binlog 订阅**:对于一致性要求极高的系统,推荐使用 Binlog 订阅方式,结合消息队列构建稳定的更新流水线。 - **结合缓存过期机制**:为 Redis 设置合理的过期时间,即使出现短暂不一致,也能在 TTL 过期后自动恢复。 - **使用分布式锁控制并发更新**:在高并发写入场景下,可使用 Redlock 等算法控制并发写入顺序,减少冲突。 - **监控补偿机制**:建立数据一致性校验机制,定期扫描 MySQL Redis数据差异,并进行修复。 综上所述,不同策略适用于不同业务场景。实际应用中,通常会根据一致性需求、性能压力以及系统复杂度综合选择合适的方案。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值