基于Pulsar实现的数据同步实践

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于Pulsar实现的数据同步实践相关的知识,希望对你有一定的参考价值。

参考技术A 数据同步,就是让数据通过一定的传输介质,从一个地点到达另一个地点,从而实现数据的同步或复制,来满足应用需求。在本人的上一份工作中,随着业务量及数据量的的大幅增长,公司不得不对现有的微服务再度细化(拆分)。公司采用的是基于领域驱动设计的微服务体系,每个领域在需求日益增加的同时,必然会愈来愈大,考虑到业务内聚、系统性能等诸多因素不得不把某些大的领域中心拆分成多个服务。这个过程就是系统重构。

系统拆分如何让用户无感知呢?上线时通过分流策略将部分用户引流到新的服务中,要求新老系统并行运行一段时间来支撑新服务的试运行到完全落地,从而最大化减小生产故障。为了让新服务数据能够与旧系统服务中的数据实时一致,就需要同步数据。随着数据量大幅增长,要加快查询速度,可以将数据复制到 ES(ElasticSearch)中,提高查询速率。

综上总结:如何实现增量数据实时同步?

市场上有相关的开源数据同步产品和商业版数据通道工具,不需要人工任何接入即可实现双边的数据同步复制。但在系统重构时时可能会发生一些表结构的变动以及表对象的一些变动,此时就无法兼容商业的数据同步,当然也可以采纳其中的部分解决方案但还是需要开发人员介入进行相关处理,所以最终,我们采用了 Maxwell + Pulsar 的自研解决方案:使用 Maxwell 读取 binlog(也可以使用 canal ,maxwell实现较简单点),Pulsar 进行数据传输。Maxwell + Pulsar 实现上层的数据读取,下游业务方实现对应的数据同步逻辑。比如,针对系统重构拆分的数据同步业务场景,以及读写分离,将数据复制同步到类似 ElasticSearch 搜索引擎中的业务场景。

该图主要展示核心的数据链路,隐藏日志记录、链路追踪等一些微服务体系中所含有的组件。

Pulsar 有四种消费模式:exclusive 模式(独占模式)、failover 模式 (故障转移模式)、Shared 模式 (共享模式)以及 Key_Shared 模式。

Exclusive 模式只有一个 Consumer,接收一个 Topic 所有的消息。

Key_Shared 模式是 shared 订阅模式拓展,一个分区可以有几个消费者并行消费消息,但具有相同 key 的消息只会路由给一个消费者。其原理则是通过哈希来确定目标的使用者。每个消费端提供固定范围的哈希值,当然散列值的整个范围可以覆盖所有的消费端。

经上所述,对于数据同步的场景,我们将key指定为下面的示例,就可以实现有序的存放至指定的分区以及消息有序的消费啦!

消息的传输保障一般有三种:At least once、At most once 和 Exactly once。

在数据同步场景下,要最大化的保证消息的可达性,可以运用 Maxwell 的 At least once 模式,尽可能保证消息传输。在网络不理想时,消息可能已经投递至目标,但接收到超时响应或者未接收成功,Pulsar 会再次投递,从而产生了我们认为的“重复消息”。

以上是关于基于Pulsar实现的数据同步实践的主要内容,如果未能解决你的问题,请参考以下文章

基于 MySQL Binlog 的 Elasticsearch 数据同步实践

Greenplum 实时数据仓库实践——实时数据同步

Greenplum 实时数据仓库实践——实时数据同步

阿里Canal框架(数据同步中间件)初步实践

基于Go的MongoDB实时同步工具及 Docker 化实践

ZK节点间数据同步以及API实践