apache pulsar关注点

Overview

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

Architect

cluster level

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

pulsar cluster, credit: apache

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

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

instance level

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

pulsar instance, credit: tibco

image

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传输

image

client

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

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

image

独立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");

image

functions

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

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

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

image

IO

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

image

io connector, credit: apache

image

3类processing guarantee,

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

image

processing guarantee

transaction

base on CompletableFuture thenCompose

image

SQL

base on presto

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

image


bootstrap

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

image

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

performance benchmark

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

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

latency

kafkaesque3在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, 但是也有有不同观点5

More

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

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

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

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

Referene

  1. apache pulsar
  2. Apache Pulsar分层分片架构
  3. performance comparison between apache pulsar and kafka: latency
  4. Apache Pulsar at Yahoo!JAPAN
  5. Kafka vs. Pulsar vs. RabbitMQ: Performance, Architecture, and Features Compared
  6. Kafka的复制机制
  7. Kafka进行机器扩容后的副本再平衡和为已有分区增加replica实践
  8. How to Configure Apache Pulsar Cluster Geo Replication between Regions on AWS
  9. apache kafka关注点