01.pulsar基本介绍、多租户模式、云原生架构、Segmented Streams、支持跨地域复制、pulsar组件介绍、Pulsar IO (Connector)、Pulsar与kafka的对比

1.Apache Pulsar基础篇
1.1. 为什么要学习 Apache Pulsar
1.1.1. 什么是云原生
1.1.2.Apache pulsar基本介绍
1.1.2.1.多租户模式
1.1.2.3.云原生架构
1.1.2.4.Segmented Streams(分片流)
1.1.2.5.支持跨地域复制
1.1.3.Apache pulsar组件介绍
1.1.3.1.层级存储
1.1.3.2.Pulsar IO (Connector)连接器
1.1.3.3.Pulsar Functions(轻量级计算框架)
1.1.4.Pulsar与kafka的对比
1.1.4.1.Pulsar和Kafka的对比介绍说明
性能对比
扩展说明：kafka目前存在的痛点

1.Apache Pulsar基础篇

1.1. 为什么要学习 Apache Pulsar

1.1.1. 什么是云原生

云原生的概念是2013年Matt Stine提出的,到目前为止, 云原生的概念发生了多次变更, 目前最新对云原生定义为: DevOps + 持续交付 + 微服务 + 容器

而符合云原生架构的应用程序是：采用开源堆栈(K8S + Docker)进行容器化，基于微服务架构提供灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

DevOps: 指的就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。
微服务：指的是应用需要具备低耦合 + 高内聚
持续交付：指的是在不影响用户适用服务的前提下，频繁将新功能发布给用户使用，当然这一点也是云原生中比较难以达到的。
容器化：指的是在运维的时候，不需要再关心每个服务所使用的技术栈，每个服务都被无差别的封装再容器中，可以被无差别的管理和维护，比如目前的docker和k8s。

1.1.2.Apache pulsar基本介绍

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

Apache Pulsar的功能与特性:
1) 多租户模式
2) 灵活的消息系统
3) 云原生架构
4) segmented Sreams(分片流)
5) 支持跨地域复制

1.1.2.1.多租户模式

• 租户和命名空间（namespace）是 Pulsar 支持多租户的两个核心概念。
• 在租户级别，Pulsar 为特定的租户预留合适的存储空间、应用授权与认证机制。
• 在命名空间级别，Pulsar 有一系列的配置策略（policy），包括存储配额、流控、消息过期策略和命名空间之间的隔离策略。
  

1.1.2.2.灵活的消息系统

Pulsar 做了队列模型和流模型的统一，在 Topic 级别只需保存一份数据，同一份数据可多次消费。以流式、 队列等方式计算不同的订阅模型大大提升了灵活度。

同时pulsar通过事务采用Exactly-Once(精准一次)在进行消息传输过程中, 可以确保数据不丢不重。

1.1.2.3.云原生架构

Pulsar使用计算与存储分离的云原生架构，数据从Broker搬离，存在共享存储内部。上层是无状态Broker，复制消息分发和服务；下层是持久化的存储层Bookie集群。Pulsar存储是分片的，这种构架可以避免扩容时受限制，实现数据的独立扩展和快速恢复。

1.1.2.4.Segmented Streams(分片流)

Pulsar 将无界的数据看作是分片的流，分片分散存储在分层存储（tiered storage）、BookKeeper集群和 Broker 节点上，而对外提供一个统一的、无界数据的视图。其次，不需要用户显式迁移数据，减少存储成本并保持近似无限的存储。

1.1.2.5.支持跨地域复制

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

1.1.3.Apache pulsar组件介绍

1.1.3.1.层级存储

• Infifinite Stream: 以流的方式永久保存原始数据
• 分区的容量不再受限制
• 充分利⽤云存储或现有的廉价存储 ( 例如 HDFS)
• 数据统⼀表征：客户端无需关心数据究竟存储在哪⾥
  

1.1.3.2.Pulsar IO (Connector)连接器

• Pulsar IO 分为输入（Input）和输出（Output）两个模块，输入代表数据从哪里来，通过 Source 实现数据输入。输出代表数据要往哪里去，通过 Sink 实现数据输出。
• Pulsar 提出了 Connector （也称为 Pulsar IO），用于解决 Pulsar 与周边系统的集成问题，帮助用户高效完成工作。
• 目前pulsar IO 支持非常多的连接集成操作: 例如HDFS 、Spark、Flink 、Flume 、ES 、HBase等。
  

1.1.3.3.Pulsar Functions(轻量级计算框架)

• Pulsar Functions 是一个轻量级的计算框架，可以给用户提供一个部署简单、运维简单、API 简单的 FASS（Function as a service）平台。Pulsar Functions 提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。

• Pulsar Functions 的设计灵感来自于 Heron 这样的流处理引擎，Pulsar Functions 将会拓展 Pulsar 和整个消息领域的未来。使用 Pulsar Functions，用户可以轻松地部署和管理 function，通过 function 从 Pulsar topic 读取数据或者生产新数据到 Pulsar topic。
  

1.1.4.Pulsar与kafka的对比

1.1.4.1.Pulsar和Kafka的对比介绍说明

1）模型概念

• Kafka: producer – topic – consumer group – consumer
• Pulsar: producer – topic -subsciption- consumer

2)消息消费模式

• Kafka: 主要集中在流(Stream) 模式, 对单个partition是独占消费, 没有共享(Queue)的消费模式。
• Pulsar: 提供了统一的消息模型和API. 流(Stream) 模式 – 独占和故障切换订阅方式 ; 队列(Queue)模式 – 共享订阅的方式。

3）消息确认（ack）

• Kafka: 使用偏移量 offset。
• Pulsar: 使用专门的cursor管理. 累积确认和kafka效果一样; 提供单条或选择性确认。

4）消息保留

• Kafka: 根据设置的保留期来删除消息, 有可能消息没被消费, 过期后被删除, 不支持TTL
• Pulsar: 消息只有被所有订阅消费后才会删除, 不会丢失数据,. 也运行设置保留期, 保留被消费的数据 . 支持TTLApache Kafka和Apache Pulsar都有类似的消息概念。 客户端通过主题与消息系统进行交互。 每个主题都可以分为多个分区。 然而，Apache Pulsar和Apache Kafka之间的根本区别在于Apache Kafka是以分区为存储中心，而Apache Pulsar是以Segment为存储中心。

Apache Kafka和Apache Pulsar都有类似的消息概念。客户端通过主题与消息系统进行交互。 每个主题都可以分为多个分区。 然而，Apache Pulsar和Apache Kafka之间的根本区别在于Apache Kafka是以分区为存储中心，而Apache Pulsar是以Segment为存储中心。

对比总结：
Apache Pulsar将高性能的流（Apache Kafka所追求的）和灵活的传统队列（RabbitMQ所追求的）结合到一个统一的消息模型和API中。 Pulsar使用统一的API为用户提供一个支持流和队列的系统，且具有同样的高性能。

性能对比：
Pulsar 表现最出色的就是性能，Pulsar 的速度比 Kafka 快得多，美国德克萨斯州一家名为 GigaOm (https://gigaom.com/) 的技术研究和分析公司对 Kafka 和 Pulsar 的性能做了比较，并证实了这一点。


扩展说明：kafka目前存在的痛点

1. Kafka 很难进行扩展，因为 Kafka 把消息持久化在 broker 中，迁移主题分区时，需要把分区的数据完全复制到其他 broker 中，这个操作非常耗时。
2. 当需要通过更改分区大小以获得更多的存储空间时，会与消息索引产生冲突，打乱消息顺序。因此，如果用户需要保证消息的顺序，Kafka 就变得非常棘手了。
3. 如果分区副本不处于 ISR（同步）状态，那么 leader 选取可能会紊乱。一般地，当原始主分区出现故障时，应该有一个 ISR 副本被征用，但是这点并不能完全保证。若在设置中并未规定只有 ISR 副本可被选为 leader 时，选出一个处于非同步状态的副本做 leader，这比没有 broker 服务该 partition的情况更糟糕。
4. 使用 Kafka 时，你需要根据现有的情况并充分考虑未来的增量计划，规划 broker、主题、分区和副本的数量，才能避免 Kafka 扩展导致的问题。这是理想状况，实际情况很难规划，不可避免会出现扩展需求。
5. Kafka 集群的分区再均衡会影响相关生产者和消费者的性能。
6. 发生故障时，Kafka 主题无法保证消息的完整性（特别是遇到第 3 点中的情况，需要扩展时极有可能丢失消息）。
7. 使用 Kafka 需要和 offset 打交道，这点让人很头痛，因为 broker 并不维护 consumer 的消费状态。
8. 如果使用率很高，则必须尽快删除旧消息，否则就会出现磁盘空间不够用的问题。
9. 众所周知，Kafka 原生的跨地域复制机制（MirrorMaker）有问题，即使只在两个数据中心也无法正常使用跨地域复制。因此，甚至 Uber 都不得不创建另一套解决方案来解决这个问题，并将其称为 uReplicator (https://eng.uber.com/ureplicator/)。
10. 要想进行实时数据分析，就不得不选用第三方工具，如 Apache Storm、Apache Heron 或 Apache Spark。同时，你需要确保这些第三方工具足以支撑传入的流量。
11. Kafka 没有原生的多租户功能来实现租户的完全隔离，它是通过使用主题授权等安全功能来完成的。