[数据库]---mysql数据库 使用binlog+canal或binlake进行数据库的复制

前言

在进行冷热分离的时候，需要将数据实时的复制在历史数据库中，我们使用的是binlog+canal的思想,将每次数据库数据的变更转换成消息发出来,然后再操作这些消息达到数据复制的
在京东,实现同样功能的组件，叫binlake
接下来详细说下:

1.Binlog

mysql有多种日志，常见的有:

1. 错误日志（ErrorLog）
2. 更新日志（UpdateLog）
3. 二进制日志（Binlog）
4. 查询日志（QueryLog）
5. 慢查询日志（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