接口推送数据原理_数据同步组件（Canal）在珍爱网的应用与实践

最新推荐文章于 2024-06-18 09:49:02 发布

weixin_39850599

最新推荐文章于 2024-06-18 09:49:02 发布

阅读量307

点赞数

文章标签：接口推送数据原理

本文作者：珍爱网技术团队二爷

随着公司业务的不断发展，公司对于实时报表的需求越来越旺盛，原则上来说，实时报表最好的实现方式的通过Spark，storm这类的技术去支撑，由于人手原因，并不能很好的支撑业务，所以，只能靠我们自己去实现，传统的做法的话，通过业务埋点，上报数据的方式，然后再对数据做一些汇总，统计是可以满足我们的需求的，但是埋点方式最大的痛点就是容易遗漏，新增一个业务或者改动业务的时候非常容易忘记埋点，导致报表的需求不正确，所以我们想要一个无埋点的方式来实现这种需求，再经过技术调研之后，发现canal完美的符合我们的需求。

canal简介

canal是基于数据库增量日志解析，提供增量数据订阅和消费的中间件，它主要工作原理是模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议，收到binlog后将binlog解析成Java对象,提供给业务使用.

整体架构

canal向Mysql发送dump命令，并开始下载binlog
Binlog parser模块负责将binlog进行解析
EventSink将解析的binlog进行过滤，加工
EventStore将binlog存储
Zookeeper负责存储消费位点等meta信息

BinlogParser

canal在获取了数据库的链接后，模拟成Slave(详细可以去了解下Mysql的主从协议，canal只是实现了部分主从同步的协议)，像主库发送BINLOG_DUMP命令，主库收到之后开始推送Binlog
从zk拿到上次同步位置后，通过Binlog Parser解析binlog
将解析到的binlog传递给EventSink处理，同时记录binlog解析位点
如果有配置从库，当主库挂了后，会自动从从库获取binlog

EventSink

EventSink主要有以下几个功能：

数据过滤：支持通配符，正式表达式过滤掉binlog，减轻客户端的压力
数据归并：解决分库分表之后数据合并问题
数据加工：在进入到store之前进行额外的处理，比较join
数据路由：解决一个parse多个store的问题

EventStore

用来储存解析出来的binlog，目前只实现了Memory内存(数据放内存已经足够了，因为位点信息放到zk，基本不会丢失数据)，通过RingBuffer设计，提升了数据读取效率。定义了3个cursor:

Put: Sink模块进行数据储存最后一次写入位置
Get: 数据订阅最后一次提取的位置
Ack: 数据消费成功最后一次消费位置

实战

在了解了Canal的原理之后，我们来看看珍爱网用Canal做了哪些事情

实时报表
通过canal来触发时间，对数据进行加工处理后，写入到结果表，延迟可以控制在S级
数据同步
因为业务的需求，我们的表设计是有一些冗余的字段，但是冗余的字段带来的问题是运维困难，通过canal来实现冗余字段的维护，极大了减轻了维护的成本
公司企业业务部门需要使用我们实时的业务数据，通过canal同步，完美解决这个问题

canal的客户端本身来说还不是很完善，为了提升开发效率，我们对canal的客户端进行了一层封装，整体架构如下：

通过canal集群拿到解析好的binlog日志
每个需要使用binlog的工程都有一个单独的data-sync模块，专门来消费canal的日志，并将日志投递到消息服务器(RocketMQ)
业务去订阅MQ消息，来完成各种消息处理

遇到的问题

canal在监控这块比较弱，在项目刚上线的时候，经常会出现canal挂了然后没人知道，运行了好久才发现数据有问题，于是我们对canal进行了监控，主要原理是通过获取canal的消费位点，跟主数据库的position进行对比，如果大于一定的阈值，则进行告警。
最开始的时候没有引入分布式消息队列，通过本地队列的方式+dubbo远程调用来做，消息入本地队列后我们就ack了，如果这段时间重启机器会导致binlog丢失，并且如果dubbo接口比较耗时，会导致canal的延迟比较大