|
在高并发的场景下，大量的请求直接访问Mysql很容易造成性能问题。所以，我们都会用Redis来做数据的缓存，削减对数据库的请求。但是，Mysql和Redis是两种不同的数据库，如何保证不同数据库之间数据的一致性就非常关键了
1、数据不一致的原因
1.在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。
2.所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。
3.读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
1.1 缓存先后删除问题
不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。
1.2 先删除缓存
1、如果先删除Redis缓存数据，然而还没有来得及写入MySQL，另一个线程就来读取。
2、这个时候发现缓存为空，则去Mysql数据库中读取旧数据写入缓存，此时缓存中为脏数据。
3、然后数据库更新后发现Redis和Mysql出现了数据不一致的问题。
1.3 后删除缓存
1、如果先写了库，然后再删除缓存，不幸的写库的线程挂了，导致了缓存没有删除
2、这个时候就会直接读取旧缓存，最终也导致了数据不一致情况
3、因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题
2、解决方案
1、延时双删策略
先删除缓存，再更新数据库，然后休眠1s（根据具体的业务合理设置，比如几百毫秒），再删除缓存，有可能第二次删除失败，还是会导致数据不一致
缺点：存在延时操作，所以会造成服务器的阻塞， 所以不适合高并发的场景
2、最终一致性
如果需要再极端情况下人仍然保证Redis和MySQL的数据一致性，就只能采用最终一致性的方案，比如基于RabbitMQ的可靠性消息通信来实现数据的最终一致性，还可以通过Canal组件监控MySQL里面的Binary log日志，把更新后的数据同步到Redis里面。
2.1、利用MQ异步重试机制，保证最终一致性，适合高并发场景，缺点就是代码的耦合性高，比如修改、新增接口都需要发送消息
2.2、利用Canal + MQ异步重试机制，保证最终一致性，适合高并发场景，缺点时增加了系统的复杂性
|