pulsar篇——基本介绍

发表于 | | 阅读次数: |

1. pulsar是什么？

Apache Pulsar is a cloud-native, distributed messaging and streaming platform。和kafka比较像，由于站在了前人的肩膀上，它做的要比kafka更加出色。

pulsar的关键特性如下：

  1. 云原生架构（计算与存储分离），无缝支持跨集群复制
  2. 比kafka更高的吞吐量和低延迟
  3. 无缝支持上百万个topics
  4. 支持多种消息订阅模式 (exclusive & shared & failover)
  5. 通过持久化存储BookKeeper保障消息的传递
  6. 轻量级Serverless计算框架Pulsar Functions提供了流式数据处理能力。
  7. 提供分层存储能力，释放BookKeeper的空间：将老数据or长期不用的数据放到AWS S3等

Pulsar架构模型类似于Client->Proxy->Server

2. pulsar的架构简介

2.1 pulsar的分层架构

与其他消息系统不同，Pulsar抽象为两层架构：

  • 无状态服务层：处理消息的Broker组成
  • 有状态存储层：BookKeeper存储节点组成，可以持久化的存储消息

Broker无状态层

与kafka不同，Pulsar Broker不存储实际的数据，而是将消息存储在BookKeeper中，仅仅拥有Topic/Partitions的代理权。它屏蔽了msg复杂的读写流程，保证了数据一致性和负载均衡。meta信息是存储在zookeeper中，消息存储到BookKeeper中。

BookKeeper

Pulsar用 Apache BookKeeper作为持久化存储。 BookKeeper是一个分布式的预写日志（WAL）系统，特性主要有：

  • 支持创建多个独立的ledgers（Fragment/Segment）随着时间的推移，底层数据以 Ledger形式存储，Pulsar会为Topic创建多个ledgers。
  • 为按条目复制的顺序数据提供了非常高效的存储。
  • 保证了多系统挂掉时ledgers的读取一致性。
  • 提供不同的Bookies（BookKeeper实例）均匀的IO分布的特性。
  • 容量和吞吐量都能水平扩展。并且容量可以通过在集群内添加更多的Bookies立刻提升。
  • Bookies被设计成可以承载数千的并发读写的ledgers。 使用多个磁盘设备，一个用于日志，另一个用于一般存储，这样Bookies可以将读操作的影响和对于写操作的延迟分隔开。

除了消息数据，cursors也会被持久化入BookKeeper。 Cursors是消费端订阅消费的位置。 BookKeeper让Pulsar可以用一种可扩展的方式存储消费位置

2.2 pulsar的订阅模式

  • 独占订阅：一个消费组只有一个消费者订阅消息。
  • 故障切换（Failover）：多个消费者可以加入同一订阅，但是只有一个消费者被选为主消费者，其他消费者为故障转移者。
  • 共享订阅：订阅组可以挂多个消费者，但一个消息只会传递给一个消费者。

2.3 broker故障处理fencing

Pulsar的broker不存储状态，类似于Topic的proxy，拥有对Topic的代理权，当broker故障时，Pulsar需要将这些topic转移给正常的brokers，这个过程称为fencing。大致流程为：

  1. Topic X 的当前拥有者(B1)不可用(通过Zookeeper);
  2. 其他Broker(B2)将Topic X 的当前Ledger状态从OPEN修改为IN_RECOVERY
  3. B2向Ledger的当前Fragment的Bookies发送fence信息并等待(Qw-Qa) + 1个Bookies响应。收到此响应数后Ledger将变成fenced。如果旧的Broker仍然处于活跃状态则无法再进行写入，因为无法获得Qa确认(由于fencing导致异常响应);
  4. B2然后从Fragment的Bookies获得他们最后确认的条目是什么。它需要最新条目的ID，然后从该点开始向前读。它确保从哪一点开始的所有条数(可能以前未向Pulsar Broker承认)都会被复制到Qw Bookies。一旦B2无法读取并复制任何条目，Ledger将完全恢复;
  5. B2将Ledger的状态更改为CLOSED;
  6. B2现在可以创建新的Ledger并接受写入请求。

整个过程类似于raft的选举，选举过程中不处理读写请求。

3. pulsar vs kafka

3.1 特性对比

消费模式

  • kafka对partition是独占消费，没有共享Queue的消费模式。
  • Pulsar提供了统一的消息模型和API，提供了队列的共享订阅方式。

消息确认

  • kakfa使用offset
  • Pulsar使用cursor管理，累计确认和kafka效果一致，额外提供了选择性确认。

消息保留

  • 设置保留期来删除消息，没被消费的数据过期也会被删除，不支持TTL
  • 消息被订阅消费才会被删除，不会丢失数据。也可以设置保留期，支持TTL。

3.2 优势对比

pulsar相对kafka而言，优势：

  • broker无状态支持更低成本扩容，无须重新分配现有数据。
  • 提供分层存储，支持比如S3类型的分布式存储，一定程度上能提高数据的可用性。
  • 支持多租户。
  • 地域复制更加友好，基于仲裁的算法能保障集群是一致的。

劣势：

  • pulsar项目较新，社区活跃不足，而kafka更加成熟，社区更加活跃。
  • kafka仅依赖broker和zk，而pulsar额外依赖bookKeeper，增加了系统的复杂性。

4. 参考