Spring Cloud Alibaba基础练习01: 使用Cannal保持MySQL与Redis数据一致原理

Spring Cloud Alibaba基础教程01: 使用Cannal保持MySQL与Redis数据一致

2020-05-20 19:40:40 星期日

最近一致在研究Spring Cloud Alibaba的一些组件,在这里记录下心得体会,准备整理成一个系列的简单入门,方便日后查看.

---

MySQL与Redis如何保持一致性的问题

首先来看下MySQL与Redis如何保持一致性的问题,我们会将数据放入到Redis中，从而减轻MySQL数据库的访问的压力，如果Redis缓存中没有存在该数据的情况下，则直接查询MySQL的数据，再将MySQL数据缓存到Redis中.

下图左侧为客户端直接调用存储层的架构，右侧为比较典型的缓存层+存储层架构。

使用缓存后的项目收益和成本

收益:

1. 加速读写：因为缓存通常都是全内存的，而存储层通常读写性能不够强悍（例如MySQL），通过缓存的使用可以
2. 有效地加速读写，优化用户体验。
3. 降低后端负载：帮助后端减少访问量和复杂计算（例如很复杂的SQL语句），在很大程度降低了后端的负载。

成本：

1. 数据不一致性：缓存层和存储层的数据存在着一定时间窗口的不一致性，时间窗口跟更新策略有关。
2. 代码维护成本：加入缓存后，需要同时处理缓存层和存储层的逻辑，增大了开发者维护代码的成本。
3. 运维成本：以Redis Cluster为例，加入后无形中增加了运维成本。

---

同步的方案:

1. 手动直接清除Redis缓存，重新查询MySQL即可；
2. 基于阿里巴巴的Canal异步订阅MySQL BinLog文件实现同步

---

阿里巴巴的Canal

阿里巴巴的 canal GitHub的链接: https://github.com/alibaba/canal

canal [kə’næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费,早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。

基于日志增量订阅和消费的业务包括

• 数据库镜像
• 数据库实时备份
• 索引构建和实时维护(拆分异构索引、倒排索引等)
• 业务 cache 刷新
• 带业务逻辑的增量数据处理

当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x

MySQL的主从复制:

• MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
• MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
• MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

简单说:主从复制的原理就是从节点订阅主的mysql服务器，主节点binlog文件发生变化的情况下，将该binlog文件增量的形式同步给从节点服务器，这样的话主和从能够最终保持数据的一致性。

MySQL主从复制作用：

• 对我们的数据实现备份
• 读写分离
• 故障转移
• 简单集群

PS: MySQL主服务器：可以读和写
MySQL从服务器：只能读不能写

canal 工作原理

• canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
• MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
• canal 解析 binary log 对象(原始为 byte 流)

总的来说,Alibaba的Cannal就是把自己伪装成一个MySQL的从节点,订阅MySQL的主节点,拿到主节点的binlog日志,再根据日志里数据库的操作类型,异步把数据同步到Redis里.这里先介绍下Cannal的大概原理,下篇来介绍下具体的使用方法.