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也會導致延時-下游