前言

在進行冷熱分離的時候，需要將數據實時的復制在歷史數據庫中，我們使用的是binlog+canal的思想,將每次數據庫數據的變更轉換成消息發出來,然后再操作這些消息達到數據復制的
在京東,實現同樣功能的組件，叫binlake
接下來詳細說下:

1.Binlog

mysql有多種日志，常見的有:

錯誤日志（ErrorLog）

更新日志（UpdateLog）

二進制日志（Binlog）

查詢日志（QueryLog）

慢查詢日志（SlowQueryLog）

Binlog可以說是MySQL最重要的日志了，它記錄了所有的DDL和DML(除了數據查詢語句)語句，以事件形式記錄，還包含語句所執行的消耗的時間，此外Binlog是事務安全型的。
Binlog一般作用是可以用于實時備份，與master/slave主從復制結合。

2.Canal

Canal是應阿里巴巴存在杭州和美國的雙機房部署，存在跨機房同步的業務需求而提出的。
Canal作為阿里巴巴提供的開源的數據抽取項目，能夠做到實時抽取，原理就是偽裝成mysql從節點，讀取mysql的binlog，生成消息，客戶端訂閱這些數據變更消息，處理并存儲
github : https://github.com/alibaba/canal

3.Binlake

BinLake堅持技術和資源共享的原則，為京東商城各個業務部門提供統一的資源和技術服務，各個業務部門通過使用BinLake服務，避免的重復投入人力對同一項技術進行研究，避免了各個部門為了滿足同一種業務需求而重復申請資源，進而避免的資源浪費，避免的各個業務部門重復投入人力和物力進行數據庫日志采集、管理、分發、訂閱系統的運維。

Binlake架構圖:

1.BinLake總共包括三大服務組件：

1.1 Wave服務

Wave服務完成實際的數據庫Binary Log的持續采集、管理和分發寫入到下游的消息發布和訂閱系統中。在BinLake集群中會存在N個Wave服務，這些Wave服務共同組成一個無狀態集群。

1.2 Tower服務

Tower服務是整個BinLake的管理中心，提供BinLake接入服務的申請、完成Wave服務、數據源、接入應用的管理。當用戶申請接入到BinLake中時，會登錄到Tower服務提供的申請界面，填寫申請接入BinLake的應用信息、數據源信息和Topic信息，Tower服務會按照用戶提供的信息做如下判斷，并完成用戶接入申請，接入流程如下:

如果不同申請者申請相同數據源的數據采集，由Tower管理端依據其申請的采集規則（如指定表，指定庫），如果規則相同，默認復用相同規則的Topic，也可強制生成新的Topic進行訂閱。

1.3 Judge服務

Judge服務主要完成兩個功能：Wave節點監控信息采集和loadBalance決策。
Wave節點監控信息采集：
通過在各個Wave服務節點部署agent采集各個Wave服務節點上的監控信息，包括：服務器的內存使用、系統負載、CPU負載、網絡負載、JVM的堆內存使用、GC信息、每個Wave服務中的instance個數等，采集到的所有這些信息都會在后續的loadBalance中作為基礎metics，參與到最終的loadBalance決策中。
loadBalance決策：
新應用接入到BinLake時，若需要采集的數據源在BinLake現有的數據源池中不存在，則需要針對于新的數據源在相應的Wave服務上創建對應的instance（數據源與instance是1對1的關系）。那么在創建instance的時候，就需要選在在哪個Wave服務上創建。這時就會請求Judge服務提供的loadBalance決策接口，若Judge服務中沒有配置loadBalance plugin，則會返回一個隨機的Wave服務節點的IP，那么就會在該隨機的Wave服務上創建instance；若配置了loadBalance的plugin，則從Judge服務提供的loadBalance決策接口獲得建議Wave服務節點，并從該節點創建新的instance。

2.BinLake依賴于兩大外部服務：

2.1 ZooKeeper

BinLake使用zookeeper服務進行Wave無狀態集群的管理、狀態同步和消息通知等，包括：
【1】Instance的自動化創建與初始化
【2】Instance的HA
【3】數據源offset實時追蹤
【4】binlog分發失敗重試
【5】數據源切換自適配
【6】Tower元數據管理
【7】instance消息通知

2.2 消息發布與訂閱系統

目前BinLake可以無縫集成JMQ和Kafka，從而進行消息的發布和訂閱管理。instance采集到的BinLog Event會發布到JMQ或者Kafka的Topic中，實際的業務應用只需要訂閱和消費對應的topic，既可以實時的獲得BinLog Event，并在后續的業務邏輯中對獲得的Binlog Event進行處理即可。

BinLake部署拓撲

在BinLake服務實際部署時，其拓撲結構如下：

對上述部署拓撲圖說明如下：

（1）一臺Tower服務器：用于用戶元數據、過濾規則、應用和訂閱信息管理

（2）2N+1臺ZooKeeper服務器：用于構建一個zookeeper集群，從而進行Wave集群管理和消息通知等

（3）一臺Judge服務器：用戶采集負載信息，并提供負載均衡建議決策。其中負載信息的采集是通過部署在各個Wave服務器上的Judge-Agent進程定期推送給Judge服務的

（4）N臺Wave服務器：構成Wave集群。每臺Wave服務器上部署兩種服務：

【1】Wave服務：用于數據庫binary log的采集并分發給下游MQ集群（Kafka或者JMQ）

【2】Judge-Agent服務：用于定期采集Wave服務器的系統以及Wave服務的負載和監控信息，并調用Judge服務提供的Restful接口，推送給Judge服務

（5）N臺已經存在的線上MySQL服務器：不屬于BinLake提供的服務器，是使用的已經存在的MySQL服務器，作為BinLake的數據源

（6）N臺已經存在的MQ服務器：不屬于BinLake提供的服務器，是已經存在的MQ服務器，處于Wave服務的下游，Wave服務會將采集到的Bianry Log Events分發給MQ集群中的Topic

總結

以上是生活随笔為你收集整理的[数据库]---mysql数据库 使用binlog+canal或binlake进行数据库的复制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。