数据蜂巢架构演进之路

标签：业务   需求   mys   服务   偏差   process   pie   运行时   ESS   

各业务系统为使用mysql的业务数据，重复开发出多套数据同步工具，一方面难以管理，另外部分工具性能也偏差。需要一个统一为mysql数据提供同步服务的平台。该平台需支持离线同步，实时订阅，实时同步三大基本功能

架构

一、功能整合

1、各功能如何实现？

离线同步：可理解为将根据一个sql查询出的数据同步到其它目标存储上；

实时订阅：通过实时解析mysql-binlog,将数据的变动封装成事件存于消息队列，供用户订阅消费；

实时同步：提供一些常见的订阅客户端料现，实时消费消息，将数据的变动应用于目标存储上。

2、如何将三个功能集成在一个平台架构下？

将离线同步，实时订阅，实时同步三个需求抽象为三种作业，分别为BatchJob,StreamJob,PieJob。

i. BatchJob参考Sqoop的模式，将需同步的数据先根据指定的规则进行分片，然后将作业根据分片拆分成多个任务，每个任务只同步本分片的数据，多个任务可同时运行，以加快同步效率；

ii. 以BatchJob的模式为基础，StreamJob也可根据需要采集的mysql实例分成多个任务，每个任务负责采集解析一个mysql的binlog，并将解析后的事件封装成消息存于本地供订阅者消费；

iii. PieJob是对订阅客户端的封装，每一个订阅客户端即可看作一个任务。

三种不同的作业最终都可以通过分片分成多个任务去运行，使用统一的模型。

二、任务细节

以下为各个Job进行分片后生成的Task内部具体实现细节

1、BatchTask

Fetcher负责抽取数据，Sinker负责写入数据，Storage为缓存层。

2、StreamTask

RelayLogTask负责拉取binlog；HHLTask负责解析Binlog,并将解析出的数据变更事件封装为易使用的消息体，最后存入hhl中。

hhl的实现借鉴了Kafka，可看作一个简易版的消息队列。消息使用protobuf序列化，压缩后顺序写入文件。同时提供了指定大小的索引块。

在StreamTask中提供了一个ClientServer负责处理客户端的订阅请求

3、PieTask

PieTask实际是对客户端的封装，这里主要介绍一下客户端的实现。

客户端采用并发处理的模式，connector负责接收消息，paritioner负责分发消息交给不同的Processor(线程)处理。

因客户端需自己记录当前处理的位点，但又要保障在并发场景下记录的位点之前的消息都已被正确处理。为了减少线程间阻塞，使用了环形数组的提交方式（记录位点）

三、集群

1、高可用

i.Mysql：mysql的高可用由dba维护，但mysql主从切换后对应的位点会不同，此处通过监测serverId的变更来发现主从切换，主机切换后通过时间在新实例上查找对应位点；

ii.Queen：通过zookeeper来实现Active与StandBy的切换

iii.Bee：宕机后Queen会将该主机上运行的所有任务切换到其它机器上

2、数据本地性

每一台Bee都有自己的机柜，机架，机房，分组信息。作业运行时可以指定自己的喜好，任务会优先分到指定的机器分组上

3、负载均衡

Bee在运行时会通过心跳汇报自己负载情况，当一个任务需要调度时，Queen会在满 足数据本地性的前提下优先将任务分发到负载低的主机上

四、子集群

原架构高度依赖Queen，当Bee与Queen断开连接后任务会立刻停止（防止Queen重新调度，进行多次执行）。但在库房环境下，当库房内部网络正常但与Queen网络不通时，因为库房的Bee全为同一分组，同时库房的任务只能分到对应库房内，此时同步任务将无法运行。为适应该场景，使用了子集群方案，具有特定分组信息的Bee启动时会和同一分组的机器先自发组建子集群，并推选Master,随后由子集群的Master与Queen进行交互。此时，对于需要发送给子集群的作业，Queen下放调度权限给子集群，由子集群的master负责调度。而Queen只负责作业状态的监控及生命周期的全局控制。同时该版本去除了对Zookeeper的依赖。

数据蜂巢架构演进之路

标签：业务   需求   mys   服务   偏差   process   pie   运行时   ESS   

原文地址：https://www.cnblogs.com/z12568/p/10663967.html