Redis 与 Mysql 的数据一致性问题

在高并发场景下，如果每一次请求都要访问数据库，那么性能一定是低的，因为数据库存储在磁盘里，磁盘的IO操作是比较慢的；
所以就出现的缓存技术，因为内存IO要比磁盘IO快很多，将一些数据存到内存中可以显著的提高访问效率，常用的就是Redis来做缓存。
但同时也会产生一些问题，在缓存和数据库同时存在时，如果数据需要修改，是应该先修改数据库还是先修改缓存呢？这个问题就是数据一致性问题。

该方案可能会导致数据不一致的情况。

如果在更新数据库后并在更新缓存前服务挂掉了，此时数据库更新了，缓存没有更新，数据库和缓存的数据不一致；

还有一种极端的情况：

如果在更新数据库后，还没来得及更新缓存呢，大量的请求访问缓存，那么这些请求所读到的都是脏数据；

该方案可能会导致数据不一致的情况。

如果在更新缓存后并在更新数据库前服务挂掉了，此时缓存更新了，数据库没有更新，数据库和缓存的数据不一致；

先删除缓存，如果删除成功，下次请求时到数据库重新拿数据写入缓存，如果删除失败，也不会更新数据库；

该方案看起来很好，但在一些场景下会有数据不一致的情况。

删除成功后，还没来得及更新数据库，另一个请求拿到从数据库拿到数据写入缓存，之后这个请求才更新数据库，此时缓存的数据为脏数据

同时也会产生性能问题：

如果缓存删除成功后有大量的请求来访问，这就会造成穿透、击穿甚至是雪崩问题

MQ有消息重投机制，缓存和数据库有一个写入失败消费失败，可以重新消费，重新写入缓存和数据库

缺陷

数据同步会有一段时间的延迟，并发场景下，会有大量请求读到脏数据