如何解决Redis缓存和MySQL数据一致性的问题？

在高并发业务场景中，数据库的性能瓶颈通常对于用户的并发访问而言太大。 因此，redis通常用作缓冲区操作，以允许请求首先访问redis，而不是直接访问数据库（例如MySQL）。 这样可以减少网络请求的延迟响应。

数据为什么会不一致

这类问题主要在于并发读写访问，缓存和数据相互交叉执行。

一、单库情况下

同一时间发生了并发读写请求，比如A(写) ，B (读)，2个请求

A请求发送一个写的操作到服务端，第一步就会淘汰cache，然后因为各种原因卡住了，不在执行后面的大量业务(例：大量的业务操作、调用其他服务处理消耗了1s）。B请求发送一个读操作，这个时候会去读cache，因为cache淘汰，所以为空B请求继续读DB，读出一个脏数据，并写入cacheA请求终于执行完全，在写入数据到DB中总结：由于写入数据最后已输入到DB中，因此未同步。cache里面就一直保持着脏数据。

脏数据是指源系统中的数据不在给定范围内或对实际业务无意义，或者数据格式不合法，并且源系统中存在不规则性。 编码和模糊的业务逻辑。

二、主从同步，读写分离的情况下，读从库而产生脏数据

A请求发送一个写操作到服务端，第一步就会淘汰掉cacheA请求写主数据库，往主数据库写了最新的数据。B请求发送一个读操作，读cache，因为cache淘汰，所以为空B请求继续读DB，这个时候读的是从库，此时主从同步还没同步成功。读出脏数据，然后脏数据写入cache最后数据库主从同步完成总结：在这种情况下，请求A和请求B操作的时间可以。 这是主从同步（假设为1s）的延迟问题，它导致读取请求从库中读取并读取脏数据不一致

根本原因:

在单个库中，逻辑处理消耗1s。 以1s的主从同步延迟，可以将旧数据读入高速缓存

主从+读写分离。 从库中读取旧数据到缓存中

数据优化方案

一、缓存双淘汰法

先淘汰缓存再写数据库将淘汰消息发送到消息总线esb，然后立即将其发送回。写入请求处理时间几乎没有增加，并且此方法淘汰了缓存两次。因此，被称为“缓存双淘汰法“，并且在消息总线的下游，有一个异步淘汰缓存的消费者，在拿到淘汰消息在1s后淘汰缓存，这样，即使在1秒内有脏数据入缓存，也能够被淘汰掉。二、异步淘汰缓存

以上步骤都是在业务线中执行的，增加了一个线下的读取binlog异步淘汰缓存模块，在读取binlog总的数据，然后进行异步淘汰。

1.思路：

MySQL binlog增量发布订阅消耗+消息队列+增量数据更新到redis

1）读取请求转到Redis：热数据基本上在Redis

2）写入请求转到MySQL：增加删除和 修改MySQL

3）更新Redis数据：MySQ数据操作binlog更新为Redis

2.Redis更新

1）数据操作主要有两块：

一个是全量(将全部数据一次写入到redis)一个是增量（实时更新）这里说的是增量,指mysql的更新，插入和删除，以更改数据

这样，一旦MySQL中发生新的写入，更新，删除和其他操作，就可以将与Binlog相关的消息推送到Redis，然后Redis会根据binlog中的记录来更新Redis。 无需处理业务线中的缓存内容。

以上是本文的全部内容，希望对大家的学习有帮助

感谢阅读

转载 ：如何解决Redis缓存和MySQL数据一致性的问题？