携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第24天,点击查看活动详情
每日英语:
I hope you have the strength to start all over again.
翻译:我希望你能有勇气重新启程。 -《本杰明·巴顿奇事》
1.缓存一致性canal实现
之前的几篇虽然我们实现了多级缓存架构,但是问题也出现了,如果数据库中数据发生变更,如何更新Redis缓存呢?如何更新Nginx缓存呢?
针对上面的问题,我们可以使用阿里巴巴的技术解决方案Canal来实现,通过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。
1.1 Canal原理讲解
讲Canal的原理,我们先来了解一下MySQL主备复制原理。
MySQL主备复制原理:
- MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events,可以通过 show binlog events 进行查看)
- MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
- MySQL slave 重放 relay log 中事件,将数据变更反映它自己的数据
Canal工作原理:
- canal 模拟 MySQL slave 的交互协议,伪装自己为 MySQL slave ,向 MySQL master 发送dump 协议
- MySQL master 收到 dump 请求,开始推送 binary log 给 slave (即 canal )
- canal 解析 binary log 对象(原始为 byte 流)
1.2 MySQL开启binlog
找到我们之前配置mysql本地镜像的位置
cd /root/mysql/conf/
修改两个配置文件my.conf和my.cnf
我们先来修改my.conf 配置,vim my.conf 配置如下:
[client]\
default-character-set=utf8\
[mysql]\
default-character-set=utf8\
[mysqld]\
init_connect='SET collation_connection = utf8_unicode_ci'\
init_connect='SET NAMES utf8'\
character-set-server=utf8\
collation-server=utf8_unicode_ci\
skip-character-set-client-handshake\
skip-name-resolve
再来修改my.cnf的配置,vim my.cnf 配置如下:
[mysqld]\
log-bin=/var/lib/mysql/mysql-bin\
server-id=123654\
expire_logs_days = 30
保存之后,执行下面的操作:
docker restart mysql #重启mysql
docker exec -it mysql bin/bash #docker启动mysql客户端
mysql -u root -p
show variables like '%log_bin%'; #查看是否生效
总结:本篇主要介绍了一下Canal原理,还有MySQL如何binlog。大家可以去着手操作一下。