基于Redis和MySQL的架构，如何保证数据一致性？

今天分享一道一线大厂公司高频面试题。“基于Redis和MySQL的架构，如何保证数据一致性”。这个问题难倒了不少工作5年以上的程序员，难的不是问题本身，而是解决这个问题的思路。

1

背景介绍

一般情况下，Redis是用作应用程序和数据库之间读操作的缓存，主要目的是减少数据库IO，还可以提升数据的IO性能。如图所示，这是Redis加MySQL的整体架构设计。

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

 在这样一个架构中，会出现一个问题，就是一份数据，同时保存在数据库和Redis中，当数据发生变化的时候，需要同时更新Redis和MySQL，由于更新是有先后顺序的，这这种两边写入的环境下，并不能像单纯数据库的操作一样，可以满足ACID特性。因此，就有可能出现一方更新失败，一方更新成功的情况，从而出现数据一致性问题。

2

解决思路

如果出现数据一致性问题，我们该如何解决呢？一般会想到以下两种解决思路。

要么先更新数据库，再更新缓存；

要么先删除缓存，再更新数据库。

如果是采用先更新数据库，再更新缓存的方案，也会有这样一个问题。假设缓存更新失败，就会导致数据库和Redis中的数据不一致。

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

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

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

再比如，还可以直接通过Canal组件，来监控MySQL中Binlog的日志，把更新后的数据同步到Redis中。

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

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

3

总结

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

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

大家一定要记住，某个技术方案不可能适用于所有的业务场景，只有最合适的方案，没有最优的方案。