【Canal源码分析】数据传输协议

Canal的数据传输有两块,一块是进行binlog订阅时,binlog转换为我们所定义的Message,第二块是client与server进行TCP交互时,传输的TCP协议。

一、EntryProtocal

这块是binlog的一个存储。主要的格式如下:

Entry
    Header
        version         [协议的版本号,default = 1]
        logfileName     [binlog文件名]
        logfileOffset   [binlog position]
        serverId        [服务端serverId]
        serverenCode    [变更数据的编码]
        executeTime     [变更数据的执行时间]
        sourceType      [变更数据的来源,default = MYSQL]
        schemaName      [变更数据的schemaname]
        tableName       [变更数据的tablename]
        eventLength     [每个event的长度]
        eventType       [insert/update/delete类型,default = UPDATE]
        props           [预留扩展]
        gtid            [当前事务的gitd]
    entryType           [事务头BEGIN/事务尾END/数据ROWDATA/HEARTBEAT/GTIDLOG]
    storeValue          [byte数据,可展开,对应的类型为RowChange]    
RowChange
    tableId             [tableId,由数据库产生]
    eventType           [数据变更类型,default = UPDATE]
    isDdl               [标识是否是ddl语句,比如create table/drop table]
    sql                 [ddl/query的sql语句]
    rowDatas            [具体insert/update/delete的变更数据,可为多条,1个binlog event事件可对应多条变更,比如批处理]
        beforeColumns   [字段信息,增量数据(修改前,删除前),Column类型的数组]
        afterColumns    [字段信息,增量数据(修改后,新增后),Column类型的数组] 
        props           [预留扩展]
    props               [预留扩展]
    ddlSchemaName       [ddl/query的schemaName,会存在跨库ddl,需要保留执行ddl的当前schemaName]
Column 
    index               [字段下标]      
    sqlType             [jdbc type]
    name                [字段名称(忽略大小写),在mysql中是没有的]
    isKey               [是否为主键]
    updated             [是否发生过变更]
    isNull              [值是否为null]
    props               [预留扩展]
    value               [字段值,timestamp,Datetime是一个时间格式的文本]
    length              [对应数据对象原始长度]
    mysqlType           [字段mysql类型]

二、CanalProtocal

这块主要定义了client和server交互的协议。

Packet
    magic_number    [default = 17]
    version         [default = 1]
    type            [PacketType,类型]
    compression     [压缩,default = NONE]
    body            [具体内容]

主要的类型和对应的body,都可以在CanalProtocal.proto里面查看到。

enum PacketType {
    HANDSHAKE = 1;
    CLIENTAUTHENTICATION = 2;
    ACK = 3;
    SUBSCRIPTION = 4;
    UNSUBSCRIPTION = 5;
    GET = 6;
    MESSAGES = 7;
    CLIENTACK = 8;
    // management part
    SHUTDOWN = 9;
    // integration
    DUMP = 10;
    HEARTBEAT = 11;
    CLIENTROLLBACK = 12;
}
//心跳
message HeartBeat {
    optional int64 send_timestamp = 1;
    optional int64 start_timestamp = 2;
}

//握手
message Handshake {
    optional string communication_encoding = 1 [default = "utf8"];
    optional bytes seeds = 2;
    repeated Compression supported_compressions = 3;
}

// client authentication
message ClientAuth {
    optional string username = 1;
    optional bytes password = 2; // hashed password with seeds from Handshake message
    optional int32 net_read_timeout = 3 [default = 0]; // in seconds
    optional int32 net_write_timeout = 4 [default = 0]; // in seconds
    optional string destination = 5;
    optional string client_id = 6;
    optional string filter = 7;
    optional int64 start_timestamp = 8;
}

//服务端响应
message Ack {
    optional int32 error_code = 1 [default = 0];
    optional string error_message = 2; // if something like compression is not supported, erorr_message will tell about it.
}

//客户端提交
message ClientAck {
    optional string destination = 1;
    optional string client_id = 2;
    optional int64 batch_id = 3;
}

// subscription
message Sub {
    optional string destination = 1;
    optional string client_id = 2;
    optional string filter = 7;
}

// Unsubscription
message Unsub {
    optional string destination = 1;
    optional string client_id = 2;
    optional string filter = 7;
}

//  PullRequest
message Get {
    optional string destination = 1;
    optional string client_id = 2;
    optional int32 fetch_size = 3;
    optional int64 timeout = 4 [default = -1]; // 默认-1时代表不控制
    optional int32 unit = 5 [default = 2];// 数字类型,0:纳秒,1:毫秒,2:微秒,3:秒,4:分钟,5:小时,6:天
    optional bool auto_ack = 6 [default = false]; // 是否自动ack
}

//消息
message Messages {
    optional int64 batch_id = 1;
    repeated bytes messages = 2;
}

// TBD when new packets are required
message Dump{
    optional string journal = 1;
    optional int64  position = 2;
    optional int64 timestamp = 3 [default = 0];
}

// 客户端回滚
message ClientRollback{
    optional string destination = 1;
    optional string client_id = 2;
    optional int64 batch_id = 3;
}

转载于:https://www.cnblogs.com/f-zhao/p/9110575.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在上一篇文章中,我们介绍了使用 Canal 分析 Binlog 的基本流程和使用方法。本文将继续深入探讨 Canal源码实现。 Canal 的架构设计 Canal 的整体架构可以分为三个部分:Client、Server、Store。其中,Client 是客户端,用于连接 MySQL 数据库并获取 Binlog;Server 是服务端,用于接收 Client 发送的 Binlog,并进行解析处理;Store 是存储层,用于保存解析后的 Binlog 信息。 在 Client 端,Canal 使用了阿里开源的 Cobar 连接池,保证了高并发的连接请求。对于每一个连接,Canal 都会为其分配一个线程,用于读取 Binlog 并发送到 Server 端。 在 Server 端,Canal 采用 NIO 的方式进行网络通信。当收到 Binlog 数据后,Canal 会将其解析为一条条的事件,并将事件发送给所有监听该实例的客户端。同时,Canal 还支持对 Binlog 进行过滤和转换,以满足不同的业务需求。 在 Store 层,Canal 提供了多种存储方式,包括内存、文件、Kafka、MQ 等。用户可以根据自己的需求进行选择。 Canal 的核心实现 在分析 Canal 的核心实现之前,我们需要先了解一下 Binlog 的结构。Binlog 是 MySQL 用于记录数据库变更的一种日志格式,其主要由 event header 和 event data 两部分构成。其中,event header 包含了事件类型、时间戳、server id 等信息,event data 则包含了具体的事件内容。 Canal 的核心实现主要包括两个部分:BinlogParser 和 CanalEventParser。 BinlogParser 用于解析 Binlog,并将其转化为事件对象。在解析 Binlog 时,BinlogParser 首先会读取 event header,然后根据 event header 中的事件类型选择相应的 CanalEventParser 进行处理。CanalEventParser 则负责将 event data 解析为具体的事件对象。 CanalEventParser 实现了一系列的事件解析器,包括 QueryEventParser、TableMapEventParser、WriteRowsEventParser 等。每个事件解析器都负责将 event data 转化为相应的事件对象,并填充事件对象中的各个字段。例如,WriteRowsEventParser 将 event data 解析为 WriteRowsEvent,并设置其对应的表名、列名、新插入的行等信息。 Canal 的事件模型 Canal 的事件模型主要由 CanalEvent 和 CanalEventSink 两部分构成。CanalEvent 表示一个数据库事件,包括事件类型、事件数据、表名、库名等信息。CanalEventSink 则表示一个事件处理器,用于接收并处理 CanalEvent。 在 Canal 中,每个客户端都会创建一个对应的 CanalEventSink,并将其注册到 Server 端。当 Server 端接收到 Binlog 数据并解析为 CanalEvent 后,会将 CanalEvent 发送给所有注册的 CanalEventSink。CanalEventSink 则根据事件类型进行相应的处理,例如将 InsertEvent 存储到数据库中。 Canal 的优点和缺点 Canal 的主要优点在于其高效、可扩展和灵活的架构设计。Canal 使用了阿里开源的 Cobar 连接池和 NIO 网络通信,保证了高并发的连接请求和网络数据传输。同时,Canal 的存储层也支持多种存储方式,可以根据用户需求进行选择。此外,Canal 还支持对 Binlog 进行过滤和转换,以满足不同的业务需求。 Canal 的缺点在于其对 MySQL 版本有一定的限制。由于 Binlog 格式在不同的 MySQL 版本之间存在差异,因此 Canal 只支持特定版本的 MySQL,且需要用户手动配置相应的 Binlog 格式。此外,Canal 无法保证数据的完整性,如果在解析 Binlog 过程中出现异常,可能会导致部分数据丢失。 总结 Canal 是一款高效、可扩展和灵活的 Binlog 解析工具,可以帮助用户实现对 MySQL 数据库变更的监控和同步。Canal 的核心实现包括 BinlogParser 和 CanalEventParser,其中 BinlogParser 用于解析 Binlog,CanalEventParser 则负责将 event data 转化为具体的事件对象。Canal 的事件模型主要由 CanalEvent 和 CanalEventSink 两部分构成,可以根据用户需求进行灵活配置。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值