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目前存在的痛点
- 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 没有原生的多租户功能来实现租户的完全隔离,它是通过使用主题授权等安全功能来完成的。