面试普通人VS高手：如何确保Redis与Mysql数据一致性实现？

本文共计1330个文字，预计阅读时间需要6分钟。

今天分享一道一线互联网公司高频面试题。题目是：Redis和MySQL如何保证数据一致性？这个问题难倒了不少工作5年以上的程序员，难题不在于问题本身，而在于解决这个问题的思维模式。

下面是解答：

为了保证Redis和MySQL的数据一致性，可以采用以下几种策略：

1. 使用事务：在Redis中，可以使用MULTI/EXEC命令来保证操作的原子性。在MySQL中，使用事务可以保证操作的原子性、一致性、隔离性和持久性（ACID特性）。

2. 使用乐观锁或悲观锁：在更新数据时，可以使用乐观锁或悲观锁来避免并发冲突，从而保证数据的一致性。

3. 使用消息队列：通过消息队列来解耦Redis和MySQL，确保数据在不同系统间的同步。

4. 使用Redis的发布/订阅功能：当MySQL中的数据发生变化时，通过发布/订阅机制将变更通知给Redis，从而保证数据的一致性。

5. 使用Redis的持久化机制：通过Redis的持久化机制，如RDB和AOF，将数据变化同步到磁盘，从而保证数据在系统崩溃后可以恢复。

6. 使用数据库级别的锁：在MySQL中，可以使用表锁、行锁或全局锁来保证数据的一致性。

通过以上方法，可以在Redis和MySQL之间实现数据一致性。在实际应用中，可以根据具体场景选择合适的策略。

今天分享一道一线互联网公司高频面试题。
“Redis和Mysql如何保证数据一致性”。
这个问题难倒了不少工作5年以上的程序员，难的不是问题本身，而是解决这个问题的思维模式。
下面来看看普通人和高手对于这个问题的回答。

普通人：

嗯....

Redis和Mysql的数据一致性保证是吧？我想想。

嗯 ， 就是，Mysql的数据发生变化以后，可以同步修改Redis里面的数据。

高手：

一般情况下，Redis用来实现应用和数据库之间读操作的缓存层，主要目的是减少数据库IO，还可以提升数据的IO性能。

这是它的整体架构。

当应用程序需要去读取某个数据的时候，首先会先尝试去Redis里面加载，如果命中就直接返回。如果没有命中，就从数据库查询，查询到数据后再把这个数据缓存到Redis里面。

在这样一个架构中，会出现一个问题，就是一份数据，同时保存在数据库和Redis里面，当数据发生变化的时候，需要同时更新Redis和Mysql，由于更新是有先后顺序的，并且它不像Mysql中的多表事务操作，可以满足ACID特性。所以就会出现数据一致性问题。

在这种情况下，能够选择的方法只有几种。

1. 先更新数据库，再更新缓存
2. 先删除缓存，再更新数据库

如果先更新数据库，再更新缓存，如果缓存更新失败，就会导致数据库和Redis中的数据不一致。

如果是先删除缓存，再更新数据库，理想情况是应用下次访问Redis的时候，发现Redis里面的数据是空的，就从数据库加载保存到Redis里面，那么数据是一致的。但是在极端情况下，由于删除Redis和更新数据库这两个操作并不是原子的，所以这个过程如果有其他线程来访问，还是会存在数据不一致问题。

所以，如果需要在极端情况下仍然保证Redis和Mysql的数据一致性，就只能采用最终一致性方案。

比如基于RocketMQ的可靠性消息通信，来实现最终一致性。

还可以直接通过Canal组件，监控Mysql中binlog的日志，把更新后的数据同步到Redis里面。

因为这里是基于最终一致性来实现的，如果业务场景不能接受数据的短期不一致性，那就不能使用这个方案来做。

以上就是我对这个问题的理解。

总结

在面试的时候，面试官喜欢问各种没有场景化的纯粹的技术问题，比如说：“你这个最终一致性方案”还是会存在数据不一致的问题啊？那怎么解决？

先不用慌，技术是为业务服务的，所以不同的业务场景，对于技术的选择和方案的设计都是不同的，所以这个时候，可以反问面试官，具体的业务场景是什么？

一定要知道的是，一个技术方案不可能cover住所有的场景，明白了吗？

本期的普通人VS高手面试系列就到这里结束了，喜欢的朋友记得点赞收藏。

另外，最近从评论区收到的面试问题，都有点太泛了，比如：说一下mongoDB啊，说一下kafka啊、说一下并发啊，这些问题都是要几个小时才能彻底说清楚，建议大家提具体一点的问题。