项目场景：

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

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

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

        ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。

 

解决方案：

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

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

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

        如果是先删除缓存，再更新数据库，理想情况是应用下次访问 Redis 的时候，发现 Redis 里面的数据是空的，就从数据库加载保存到 Redis 里面，那么数据是一致的。

        但是在极端情况下，由于删除 Redis 和更新数据库这两个操作并不是原子的，所以这个过程如果有其他线程来访问，还是会存在数据不一致问题。

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

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

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

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

也会有人说：“你这个最终一致性方案”还是会存在数据不一致的问题啊？那怎么解决？ 先不用慌，技术是为业务服务的，所以不同的业务场景，对于技术的选择和方案的设计 是不同的，所以这个时候，可以反问面试官，具体的业务场景是什么？ 一定要知道的是，一个技术方案不可能 cover 住所有的场景，明白了吗？