文章目录
概述
在分布式系统中，保证Redis和MySQL之间的数据一致性是一个复杂且重要的问题。由于Redis是内存数据库，而MySQL是磁盘数据库，它们的特性和持久化方式不同，因此需要特殊的注意和处理来确保数据的一致性。
以下是一些常见的方法来保证Redis和MySQL之间的数据一致性：
- 双写模式：在进行写操作时，先将数据写入MySQL，然后再将数据写入Redis。这种方式可以保证MySQL中的数据一定会被同步到Redis中，但是对于读操作来说效率较低。
- 异步更新：在进行写操作时，只将数据写入MySQL，然后异步地将数据写入Redis。这种方式可以提高写入操作的效率，但是可能会导致Redis中的数据与MySQL中的数据存在一定的延迟。
- 通过消息队列实现数据同步：可以使用消息队列（如Kafka、RabbitMQ等）来实现MySQL和Redis之间的数据同步。当MySQL中的数据发生变化时，将变化的数据写入消息队列，然后Redis订阅消息队列，根据消息内容更新自己的数据。这种方式可以实现异步更新，并且解耦了MySQL和Redis之间的直接依赖。
- 定期全量同步：定期从MySQL中读取全量数据，然后覆盖Redis中的数据。这种方式可以保证Redis中的数据与MySQL中的数据完全一致，但是对于大数据量的情况下可能会影响性能。
- 使用分布式事务：在一些场景下，可以使用分布式事务来保证Redis和MySQL之间的数据一致性。例如，可以使用基于XA协议的分布式事务管理器（如Seata）来协调Redis和MySQL之间的数据更新操作。
需要根据具体的业务场景和需求选择合适的数据一致性方案，并进行相应的设计和实现。同时，还需要考虑各种异常情况下的处理，如网络故障、节点宕机等，以确保系统在异常情况下依然能够保持数据一致性。
解决方案
1.基于 MQ 异步同步更新，消息队列+异步重试-比如基于 RocketMQ 的可靠性消息通信，来实现最终一致
2.还可以直接通过 Canal （阿里的一款开源框架）组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面。
3.延时双删
缓存延时双删
删除缓存重试机制
读取biglog异步删除缓存
一般情况下，Redis 用来实现应用和数据库之间读操作的缓存层，主要目的是减少数据库 IO，还可以提升数据的 IO 性能。这是它的整体架构
当应用程序需要去读取某个数据的时候，首先会先尝试去 Redis 里面加载，如果命中就直接返回。如果没有命中，就从数据库查询，查询到数据后再把这个数据缓存到 Redis 里面。
在这样一个架构中，会出现一个问题，就是一份数据，同时保存在数据库和 Redis里面，当数据发生变化的时候，需要同时更新 Redis 和 Mysql，由于更新是有先后顺序的，并且它不像 Mysql 中的多表事务操作，可以满足 ACID 特性。所以就会出现数据一致性问题。
在这种情况下，能够选择的方法只有几种
先更新数据库，再更新缓存
先删除缓存，再更新数据库
如果先更新数据库，再更新缓存，如果缓存更新失败，就会导致数据库和 Redis中的数据不一致。
如果是先删除缓存，更新数据库，理想情况是应用下次访问 Redis 的时候，发现 Redis 里面的数据是空的，就从数据库加载保存到 Redis 里面，那么数据是一致的。但是在极端情况下，由于删除 Redis 和更新数据库这两个操作并不是原子的，所以这个过程如果有其他线程来访问，还是会存在数据不一致问题
如果需要在极端情况下仍然保证 Redis 和 Mysql 的数据一致性，就只能采用最终一致性方案。
消息队列+异步重试 基于 RocketMQ 的可靠性消息通信，来实现最终一致
因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制
删除缓存重试流程
- 写请求更新数据库
- 缓存因为某些原因，删除失败
- 把删除失败的key放到消息队列
- 消费消息队列的消息，获取要删除的key
- 重试删除缓存操作
Canal 组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面
因为这里是基于最终一致性来实现的，如果业务场景不能接受数据的短期不一致性，那就不能使用这个方案来做
异步更新缓存(基于订阅binlog的同步机制)
MySQL binlog增量订阅消费+消息队列+增量数据更新到redis读Redis
热数据基本都在Redis写MySQL:增删改都是操作MySQL更新Redis数据：MySQ的数据操作binlog，来更新到Redis：
1)数据操作主要分为两大块：一个是全量(将全部数据一次写入到redis)一个是增量(实时更新)。
这里说的是增量,指的是mysql的update、insert、delate变更数据。
2)读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。
这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。
其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。
这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。
当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis
重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。其实，还可以这样优化：通过数据库的binlog来异步淘汰key。
以mysql为例吧
● 可以使用阿里的canal将binlog日志采集发送到MQ队列里面
● 然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性
延时双删
redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)先删除缓存，再更新数据库，当更新数据后休眠一段时间再删除一次缓存。
这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。
这种方案还算可以，只有休眠那一会（比如就那1秒），可能有脏数据，一般业务也会接受的。但是如果第二次删除缓存失败呢？缓存和数据库的数据还是可能不一致，对吧？给Key设置一个自然的expire过期时间，让它自动过期怎样？那业务要接受过期时间内，数据的不一致咯？还是有其他更佳方案呢？
弱一致性和强一致性
数据同步过程中，会存在短暂的延迟，这属于正常的现象。
在分布式架构中很难实现数据强一致性
弱一致性： 主从之间数据允许不一致性；
强一致性： 主从之间数据必须一致性； 如果实现 成本是非常高，会设计到 一些锁的技术，
最终一致性：短暂的数据延迟是允许的，但是最终数据是需要一致; ---在分布式中做数据同步需要经过网络传输的，网络传输数据需要一定的时间， 所以数据短暂的延迟是允许的，但是最终数据一定达成一致。
延迟是很难避免的，优化 减少延迟的时间。 公司中数据 同步延迟 优化在 10-30 毫秒。
Canal详解
Canal 是阿里巴巴开源的数据库变更捕获（CDC）解决方案，主要用于监控数据库的变更，并将这些变更推送到其他数据存储、消息队列等目标端。以下是对 Canal 的详细解释：
- 工作原理：
○ Canal通过连接数据库的binlog日志，实时解析binlog日志中的数据变更（如insert、update、delete等操作），将这些变更解析成数据库行记录的格式，并推送到外部系统。
○ Canal分为客户端和服务端两部分。客户端（Agent）位于数据库服务器上，负责与数据库的binlog日志进行交互，并将解析后的数据变更推送给服务端。服务端（Server）接收客户端推送的数据变更，并将其发送到目标存储或消息队列。 - 特点：
○ 实时性：Canal能够实时捕获数据库的变更，几乎可以做到毫秒级的实时性。
○ 可靠性：Canal保证数据变更的完整性和准确性，可以应对数据库主从切换、网络闪断等异常情况。
○ 高性能：Canal使用了一系列性能优化措施，如异步化处理、多线程并发等，保证了高性能的数据变更捕获和传输。 - 应用场景：
○ 数据同步：将数据库的变更同步到其他数据存储（如另一个数据库、Hadoop、Elasticsearch等）。
○ 实时监控：实时监控数据库的变更情况，用于数据审计、报警等用途。
○ 缓存更新：将数据库的变更用于更新缓存，提高系统性能和响应速度。
○ 搜索引擎索引更新：将数据库的变更同步到搜索引擎（如Elasticsearch）中，用于实时更新索引。 - 支持的数据库：
○ Canal目前主要支持MySQL数据库，包括MySQL的各种版本，如MySQL5.x、MySQL8.x等。 - 架构图：
○ Canal的架构包括客户端（Agent）和服务端（Server）两部分，客户端负责与数据库的binlog交互，服务端负责接收客户端推送的数据变更并处理。
○ 具体的架构图可以参考官方文档或源码。
总的来说，Canal是一个功能强大的数据库变更捕获解决方案，可以实现实时的数据库变更监控和同步，广泛应用于数据同步、实时监控等场景。
方案二：还可以直接通过 Canal 组件，监控 Mysql 中 binlog 的日志，把更新后的数据同步到 Redis 里面。