题5：Redis 做为缓存，MySQL 的数据如何与 Redis 进行同步呢？（双写一致性）
读写锁方案
项目需要让 MySQL 与 Redis 尽量保持较强一致性，所以我们当时采用的是redisson实现的分布式读写锁。在读数据的时候添加共享锁，允许多个线程并发读取，读读不互斥，在写数据的时候，添加互斥锁，写操作期间不允许其他读写线程进入。写操作流程
- 获取互斥锁
- 更新 MySQL
- 删除 Redis 缓存
- 释放锁
这样能减少脏数据，因为写数据期间禁止读，避免读线程在数据库更新期间读取旧数据并重新写回缓存，从而减少缓存脏数据问题。要注意读方法和写方法必须使用同一把锁。
题6：那这个排他锁是如何保证读写、写写互斥的呢？
排他锁底层核心思想类似 Redis 的 SETNX。因为 SETNX 是原子操作，所以同一时间只有一个线程能够加锁成功，其他线程会获取失败并等待。因此可以保证同一时间只有一个线程进入临界区(访问共享资源的代码区域)，从而实现互斥。
题7：你听说过延迟双删吗？为什么不用它呢？
延迟双删也是一种常见的缓存双写一致性方案。
它的流程是：
- 删除 Redis 缓存
- 更新 MySQL
- 延迟一段时间
- 再次删除 Redis 缓存
之所以需要第二次删除，是因为在第一次删除缓存之后，数据库更新期间，可能有其他线程查询旧数据库数据，并重新写回缓存，因此需要再次删除缓存。
不过由于第二次删除是延迟执行的，而延迟时间又不太容易确定，在这段时间内，其他线程仍然可能读取到旧缓存数据，因此延迟双删本质上只能保证最终一致性。
题8：Redis 做为缓存，MySQL 的数据如何与 Redis 进行同步呢？（Canal 方案）
我们做的这个业务允许存在一定的数据同步延迟，因此我们采用了阿里的 Canal 组件实现缓存同步。Canal 不需要侵入业务代码，只需要部署一个 Canal 服务即可。它会伪装成 MySQL 的从节点，监听 MySQL 的 binlog 日志。当 MySQL 数据发生更新后，Canal 会读取 binlog 变更数据，然后由 Canal 客户端消费这些变更信息，并更新 Redis 缓存。相比业务代码中手动删除缓存，这种方案的优势是业务解耦，业务层只需要负责更新数据库，缓存同步交给 Canal 统一处理。
不过由于 Canal 本质上是异步同步，因此它只能保证最终一致性。