apache pulsar关注点

Overview

最近看到mq这块, kafka很火(star 16k), 而且融入了scala. 那么市场上其alternative apache pulsar表现如何? 所以clone(v2.5.2)下来粗略看了看, 下面是个人对其的关注点

Architect

cluster level

一个pulsar cluster由以下组件构成,

pulsar cluster, credit: apache

broker是中间层
zk是服务发现, 选主和集中配置
bookKeeper是持久化层
- quorum replica机制, broker通过BK client并发发送写操作到N个bookies(副本), 然后等待相关bookies返回quorum ack, 接着返回ack给producer, 并投递该msg给consumer²

类似hdfs federation或者elasticsearch cross-cluster, 通过global zk来关联2个不同cluster, 实现了数据的异地geo/异集群的传输/备份replica

instance level

单个Pulsar实例由一个或多个Pulsar集群组成. 实例中的集群之间可以相互复制数据

pulsar instance, credit: tibco

pulsar instance - 通过geo replica, consumer C1和C2就可以消费到producer P3的send msg, 因为cluster ABC都是share同一个topic即T1, credit: apache

broker

broker相当于es coordinator, 作为一个中间层, 起承转合

broker本身是无状态的, 所以可以很好的水平扩展scaling,

提供topic服务
处理message传输

client

Pulsar推出了支持Java, Go, Python和C++的客户端API

PuslarAPI封装了客户端到broker端的通信协议, 暴露出一套API供应用程序使用

独立client只是其中一个操作pulsar instance/cluster的方式, 还有另外的2种方式,

admin REST api
- e.g., curl http://localhost:9092/admin/v2/persistent/{tenant}/{namespace}, 类似es的curl
pulsar-admin CLI
- e.g., sh bin/pulsar-admin topics list tenant/cluster/namespace

broker service discovery

client要与bookie进行交互(index or query)都需要经过broker

这个模块就提供一个http server(jetty), 用于client发送http来round-robin zk上存着的可用brokers

可用brokers与http server之间的通信桥梁是zk, 即conf配置

It keeps list of active available brokers and redirects all incoming requests to one of the broker in round-robin manner

String zookeeperServers = config.getInitParameter("zookeeperServers");

functions

类似一个小型flink/spark/MR框架, 可以部署到现有的broker上(实现复用)

有一个dashboard, 但是UI肯定没有spark那么丰富, 可以看到lineage DAG, resource

不过对于simple应用(map, flatMap)等, 就可以比较快速简单实现, 不用引入3rd party

IO

外部组件作为source/sink与pulsar的连接

io connector, credit: apache

3类processing guarantee,

at-most-once
at-least-once
effectively-once

processing guarantee

transaction

base on CompletableFuture thenCompose

SQL

base on presto

需要单独起sql-worker, 即运行sh ${PRESTO_HOME}/bin/launcher run

bootstrap

使用standalone模式来过一遍启动时会经历哪些状态,

create pulsarConfiguration include zk
- conf/standalone.conf
broker
- zk
- bookKeeper
- loadManager(ResourceUnit)
- webService(admin REST api)
- startLeaderElectionService(zk-Watcher-notify-recursively)
create nameSpace for tenant

performance benchmark

一般从以下2个方面入手选择适合业务系统的messaging system/streaming platform,

latency: 固定量(size-mb)的数据从生产到被消费确认所需的时间(time-sec)
throughput: 单位时间(time-sec)内最大的数据发送/接收量(size-mb)

latency

kafkaesque³在2019年从以下方面详细给出了关于latency的benchmark,

project	sub-item	remark	kafka	pulsar
latency	publishing latency	消息发送到被messaging system ack的时间	x	y
-	end-to-end latency	消息发送到被consumer ack的时间	x	y
durability	enable	开启写磁盘(flush)的持久化	x	y
-	disable	-	x	y
replication	enable	多数据副本	x(leader-follower)	y(bookKeeper quorum)
-	disable	零副本	x	y
workloads partition	1	分区数	x	y
-	6	-	x	y
-	16	-	x	y

从报告来看, 小结如下,

在end-to-end latency, kafka延迟更低; 但pulsar方差更小(smooth)
在publishing latency, pulsar延迟更低且更smooth
相比单分区, 在增加分区partition时, pulsar表现出延迟更低; 而kafka则相反其多分区延迟比单分区更高
在开启durability的情况下, pulsar延迟更低

但是评论区也有人指出应该使用多brokers来做benchmark, that make sense making benchmark workloads closer to PRD env

throughput

在2018年给出了pulsar吞吐量更高的结论^2,4, 但是也有有不同观点⁵

kafka - 在提高latency方面, kafka也有往quorum转? 但是当下的基于primary-backup对容错支持更好⁶. 不过kafka越来越独立自成系统了

pulsar - 站在了bookKeeper和zk等第三方框架的肩膀上. 但是也实现了存储和服务分离, scaling很好

个人比较喜欢pulsar的分离设计, 大大提高了可扩展性, 可以更好地增加partition来应对突发流量, 而不像kafka那样需要人工介入rebalance/reassign⁷

当然对于kafka主动脱离zk而自管理metadata也很期待

Referene

PREVIOUSpiano learning

NEXTeaten japanese buffets in singapore