前言
在进行冷热分离的时候,需要将数据实时的复制在历史数据库中,我们使用的是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
————————————————