基于canal client實現canal同步es的示例分析

這期內容當中小編將會給大家帶來有關基于canal client實現canal同步es的示例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

canal是阿里開源的一款純java語言的mysql增量訂閱工具,主要是偽裝成slave節點,向mysql發送 dump協議官方原理如圖:

官方的解釋:    

                          server代表一個canal運行實例，對應于一個jvm

                          instance對應于一個數據隊列 （1個server對應1..n個instance)

個人是這么理解的instance當做一個mq中的topic隊列(kafka中的broker),canal client相當于mq中的消費者.instance接收到數據通過parse解析之后經過sink進行數據加工,最后存儲到sore中,由canal client來進行消費.

          由于業務數據量較大,單表超億,根據實際業務對數據庫進行分庫分表,es中存儲主鍵和賬號對應關系,訪問數據庫時先送es中獲取主鍵再查db,這樣可以直接打到對應分片上秒回

         起初打算采用官方提供的工具實現,后續發現官方的不太符合我們的需求(或許是自己沒搞明白官方的工具),并切我們是分庫分表的,按照官方的配置太過繁瑣.一個表到底層就分了幾百張表,所以決定就基于canal client自己實現了同步es,全量和增量.不過踩了不少得吭.

        采用es的bulk api批量更新 .設置自定義模板,后續翻閱官方的源碼,其實大致也是這么實現的,只不過官方的具有通用性而已.

        啟動方法:

 連接canal server代碼:

解析binlog的代碼也很簡單,不過自己實現的不具備通用性,勿噴:

將數據進行組裝批量提交:

就這個不困擾了.es和msyql總是差那么10-100條不等,后續找到的原因,由于設置批量是1000,而數據庫更新操作tps較低,所以造成兩者之間數據延時.將批量數逐個降低測試最后調整到50批次,es和mysql數據時延降低到毫級了.

全量同步的較為簡單.個人是這樣實現的.首先將mysql中20億數據量導出到文本文件,我們只需要主鍵和賬號兩個字段即可,并且是分庫分表的,導出非常快.1億的數據量30秒以內全部導出.然后通過緩沖流一行一行讀取文件,調用bulk api批量入es,es 5個數據節5分片一副本,單節點40核物理機 內存512G jvm設置31G raid0 sas盤,1億數據量基本5分鐘以內就可導入es中,目前線上運行2月沒發現異常.

上述就是小編為大家分享的基于canal client實現canal同步es的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。