What is Pulsar 001 ——Pulsar 基础
文章目录
What is Pulsar 001 ——— Pulsar 基础
Apache Pulsar 介绍
什么是Pulsar? 我为什么会接触到Pulsar ？
Pulsar官网对Pulsar的描述 Pulsar官网
Apache Pulsar是最初由Yahoo创建的云原生分布式消息传递和流平台
我为什么会接触到Pulsar？
其实很凑巧，我最初接触Pulsar是因为Pulsar IO，那时候我们公司数据同步基本都是走阿里云DTS方案( 阿里云DTS介绍)，后来发现DTS有时候会影响源库的写入，并且不支持函数处理和数据脱敏，而且相对来说成本也比较大，后面就想着找个实时数据同步方案替代DTS，当时Pulsar版本是2.5.2，通过Pulsar-IO Source的Debezium Mysql订阅Mysql binlog日志进而实现数据实时同步，不过Pulsar提供的Sink并不支持同步DDL（数据定义语言）语句，后来我们重写了Pulsar BinLog Souce及Pulsar Sink以支持DML（数据操纵语言）、DDL、UPSERT操作，这个在后续的文章中会有介绍，这里我先以Pulsar IO简单画个图，如下：
由此打开了Pulsar的大门，对Pulsar的逐渐学习过程中，遇到很多困难，不过随着对Pulsar的了解，也愈发想写一些文章来分享关于Pulsar，目前来说Pulsar在国内的普及度不是很高，所以也想尽自己的微薄之力来推动Pulsar在中国的发展，不过回过头说Pulsar的社区是真的挺活跃…
贴一下 Pulsar GitHub地址
话不多说，接下来进入 What is Pulsar 001 Pulsar 基础
我们从三个方面引入Pulsar 分别是 Connect、Store、Process
Connect 层面
Pulsar具有自己的Pub/Sub模型，同时Pulsar IO的功能，可以非常方便的将数据源导入到Pulsar或从Pulsar中导出 Pulsar官网对于Pulsar IO的描述
Store 层面
Pulsar架构比较亮眼的一点就是存储与计算分离，最开始使用Bookkeeper作为分布式存储，后续增加了通过JCloud和HDFS等多种模式进行的存储选择
Process 层面
Pulsar提供了一个无线存储的抽象，方便第三方平台进行更好的批流融合的计算
目前Pulsar包含以下几类集成融合处理方式：
Pulsar Function
Pulsar自带的函数处理 Pulsar官网关于Pulsar Function的描述
这是Pulsar官网中对于Pulsar Function的示意图，从图中我们可以看到Pulsar Function起到类似"路由"的功能，根据某些规则将已有数据按照这些规则进行数据清洗然后进入到不同的Topic中（下面会解释Topic是什么）
Pulsar-Flink connector和Pulsar-Spark connector：作为批流融合计算引擎，Flink 和 Spark 都提供流计算的机制，Pulsar支持这两种流式计算
Presto (Pulsar SQL)
Pulsar 与 Presto 有很好的集成处理，你可以用 SQL 在 Pulsar 进行处理
Pulsar各组件的介绍以及
Tenant & Namespace
Pulsar是是一个层级化管理结构，也就是 Tenant，Tenant 下有 namespace（命名空间），然后再往下走就是 topic
三层的结构有利于把 Pulsar 做成多租户系统进行管理公司等需要多层结构的组织。这些策略的组织成为后期 Pulsar 运维和管理上更巧妙的一种方式,Pulsar 为了支持统一化的消息平台，引入了 Topic Domain 的概念，默认消息是可持久化的。所以通过这种层级化结构，可以使 Pulsar 更适配不同的应用场景
Producer（生产者）
消息的生产方，所有消息调用生产方的接口，来将消息发送给 Pulsar，同时发送的数据会带上 schema（后面会介绍~） 信息，Pulsar 会确保一个 Producer 往 Topic 发送的消息是满足一定的 schema 格式
Topic（主题）
是一个消息的集合，所有生产者的消息，都会归属到指定的 Topic 里。所有在 Topic 里的消息，会按照一定的规则，被切分成不同的分区（Partition），一个分区会落靠在某一个服务器上，原理类似于 Kafka Topic Partition
Partition （分区）
每个Partition（分区）就是一个 stream（无穷无尽的数据流）。Pulsar 给用户提供了 partition 的逻辑抽象，底层物理存储将逻辑的 partition 划分为多个分片（Segment），均匀存储在所有节点上，利用 Apache BookKeeper 的存储，按照一定的规则生成新的 segment，比较灵活
上图中，Segment 由多条 entry 组成，entry 就是真正意义上组织和存储的力度，entry 里是由更多的消息（Message）通过匹配进行批量组成的，从下图的架构层级就可以更容易地看出，需要从哪个层面进行相应的处理。（图中以一个 Segment 为例）
上图中，最底层的 message 通常包含 Message ID，字段则一般由这几个：ledger-id（在哪个 segment）、entry-id（entry 在这个 segment 的位置）、batch-id（消息被匹配后的位置）、partition-index（消息在 topic 的哪个 partition）
Broker
分区（partition）落靠的服务器就是Broker，用来接收和发送消息，生产方连接Broker去生产消息，消费方连接Broker去消费消息，这其中有个需要注意的是数据不会真正存储在Broker，Pulsar中的Broker是没有存储状态的
Subscription
Consumer 作为消息的接收方，连接到 broker 消费消息，在Pulsar中将 consumer 接收消息的过程称为 Subscription，类似于 Kafka 的 consumer group。一个订阅里的所有 consumer，会作为一个整体去消费这个 topic 里的所有消息
Subscription Mode
Pulsar里每一个订阅都会有不同的模式。目前 Pular 的订阅模式主要是以下四种：
-
Exclusive：独占订阅模式
不管有多少个 consumer 同时存在，只会有一个 consumer 是活跃的，也就是只有这一个 consumer 可以接收到这个 topic 的所有消息
-
Failover：故障转移订阅模式
多个 consumer 可以附加到同一订阅。但是，对于给定的主题分区，将选择一个 consumer 作为该主题分区的主使用者，其他 consumer 将被指定为故障转移消费者，当主消费者断开连接时，分区将被重新分配给其中一个故障转移消费者，而新分配的消费者将成为新的主消费者。发生这种情况时，所有未确认的消息都将传递给新的主消费者
- Shared：共享订阅模式
是可以将所需数量的 consumer 附加到同一订阅。消息以多个 consumer 的循环尝试分发形式传递，并且任何给定的消息仅传递给一个 consumer。当消费者断开连接时，所有传递给它并且未被确认的消息将被重新安排，以便发送给该订阅上剩余的 consumer。
- Key_Shared：Key 保序共享订阅模式
2.4.0 以后一个新订阅模式。类似于共享订阅，但又不是按照循环模式，是按照 key 进行分发，比如同一特征（奇数、偶数等）。总的来说是融合了 Failover 的有序性和 Shared 的消费扩展性、更均衡的一种订阅模式。
Cursor
Cursor 在消费者端，代表了每个订阅组的消费状态。所有订阅状态的管理，都给到了 broker，追踪每个订阅消费到了哪里，并存储到 cursor。然后提供到客户端接口 Acknowledge Cumulatively，后续再进行相应的操作，比如移动或重置
Reader
它的消费状态不被持久化的消费者进行消费。它的消费状态只在内存里出现，指定 Reader 在 Topic 上从何处开始处理消，Reader不会保留数据或确认消息
What is Pulsar 001 ——— Pulsar 基础就到这里结束了~ 后续我会逐渐更新更多关于Pulsar 相关的文章