canal系列~原理

一 说明

1. canal本身是一个管道,binlog通过管道进入,然后处理,再从管道出去,binlog是在canal端进行过滤的.所以对於单实例多库来说是推送全部binlog的
2. 整个canal的解析流程大致分成4步。binlog dump -- parse -- sink -- kafka(rocketmq)
3. 我们可以把canal理解成拥有过滤规则的从库,不过要将处理过的日志打入kafka而已
4. kafka是canal的主要接收者

二 具体流程说明-三个核心指标

• Put: Canal Server从MySQL拉取到数据后，放到内存中，Put增加
• Get: 消费者（Canal Client）从内存中消费数据，Get增加
• Ack: 消费者消费完成，Ack增加。并且会删除Put中已经被Ack的数据

三 延时问题监控

1. canal_instance_traffic_delay{destination="example"} / 1000 Server与MySQL master之间的延时。
2. canal_instance_put_delay{destination="example"} / 1000 Store put操作时间点的延时。
3. canal_instance_get_delay{destination="example"} / 1000 Client get操作时间点的延时。
4. canal_instance_ack_delay{destination="example"} / 1000 Client ack操作时间点的延时。

四 延时问题思考

1.  源端短时间内产生大量binlog,canal需要进行过滤处理,导致负载升高,同时消费端消费能力也不能及时消费,导致延时-主要原因-上游
2. 对于接收端是kafka的,canal解析完就会源源不断的打入kafak中,如果kafka产生消息积压,canal也会导致延时-下游