Pulsar基础（一）——Pulsar介绍

Pulsar介绍

Apache Pulsar 是一个云原生企业级的发布订阅（pub-sub）消息系统，于2016年开源，Apache软件基金会顶级开源项目。Pulsar在Yahoo的生产环境运行了三年多，助力Yahoo的主要应用，如Yahoo Mail、 Yahoo Finance、Yahoo Sports、Flickr、Gemini广告平台和Yahoo分布式键值存储系统Sherpa

Pulsar的功能与特性

多租户模式（Multi-tenancy）

• Pulsar能为特定的租户预留合适的存储空间、应用授权与认证机制
• 一个租户中可以由多个命名空间
• Pulsar在命名空间层中，有一系列配置策略（policy），包括存储配额、流量监控、消息过期策略和不同命名空间的隔离策略。

优点：

• 多租户技术可以实现多个租户之间共享系统实例，同时又可以实现租户的系统实例的个性化定制。

• 通过使用多租户技术可以保证系统共性的部分被共享，个性的部分被单独隔离。通过在多个租户之间的资源复用，运营管理维护资源，有效节省开发应用的成本。

• 在租户之间共享应用程序的单个实例，可以实现当应用程序升级时，所有租户可以同时升级。

• 多个租户共享一份系统的核心代码，因此当系统升级时，只需要升级相同的核心代码即可。

灵活的消息系统

• Pulsar做了队列和流模型的统一，在Topic只需要保存一份数据，这份数据可以多次消费。以流式、队列等方式计算不同的订阅模型。
• Pulsar通过事务采用Exactly-Once，在进行消息传输的过程中，可以保证数据不丢失、不重复。

云原生架构

• Pulsar 使用计算与存储分离的云原生架构，数据从 Broker 搬离，存在共享存储内部。

• 上层是无状态 Broker ，复制消息分发和服务

• 下层是持久化的存储层 Bookie 集群

• Pulsar 存储是分片的，这种构架可以避免扩容 时受限制，实现数据的独立扩展和快速恢复

Segmented Streams 分片流

• Pulsar 将无界的数据看作是分片的流，分片分散存储在分层存储（tiered storage）、BookKeeper 集群和 Broker 节点上，而对外提供一个统一的、无界数据的视图。

• 不需要用户显式迁移数据，减少存储成本并保持近似无限的存储

支持跨地域复制

• Pulsar 中的跨地域复制是将 Pulsar 中持久化的消息在多个集群间备份。

• 在 Pulsar 2.4.0 中新增了复制订阅 模式(Replicated-subscriptions)，在某个集群失效情况下，该功能可以在其他集群恢复消费者的消费状态， 从而达到热备模式下消息服务的高可用。

Pulsar组件介绍

层级存储

• Infinite Stream：以流的方式永久保存原始数据
• 分区容量不再受到限制
• 充分利用存储或现有的廉价存储（HDFS等）
• 数据统一表征：客户端不需要关心数据存储位置。

Pulsar IO 连接器

• Pulsar IO分为Input和Output两个模块，通过Source实现数据输入。通过Sink实现数据输出
• Pulsar提供了Connector，用于解决Pulsar于周边系统的集成问题
• 目前Pulsar支持HDFS、Spark、Flume、ES、HBase等

Pulsar Funcations（轻量级计算框架）

• Pulsar Functions 是一个轻量级的计算框架，可以给用户提供一个部署简单、运维简单、API 简单的 FASS（Function as a service）平台。

• Pulsar Functions 提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。

• 用户可以轻松地部署和管理 function，通过 function 从 Pulsar topic 读取数据或者生产新数据到 Pulsar topi

与Kafka对比

对比方面	Kafka	Pulsar
模型概念	producer – topic – consumer group – consumer	producer – topic -subsciption- consumer
消费模式	主要集中在流(Stream) 模式, 对单个partition是独占消费, 没有共享(Queue)的消费模式	提供了统一的消息模型和API. 流(Stream) 模式 – 独占和故障切换订阅方式 ; 队列(Queue)模式 – 共享订阅的方式
消息确认	使用偏移量 offset	使用专门的cursor管理. 累积确认和kafka效果一样; 提供单条或选择性确认
消息保留	根据设置的保留期来删除消息, 有可能消息没被消费, 过期后被删除, 不支持TTL	消息只有被所有订阅消费后才会删除, 不会丢失数据,. 也运行设置保留期, 保留被消费的数据 . 支持TTL

根本区别：Apache Pulsar和Apache Kafka之间的根本区别在于Apache Kafka是以分区为存储中心，而Apache Pulsar是以Segment为存储中心

性能对比：Pulsar性能比Kafka强许多，速度是Kafka的五倍，延迟降低了40%（数据来源于 GigaOm）

kafka存在的问题

• Kafka 很难进行扩展，因为 Kafka 把消息持久化在 broker 中，迁移主题分区时，需要把分区的数据完全复制到其他 broker 中，这个操作非常耗时。

• 当需要通过更改分区大小以获得更多的存储空间时，会与消息索引产生冲突，打乱消息顺序。因此，如果用户需要保证消息的顺序，Kafka 就变得非常棘手了。

• 如果分区副本不处于 ISR（同步）状态，那么 leader 选取可能会紊乱。一般地，当原始主分区出现故障时，应该有一个 ISR 副本被征用，但是这点并不能完全保证。若在设置中并未规定只有 ISR 副本可被选为 leader 时，选出一个处于非同步状态的副本做 leader，这比没有 broker 服务该 partition的情况更糟糕。

• 使用 Kafka 时，你需要根据现有的情况并充分考虑未来的增量计划，规划 broker、主题、分区和副本的数量，才能避免 Kafka 扩展导致的问题。这是理想状况，实际情况很难规划，不可避免会出现扩展需求。

• Kafka 集群的分区再均衡会影响相关生产者和消费者的性能。

• 发生故障时，Kafka 主题无法保证消息的完整性（特别是遇到第 3 点中的情况，需要扩展时极有可能丢失消息）。

• 使用 Kafka 需要和 offset 打交道，这点让人很头痛，因为 broker 并不维护 consumer 的消费状态。

• 如果使用率很高，则必须尽快删除旧消息，否则就会出现磁盘空间不够用的问题。

• 众所周知，Kafka 原生的跨地域复制机制（MirrorMaker）有问题，即使只在两个数据中心也无法正常使用跨地域复制。因此，甚至 Uber 都不得不创建另一套解决方案来解决这个问题，并将其称为 uReplicator (https://eng.uber.com/ureplicator/)。

• 要想进行实时数据分析，就不得不选用第三方工具，如 Apache Storm、Apache Heron 或 Apache Spark。同时，你需要确保这些第三方工具足以支撑传入的流量。

• Kafka 没有原生的多租户功能来实现租户的完全隔离，它是通过使用主题授权等安全功能来完成的