怎么做班级网站,江西南昌网站建设服务,做网站的规范尺寸,虚拟主机商Canal介绍
canal [kənl]#xff0c;译意为水道/管道/沟渠#xff0c;主要用途是基于 MySQL 数据库增量日志解析#xff0c;提供增量数据订阅和消费
canal可以用来监控数据库数据的变化#xff0c;从而获得新增数据#xff0c;或者修改的数据。
canal是应阿里巴巴存在杭…Canal介绍
canal [kənæl]译意为水道/管道/沟渠主要用途是基于 MySQL 数据库增量日志解析提供增量数据订阅和消费
canal可以用来监控数据库数据的变化从而获得新增数据或者修改的数据。
canal是应阿里巴巴存在杭州和美国的双机房部署存在跨机房同步的业务需求而提出的。
阿里系公司开始逐步的尝试基于数据库的日志解析获取增量变更进行同步由此衍生出了增量订阅消费的业务。
canal主要用途是基于 MySQL 数据库增量日志解析并能提供增量数据订阅和消费应用场景十分丰富。
目前canal主要支持mysql数据库。
github地址https://github.com/alibaba/canal
版本下载地址https://github.com/alibaba/canal/releases
文档地址https://github.com/alibaba/canal/wiki/Docker-QuickStart
Canal应用场景
1、电商场景下商品、用户实时更新同步到至Elasticsearch、solr等搜索引擎 2、价格、库存发生变更实时同步到redis 3、数据库异地备份、数据同步 4、代替使用轮询数据库方式来监控数据库变更有效改善轮询耗费数据库资源。 MySQL主从复制原理
1、MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events可以通过 show binlog events 进行查看) 2、MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log) 3、MySQL slave 重放 relay log 中事件将数据变更反映它自己的数据 Canal工作原理 canal 模拟 MySQL slave 的交互协议伪装自己为 MySQL slave 向 MySQL master 发送 dump 协议 MySQL master 收到 dump 请求开始推送 binary log 给 slave (即 canal ) canal 解析 binary log 对象(原始为 byte 流)
Canal安装
参考文档https://github.com/alibaba/canal/wiki/QuickStart
Canal配置
mq相关参数说明 (1.1.5版本)
在1.1.5版本开始引入了MQ Connector设计参数配置做了部分调整 参数名 参数说明 默认值 canal.aliyun.accessKey 阿里云ak 无 canal.aliyun.secretKey 阿里云sk 无 canal.aliyun.uid 阿里云uid 无 canal.mq.flatMessage 是否为json格式 如果设置为false,对应MQ收到的消息为protobuf格式 需要通过CanalMessageDeserializer进行解码 false canal.mq.canalBatchSize 获取canal数据的批次大小 50 canal.mq.canalGetTimeout 获取canal数据的超时时间 100 canal.mq.accessChannel local 是否为阿里云模式可选值local/cloud local canal.mq.database.hash 是否开启database混淆hash确保不同库的数据可以均匀分散如果关闭可以确保只按照业务字段做MQ分区计算 true canal.mq.send.thread.size MQ消息发送并行度 30 canal.mq.build.thread.size MQ消息构建并行度 8 kafka.bootstrap.servers kafka服务端地址 127.0.0.1:9092 kafka.acks kafka为ProducerConfig.ACKS_CONFIG all kafka.compression.type 压缩类型 none kafka.batch.size kafka为ProducerConfig.BATCH_SIZE_CONFIG 16384 kafka.linger.ms kafka为ProducerConfig.LINGER_MS_CONFIG , 如果是flatMessage格式建议将该值调大, 如: 200 1 kafka.max.request.size kafka为ProducerConfig.MAX_REQUEST_SIZE_CONFIG 1048576 kafka.buffer.memory kafka为ProducerConfig.BUFFER_MEMORY_CONFIG 33554432 kafka.max.in.flight.requests.per.connection kafka为ProducerConfig.MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION 1 kafka.retries 发送失败重试次数 0 kafka.kerberos.enable kerberos认证 false kafka.kerberos.krb5.file kerberos认证 ../conf/kerberos/krb5.conf kafka.kerberos.jaas.file kerberos认证 ../conf/kerberos/jaas.conf rocketmq.producer.group rocketMQ为ProducerGroup名 test rocketmq.enable.message.trace 是否开启message trace false rocketmq.customized.trace.topic message trace的topic 无 rocketmq.namespace rocketmq的namespace 无 rocketmq.namesrv.addr rocketmq的namesrv地址 127.0.0.1:9876 rocketmq.retry.times.when.send.failed 重试次数 0 rocketmq.vip.channel.enabled rocketmq是否开启vip channel false rocketmq.tag rocketmq的tag配置 空值 rabbitmq.host rabbitMQ配置 无 rabbitmq.virtual.host rabbitMQ配置 无 rabbitmq.exchange rabbitMQ配置 无 rabbitmq.username rabbitMQ配置 无 rabbitmq.password rabbitMQ配置 无 rabbitmq.deliveryMode rabbitMQ配置 无 pulsarmq.serverUrl pulsarmq配置 无 pulsarmq.roleToken pulsarmq配置 无 pulsarmq.topicTenantPrefix pulsarmq配置 无 canal.mq.topic mq里的topic名 无 canal.mq.dynamicTopic mq里的动态topic规则, 1.1.3版本支持 无 canal.mq.partition 单队列模式的分区下标 1 canal.mq.enableDynamicQueuePartition 动态获取MQ服务端的分区数,如果设置为true之后会自动根据topic获取分区数替换canal.mq.partitionsNum的定义,目前主要适用于RocketMQ false canal.mq.partitionsNum 散列模式的分区数 无 canal.mq.dynamicTopicPartitionNum mq里的动态队列分区数,比如针对不同topic配置不同partitionsNum 无 canal.mq.partitionHash 散列规则定义 库名.表名 : 唯一主键比如mytest.person: id 1.1.3版本支持新语法见下文 无
canal.mq.dynamicTopic 表达式说明
canal 1.1.3版本之后, 支持配置格式schema 或 schema.table多个配置之间使用逗号或分号分隔 例子1test\\.test 指定匹配的单表发送到以test_test为名字的topic上 例子2.*\\..* 匹配所有表则每个表都会发送到各自表名的topic上 例子3test 指定匹配对应的库一个库的所有表都会发送到库名的topic上 例子4test\\..* 指定匹配的表达式针对匹配的表会发送到各自表名的topic上 例子5test,test1\\.test1指定多个表达式会将test库的表都发送到test的topic上test1\\.test1的表发送到对应的test1_test1 topic上其余的表发送到默认的canal.mq.topic值
为满足更大的灵活性允许对匹配条件的规则指定发送的topic名字配置格式topicName:schema 或 topicName:schema.table 例子1: test:test\\.test 指定匹配的单表发送到以test为名字的topic上 例子2: test:.*\\..* 匹配所有表因为有指定topic则每个表都会发送到test的topic下 例子3: test:test 指定匹配对应的库一个库的所有表都会发送到test的topic下 例子4testA:test\\..* 指定匹配的表达式针对匹配的表会发送到testA的topic下 例子5test0:test,test1:test1\\.test1指定多个表达式会将test库的表都发送到test0的topic下test1\\.test1的表发送到对应的test1的topic下其余的表发送到默认的canal.mq.topic值
大家可以结合自己的业务需求设置匹配规则建议MQ开启自动创建topic的能力
canal.mq.partitionHash 表达式说明
canal 1.1.3版本之后, 支持配置格式schema.table:pk1^pk2多个配置之间使用逗号分隔 例子1test\\.test:pk1^pk2 指定匹配的单表对应的hash字段为pk1 pk2 例子2.*\\..*:id 正则匹配指定所有正则匹配的表对应的hash字段为id 例子3.*\\..*:$pk$ 正则匹配指定所有正则匹配的表对应的hash字段为表主键(自动查找) 例子4: 匹配规则啥都不写则默认发到0这个partition上 例子5.*\\..* 不指定pk信息的正则匹配将所有正则匹配的表,对应的hash字段为表名 • 按表hash: 一张表的所有数据可以发到同一个分区不同表之间会做散列 (会有热点表分区过大问题) 例子6: test\\.test:id,.\\..* , 针对test的表按照id散列,其余的表按照table散列
注意大家可以结合自己的业务需求设置匹配规则多条匹配规则之间是按照顺序进行匹配(命中一条规则就返回)
其他详细参数可参考Canal AdminGuide
mq顺序性问题
binlog本身是有序的写入到mq之后如何保障顺序是很多人会比较关注在issue里也有非常多人咨询了类似的问题这里做一个统一的解答 1. canal目前选择支持的kafka/rocketmq本质上都是基于本地文件的方式来支持了分区级的顺序消息的能力也就是binlog写入mq是可以有一些顺序性保障这个取决于用户的一些参数选择 2. canal支持MQ数据的几种路由方式单topic单分区单topic多分区、多topic单分区、多topic多分区 canal.mq.dynamicTopic主要控制是否是单topic还是多topic针对命中条件的表可以发到表名对应的topic、库名对应的topic、默认topic name canal.mq.partitionsNum、canal.mq.partitionHash主要控制是否多分区以及分区的partition的路由计算针对命中条件的可以做到按表级做分区、pk级做分区等 1. canal的消费顺序性主要取决于描述2中的路由选择举例说明 单topic单分区可以严格保证和binlog一样的顺序性缺点就是性能比较慢单分区的性能写入大概在2~3k的TPS 多topic单分区可以保证表级别的顺序性一张表或者一个库的所有数据都写入到一个topic的单分区中可以保证有序性针对热点表也存在写入分区的性能问题 单topic、多topic的多分区如果用户选择的是指定table的方式那和第二部分一样保障的是表级别的顺序性(存在热点表写入分区的性能问题)如果用户选择的是指定pk hash的方式那只能保障的是一个pk的多次binlog顺序性 ** pk hash的方式需要业务权衡这里性能会最好但如果业务上有pk变更或者对多pk数据有顺序性依赖就会产生业务处理错乱的情况. 如果有pk变更pk变更前和变更后的值会落在不同的分区里业务消费就会有先后顺序的问题需要注意
性能表现
Kafka 混合DML场景测试 场景 1个topic 单分区 1个topic3分区 2个topic1分区 2个topic3分区 不开启flatMessage 29.6k rps (9.71k tps) 17.54k rps (6.53k tps) 21.6k rps (7.9k tps) 16.8k rps (5.71k tps) 开启flatMessage 11.79k rps (4.36k tps) 15.97 rps (5.94k tps) 11.91k rps (4.45k tps) 16.96k rps (6.26k tps)
Kafka 单表的batch insert场景测试 场景 1个topic 单分区 1个topic3分区 不开启flatMessage 59.6k rps 45.1k rps 开启flatMessage 51.3k rps 49.6k rps RocketMQ 混合DML场景测试 场景 1个topic 单分区 1个topic3分区 2个topic1分区 2个topic3分区 不开启flatMessage 29.6k rps (10.71k tps) 23.3k rps (8.59k tps) 26.7k rps (9.46k tps) 21.7k rps (7.66k tps) 开启flatMessage 16.75k rps (6.17k tps) 14.96k rps (5.55k tps) 17.83k rps (6.63k tps) 16.93k rps (6.26k tps)
RocketMQ 单表的batch insert场景测试 场景 1个topic 单分区 1个topic3分区 不开启flatMessage 81.2k rps 51.3k rps 开启flatMessage 62.6k rps 57.9k rps
附录
canal官方文档https://github.com/alibaba/canal/wiki/Canal-Kafka-RocketMQ-QuickStart
CanalMQ性能表现https://github.com/alibaba/canal/wiki/Canal-MQ-Performance
参考文档https://www.cnblogs.com/zwh0910/p/17043265.html
