对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

本文作者为江谋晶，谊品生鲜高级研发工程师。主导数据管道零碎的设计与研发，借助 Apache Pulsar 作为数据同步工具，并落地实现增量数据同步的各种利用场景需要。他打算进一步实现数据管道的平台化及可视化，并接入更丰盛的数据库类型反对。

背景

数据管道，就是让数据通过肯定的传输介质，从一个地点达到另一个地点，从而实现数据的同步或复制，来满足利用需要。随着业务量及数据量的的大幅增长，咱们现有的微服务须要再度细化（拆分）。

零碎拆分如何做到让用户无感知呢？上线时，通过分流策略将局部用户引流到新的服务中，要求新老零碎并行运行一段时间来撑持新服务的试运行到齐全落地，从而最大水平上缩小生产故障。为了让新服务数据可能与旧零碎服务中的数据实时统一，就须要同步数据。随着数据量大幅增长，要放慢查问速度，能够将数据复制到 ElasticSearch 中，进步查问速率。

市场上有相干的开源数据同步产品和商业版数据通道工具，不须要人工染指即可实现双边的数据同步复制。但零碎重构可能会产生一些表构造或表对象的变动，无奈兼容商业的数据同步，须要开发人员染指进行相干解决。咱们采纳了 Maxwell + Pulsar 的自研解决方案：应用 Maxwell 读取 binlog，Pulsar 进行数据传输。Maxwell + Pulsar 实现下层的数据读取，上游业务方实现对应的数据同步逻辑。比方，针对零碎重构拆分的数据同步业务场景以及读写拆散，将数据复制同步到相似 ElasticSearch 搜索引擎中的业务场景。

为何抉择 Pulsar?

在数据管道的零碎重构中，咱们抉择 Apache Pulsar 的起因如下：

• 无状态。微服务架构体系中，中间件最好是无状态的。这样启动快，能够随时替换并且能够实现无缝伸缩，弹性扩大。Kafka 不是无状态的，每个 Broker 都蕴含了分区所有的日志，如果一个 Broker 宕机，并非任意一个 Broker 能够来接管，也不能随便增加 Broker 来分担负载，Broker 之间必须进行状态同步。在 Pulsar 架构中，数据从 Broker 剥离，存储在共享贮存外部；下层是下层是无状态的计算层（Broker），复制音讯散发和服务（计算），上层则是长久化的存储层（Bookie）。所以数据计算和存储互相独立，能够实现数据的独立扩大和疾速复原。
• Pulsar 反对流解决和传统的音讯队列，大大晋升了订阅灵便度。
• Pulsar 云原生的架构不便程度弹性扩大，且反对跨地区复制。
• Pulsar 反对分区，吞吐高，提早低。
• 开源社区沉闷，技术支持响应快、服务好。

Pulsar 如何保障分布式生产过程中的程序

首先，咱们理解一下 Pulsar 的订阅模式。Pulsar 有四种订阅模式：exclusive 模式（独占模式）、failover 模式（故障转移模式）、Shared 模式（共享模式）以及 Key_Shared 模式。Exclusive 模式只有一个消费者（consumer），接管一个 Topic 所有的音讯。

Failover 模式中，同一时刻只有一个无效的消费者，其余的消费者作为备用节点，在主消费者（master consumer）不可用后进行代替（该模式实用于数据量小、解决单点故障的场景）。

Shared 模式中，多个消费者能够连贯到同一订阅主题。音讯以轮询的形式散布在各个消费者之间，任何给定的音讯仅传递给一个消费者。起初咱们采纳 Shared 模式，因为 Shared 模式具备分布式生产能力，生产速度快。但在生产过程中发现源数据库数据与同步的指标库（ElasticSearch、MySQL）频繁呈现数据偏差和数据不统一的问题。经排查发现，是生产程序错乱导致的，当用户频繁操作某条数据产生了多条 MQ 音讯时，Shared 模式下，多个消费者并行生产音讯了。

Pulsar 在 2.4.0 版本基于 Shared 模式推出了 Key_Shared 模式。在 Key_Shared 模式下，多个消费者能够附加到同一订阅。音讯在各个使用者之间进行散发，具备雷同 key 或雷同订购 key 的音讯仅投递给一位消费者，不论音讯从新发送多少次，它都会被发送到同一使用者。当消费者连贯或断开连接时，服务的消费者会更改某些音讯 Key（密匙）。Key_Shared 模式保障在 Shared 模式下同一个 Key 的音讯会发送到同一个消费者，在并发的同时保障程序性。

数据同步场景对音讯的程序要求十分高。当用户不断更新某条数据时，数据库表中对应的记录也在不断更新。数据量大高并发时，须要保障用户变更数据产生的音讯程序与其操作程序统一，否则会呈现同步的该条数据与源数据不统一，产生系统故障。

程序问题是分布式生产过程中常见的问题。为了保障客户端的有序生产，咱们采纳 Key_Shared 订阅模式。Key_Shared 模式是 Shared 订阅模式拓展，一个分区能够有几个消费者并行生产音讯，但具备雷同 key 的音讯只路由给一个消费者。其原理是通过哈希来确定指标使用者，每个生产端提供固定范畴的哈希值；散列值的整个范畴能够笼罩所有的生产端。而后生产音讯时指定 key（如下所示），造成闭环，就能够实现有序的寄存至指定的分区以及音讯有序的生产。具体原理及用法能够参考 Pulsar 官网。

key：{"database":"you_db_name","table":"you_table_name","pk.id":"you_table_Primary key"}

如何过滤反复音讯?

音讯的传输保障个别有三种：At least once、At most once 和 Exactly once。

• At least once：每条音讯会进行屡次传输尝试，至多胜利一次，即音讯可能反复但不会失落;
• At most once：每条音讯最多传输一次，音讯可能会失落；
• Exactly once：每条音讯只传输一次，音讯传输既不会失落也不会反复。

在数据同步场景下，要最大化保障音讯的可达性，咱们使用 Maxwell 的 At least once 模式，尽可能保障音讯传输。在网络不现实时，音讯可能曾经投递至指标，但接管到超时响应或者未接管胜利，Pulsar 会再次投递，从而产生了“反复音讯”。

为了解决反复音讯的问题，咱们在数据管道数据链路模型中减少了过滤器，过滤一些反复、有效、重试的音讯。

总结

在须要同步大量增量数据的场景下，咱们采纳了 Maxwell + Pulsar 的自研解决方案，Pulsar Key_Shared 订阅模式是否很好解决分布式音讯生产过程中的程序问题，在数据管道数据链路中增设过滤器，能保障音讯不重不漏。

后续咱们打算基于现有的解决方案，充分利用 Pulsar 的个性，将数据管道做成可视化的数据同步中台，接入更多的数据库扩大、欠缺的监控和日志体系。

相干浏览

• Apache Pulsar 在能源互联网畛域的落地实际
• Apache Pulsar 在腾讯 Angel PowerFL 联邦学习平台上的实际

点击 链接，获取 Apache Pulsar 硬核干货材料！