【数据库 的面试】redis缓存一致性怎么保证？redis mysql 缓存方案_mysql缓存机制_redis同步数据到mysql

作者：牛牛玛特 公众号：牛牛玛特

2019年，牛牛面试字节深圳某部门时，被问到如何保证redis和mysql的数据一致性？牛牛凭着多年积累，和面试官就各种情况畅聊10分钟，顺利过关。

2020年，同样的问题，牛牛在鹅厂三面中再次被问及。如此高频的问题，如果你遇到，能否对答如流？

缓存是什么？

缓存在计算机领域是一个非常重要的概念。牛牛首次接触缓存，是在操作系统的课上。简单来说，存储的速度是有区别的，缓存就是把低速存储的结果，临时保存在高速存储，以提高查询效率。

在数据库场景下，更廉价、高效但可靠性稍低的redis可以给更昂贵、较慢、可靠性强的mysql做缓存。

为什么需要缓存？

关系型数据库如mysql，通常支持完整的ACID特性，即原子性、一致性、隔离性和持久性，架构复杂，因而性能普遍较低。高并发的查询需求，会给mysql带来很大压力，造成数据库系统的不稳定，同时也容易产生延迟。

根据局部性原理，80%的请求会落到20%热点数据上，在读多写少场景下，增加一层缓存非常有助提升系统吞吐量和健壮性。通常，我们会使用redis来作为mysql的缓存，如果在redis中能找到缓存，就叫缓存命中，此时就直接用redis的数据；如果缓存未命中，那么再从mysql读取数据。可以看到，redis就像一个盾牌🛡️一样，帮助mysql分担请求，减轻压力。

存在问题

mysql的数据随着时间流逝，可能会发生更新，此时redis缓存数据就会落后，我们如何保证它们的一致性呢？

这里要明白一点，面试官要考察的，一定是符合实际场景的最终一致性，如果非要杠强一致性，那么八成是希望你告诉他，强一致性带来的成本巨大，还不如不用缓存。

解决方案

方案一：等待过期，顺其自然

使用redis的过期时间，mysql更新时，redis不做处理，等待缓存过期失效，再从mysql拉取缓存。

这种方式实现简单，但不一致的时间会比较明显，具体由你的业务来配置。如果读请求非常频繁，且过期时间设置较长，则会产生很多脏数据。

优点：

• redis原生接口，开发成本低，易于实现；
  
• 管理成本低，出问题的概率会比较小。

不足：

• 完全依赖过期时间，时间太短容易造成缓存频繁失效，太长容易有较长时间不一致，对编程者的业务能力，有一定要求。

方案二：尝试删除，从头再来

在方案一的基础上扩展，不光通过key的过期时间兜底，还需要在更新mysql时，同时尝试删除redis，如果删除成功，下次访问该数据，则会直接查询mysql的数据，此时再写入redis，就完成了数据同步。这里为什么说是尝试删除呢？因为有了key本身的过期时间作为保障，最终一致性是一定达成的，主动删除redis数据只是为了减少不一致的时间，但不能让其成为一个关键路径，影响核心流程。

优点：

• 相对方案一，达成最终一致性的延迟更小；
• 实现成本较低，只是在方案一的基础上，增加了删除逻辑。

不足：

• 如果更新mysql成功，删除redis却失败，就退化到了方案一；
• 在高并发场景，业务server需要和mysql、redis同时进行连接，这样是损耗双倍的连接资源，容易造成连接数过多的问题。

方案三：主动更新，信箱投递

从被动防守，到主动进攻，在更新mysql之后，redis也要更新，怎么更新呢？用消息队列！具体来说，是将更新操作交给消息队列，由消息队列保证可靠性，此外再搭建一个消费服务订阅消息队列，来异步更新redis数据。

优点：

• 使用消息队列，就相当于将请求投递至信箱，只要投递成功即完成任务，不用关心结果，实现了进一步解耦；
• 消息队列本身具有可靠性，在投递成功的前提下，通过手动提交等手段去消费，可以保证更新操作至少在redis中执行一次。

不足：

• 有时序性问题。举个栗子🌰，两台业务服务器在同一时间发出a = 1和a = 5两条请求，若mysql中先执行a=1再执行a=5，则mysql中a的值最终为5；但由于网络传输本身有延迟，所以无法保证两条请求谁先进入消息队列，最终redis的结果可能是1也可能是5，如果是1，mysql和redis中的数据就会产生不一致；
• 引入了消息队列，同时要增加消费服务，成本较高；
• 依旧有消耗更多客户端连接数的问题。

方案四：订阅日志，完全解耦

把我们搭建的消费服务作为mysql的一个slave，订阅mysql的binlog日志，解析日志内容，再更新到redis。此方案和业务完全解耦，redis的更新对业务方透明，可以减少心智成本。

优点：

• 在同步服务压力不大情况下，延迟较低；
• 和业务完全解耦，在更新mysql时，不需要做额外操作；
• 解决了时序性问题，可靠性强。

缺点：

• 要单独搭建一个同步服务，并且引入binlog同步机制，成本较大；
• 同步服务如果压力比较大，或者崩溃了，那么在较长时间内，redis中都是老旧数据。

方案选型

1. 首先确认产品上对延迟性的要求，如果要求极高，且数据有可能变化，别用缓存。
2. 通常来说，方案1就够了。牛牛咨询过4、5个团队，基本都是用方案1，因为使用缓存方案，通常是读多写少场景，同时业务上对延迟具有一定的包容性。方案1虽然有一定延时，但比较实用。
3. 如果想增加更新时的即时性，就选择方案2，不过一定要注意，针对redis老数据的删除操作不要作为关键路径，影响核心流程。
4. 方案3、方案4均适用于对延时要求比较高的业务，其区别为前者是推模式，后者是拉模式，而后者具有更强的可靠性，且无时序性问题。既然都愿意花功夫做处理消息的逻辑，不如一步到位，用方案4！

redis的缓存淘汰策略可见LRU缓存淘汰算法

结论

在面试中，可以直接摊牌“我有四种方案”，然后讲优势，谈场景，论选型，展现专业风采；如果遇到的是那种感觉会追问的面试官，也可以从简单讲到复杂，引导面试官一步一步追问，一点点推导，你来我往，宾主尽欢。

更多面试题详见《数据库的面试题集》