猪鼻子兔
随着技术发展，现在项目技术选型不像从前那样单一的，特别是在高并发场景下的项目，都是多种技术配套着来使用。在以前，对于用户数据无论是增删改查，我们都是直接操作数据库的，但在高并发场景下这样做显然是不合理的，于是乎我们在DB层之前加上Cache层，以此来缓解DB层的压力。
在业界通常是将MySQL作为数据最终落地的存储方案，而用Redis来缓存热点数据。一般是读数据是从Redis中读取，增删改则是操作MySQL。但是这样会存在一个问题，即：读操作和写操作是并发的，执行顺序无法保证，这样很容易出现缓存数据与数据库中的数据不一致。
举例说明一下：
假设我们更新了数据库后，缓存一直没有失效，那我们从缓存中读取的就是脏数据。
假设缓存中的数据不存在，我们从数据库中读取数据然后存入缓存，此时数据库刚好更新，那在缓存期间内，这个缓存数据就是脏数据。
如何避免Redis和MySQL中数据一致性问题呢？结合我的经验给出一些方案供大家参考：
1、首先确定你的业务是否要求缓存和数据库之间是强一致性关系
如果你的业务要求数据库和缓存之间是强一致性，那你要做的就是确保每次更新了MySQL后就同步更新Redis；
如果不需要强一致性，那我们合理控制好缓存的TTL即可。
2、借助MQ消息来更新缓存
大概思路是，数据库的每一次修改操作后，我们通过MQ来生产一条消息，然后消费者对应去清理缓存Key并重新写入。
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！
网络圈
要看应用场景，数据变动频繁的环境中，使用读缓存是毫无意义的，反而加重系统负荷，因为要花费额外资源维护缓存和数据源的一致性。
其实redis可以当作数据库的元数据使用，设计好数据结构就是一个简单的关系型库，业务数据完全放到redis中运行，MySQL当作后备库使用。redis也有持久化机制而且很容易做镜像，因此可以在很大时间粒度上进行数据同步，比如一天同步一次。而业务层只操作redis，与数据库完全剥离，即使数据库挂掉也不会导致业务中断。
