本文转载自 Java 高级架构，原中文版本由闻数起舞翻译自 Lewis Fairweather 的文章《Pulsar Advantages Over Kafka》，文章转载时有改变。Apache Pulsar 欢送大家踊跃踊跃投稿、与社区共同进步，也欢送大家与作者进行交换！
排版：Tango@StreamNative

对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

Photo by Mikael Kristenson on Unsplash

介绍

最近，我始终在钻研 Pulsar 及其与 Kafka 的比拟。通过疾速搜寻，你会看到这两个最驰名的开源消息传递零碎之间正在进行的 ” 和平 ”。

作为 Kafka 的用户，我着实对 Kafka 的某些问题感到困惑，但 Pulsar 却让人眼前一亮、令我十分兴奋。所以最初，我设法花了一些工夫理解背景材料，并且做了很多钻研。在本文中，我将重点介绍 Pulsar 的劣势，并阐明 Pulsar 胜于 Kafka 的理由。让咱们开始！

Kafka 基础知识

Kafka 是消息传递零碎之王。它由 LinkedIn 于 2011 年创立，并在 Confluent 的反对下失去了宽泛的流传。Confluent 已向开源社区公布了许多新性能和附加组件，例如用于模式演变的 Schema Registry，用于从其余数据源轻松流式传输的 Kafka Connect 等。数据库到 Kafka，Kafka Streams 进行分布式流解决，最近应用 KSQL 对 Kafka topic 执行相似 SQL 的查问等等。

Kafka 疾速，易于装置，十分受欢迎，可用于宽泛的范畴或用例。从开发人员的角度来看，只管 Apache Kafka 始终很敌对，但在操作运维方面却是一团糟。因而，让咱们回顾一下 Kafka 的一些痛点。

Kafka 演示

Kafka 的诸多痛点

• 扩大 Kafka 非常辣手，这是因为 broker 与存储数据的耦合架构构造所致。剥离一个 broker 意味着它必须复制 topic 分区和正本，这十分耗时；
• 没有与租户齐全隔离的本地多租户；
• 存储会变得十分低廉，只管能够长时间存储数据，然而因为老本问题却很少用到它；
• 万一正本不同步，有可能失落音讯；
• 必须提前打算和计算 broker、topic、分区和正本的数量（确保打算的将来使用量增长），以防止扩大问题，这十分艰难；
• 如果仅须要消息传递零碎，则应用偏移量可能会很简单；
• 集群从新均衡会影响相连的生产者和消费者的性能；
• MirrorMaker Geo 复制机制存在问题。像 Uber 这样的公司曾经创立了本人的解决方案来克服这些问题。

如您所见，大多数问题与操作运维方面无关。只管装置起来绝对容易，但 Kafka 难以治理和调优。而且，它也不足应有的灵便和弹性。

Pulsar 基础知识

Pulsar 由 Yahoo！在 2013 年创立，并于 2016 年捐献给 Apache 基金会。Pulsar 当初是 Apache 软件基金会的顶级我的项目。Yahoo！、Verizon、Twitter 等公司已在生产中应用它来解决成千上万音讯。它具备运行成本低、灵便等个性。Pulsar 旨在解决 Kafka 的大部分难题，使其更易于扩大。

Pulsar 非常灵活：它既能够利用于像 Kafka 这样的分布式日志利用场景，也能够利用于像 RabbitMQ 这样的纯消息传递零碎场景。它反对多种类型的订阅、多种交付保障、保留策略以及解决模式演变的办法，以及其余诸多个性。

Pulsar 架构图

Pulsar 的个性

• 内置多租户，不同的团队能够应用雷同的集群并将其隔离，解决了许多治理难题。它反对隔离、身份验证、受权和配额；
• 多层体系结构：Pulsar 将所有 topic 数据存储在由 Apache BookKeeper 反对的业余数据层中。存储和消息传递的拆散解决了扩大、从新均衡和保护集群的许多问题。它还进步了可靠性，简直不可能失落数据。另外，在读取数据时能够直连 BookKeeper，且不影响实时摄取。例如，能够应用 Presto 对 topic 执行 SQL 查问，相似于 KSQL，但不会影响实时数据处理；
• 虚构 topic：因为采纳 n 层体系结构，因而对 topic 的数量没有限度，topic 及其存储是拆散的。用户还能够创立非持久性 topic；
• N 层存储：Kafka 的一个问题是，存储费用可能变高。因而，它很少用于存储 ” 冷 ” 数据，并且音讯常常被删除，Apache Pulsar 能够借助分层存储主动将旧数据卸载到 Amazon S3 或其余数据存储系统，并且依然向客户端展现通明视图；Pulsar 客户端能够从工夫开始节点读取，就像所有音讯都存在于日志中一样；
• Pulsar Function：易于部署、轻量级计算过程、对开发人员敌对的 API，无需运行本人的流解决引擎（如 Kafka）；
• 安全性：它具备内置的代理、多租户安全性、可插拔的身份验证等个性；
• 疾速从新均衡：分区被分为易于从新均衡的分片；
• 服务器端反复数据删除和有效字段：无需在客户端中执行此操作，也能够在压缩期间删除反复数据；
• 内置 Schema registry（架构注册表）：反对多种策略，易于操作；
• 天文复制和内置 Discovery：易于将集群复制到多个区域；
• 集成的负载均衡器和 Prometheus 指标；
• 多重集成：Kafka、RabbitMQ 等；
• 反对多种编程语言，例如 GoLang、Java、Scala、Node、Python……
• 分片和数据分区在服务器端通明进行，客户端不须要理解分片与分区数据。

Pulsar 个性列表:

Pulsar 入门

Pulsar 入门非常容易。应用前提是装置 JDK。

1. 下载 Pulsar 并解压缩（备注：目前 Apache Pulsar 最新版本为 2.7.0）：

`
$ wget https://archive.apache.org/di…`

2. 下载连接器（可选）：
`
$ wget https://archive.apache.org/di…{connector}-2.6.1.nar`

3. 下载 nar 文件后，将文件复制到 Pulsar 目录中的 Connectors 目录

4. 启动 Pulsar！
`
$ bin/pulsar standalone`

Pulsar 提供了一个称为 Pulsar-Client 的 CLI 工具，咱们能够应用它与集群进行交互。

生产音讯：
`
$ bin/pulsar-client produce my-topic –messages “hello-pulsar”`

生产音讯：
`
$ bin/pulsar-client consume my-topic -s “first-subscription”`

Akka 流示例

举一个客户端示例，咱们在 Akka 上应用 Pulsar4s。

首先，咱们须要创立一个 Source 来生产数据流，所须要的只是一个函数，该函数将按需创立消费者并查找音讯 ID：

val topic = Topic("persistent://standalone/mytopic")

val consumerFn = () => client.consumer(ConsumerConfig(topic, subscription)) 

而后，咱们传递 ConsumerFn 函数来创立源：

import com.sksamuel.pulsar4s.akka.streams._

val pulsarSource = source(consumerFn, Some(MessageId.earliest)) 

Akka 源的物化值是 Control 的一个实例，该对象提供了一种 ” 敞开 ” 办法，可用于进行生产音讯。当初，咱们能够像平常一样应用 Akka Streams 解决数据。

要创立一个接收器：

val topic = Topic("persistent://standalone/mytopic")

val producerFn = () => client.producer(ProducerConfig(topic))

import com.sksamuel.pulsar4s.akka.streams._

val pulsarSink = sink(producerFn)

残缺示例摘自 Pulsar4s。

object Example {import com.sksamuel.pulsar4s.{ConsumerConfig, MessageId, ProducerConfig, PulsarClient, Subscription, Topic}
  import org.apache.pulsar.client.api.Schema

  implicit val system: ActorSystem = ActorSystem()
  implicit val materializer: ActorMaterializer = ActorMaterializer()
  implicit val schema: Schema[Array[Byte]] = Schema.BYTES

  val client = PulsarClient("pulsar://localhost:6650")

  val intopic = Topic("persistent://sample/standalone/ns1/in")
  val outtopic = Topic("persistent://sample/standalone/ns1/out")

  val consumerFn = () => client.consumer(ConsumerConfig(topics = Seq(intopic), subscriptionName = Subscription("mysub")))
  val producerFn = () => client.producer(ProducerConfig(outtopic))

  val control = source(consumerFn, Some(MessageId.earliest))
    .map {consumerMessage => ProducerMessage(consumerMessage.data) }
    .to(sink(producerFn)).run()

  Thread.sleep(10000)
  control.stop()}

Pulsar Function 示例

Pulsar Function 解决来自一个或多个 topic 的音讯，对其进行转换并将后果输入到另一个 topic：

Pulsar Function

能够在两个接口之间进行抉择以编写函数：

• 语言原生接口：不须要特定的 Pulsar 库或非凡的依赖项；无法访问上下文，仅反对 Java 和 Python；
• Pulsar Function SDK：可用于 Java / Python / Go，并提供更多功能，比方拜访上下文对象。

只需编写一个简略的函数即可应用语言原生接口转换音讯：

def process(input):

return "{}!".format(input)

用 Python 编写的这个简略函数只是向所有传入的字符串增加一个感叹号，并将后果字符串公布到 topic。

应用 SDK 须要导入依赖项，例如在 Go 中，咱们能够编写：

package main

import (

"context"

"fmt"

"github.com/apache/pulsar/pulsar-function-go/pf"

)



func HandleRequest(ctx context.Context, in []byte) error {fmt.Println(string(in) + "!")

return nil

}



func main() {pf.Start(HandleRequest)

}

如果要公布无服务器性能并将其部署到集群，能够应用 Pulsar-Admin CL；如果应用 Python，咱们能够编写：

$ bin/pulsar-admin functions create \

--py ~/router.py \

--classname router.RoutingFunction \

--tenant public \

--namespace default \

--name route-fruit-veg \

--inputs persistent://public/default/basket-items

Pulsar Function 的一个重要性能是用户能够在公布该函数时设置交付保障：$ bin/pulsar-admin functions create \

--name my-effectively-once-function \

--processing-guarantees EFFECTIVELY_ONCE

有以下抉择：

Pulsar 的劣势

与 Kafka 相比，让咱们回顾下 Pulsar 的次要劣势：

• 更多功能：Pulsar Function、多租户、Schema registry、n 层存储、多种生产模式和持久性模式等；
• 更大的灵活性：3 种订阅类型（独占，共享和故障转移），用户能够在一个订阅上治理多个 topic；
• 持久性选项：非长久（疾速）、长久、压缩（每个音讯仅最初一个键），用户能够抉择交付保障。Pulsar 具备服务器端反复数据删除和有效字样多保留政策和 TTL 的个性；
• 无需提前定义扩大需要；
• 反对队列与流两种音讯生产模型，所以 Pulsar 既能够代替 RabbitMQ 也能够代替 Kafka；
• 存储与 broker 拆散，因而扩展性更好，从新均衡更快、更牢靠；
• 易于操作运维：架构解耦和 n 层存储；
• 与 Presto 的 SQL 集成，可间接查问存储而不会影响 broker；
• 借助 n 层主动存储选项，能够更低成本地存储；
• 更快：基准测试在各种状况下都体现出更好的性能。Pulsar 具备较低的提早和更好的扩大性能。
• Pulsar Function 反对无服务器计算，无需部署治理；
• 集成 Schema registry；
• 集成的负载平衡器和 Prometheus 指标；
• 天文复制成果更好，更易于设置。Pulsar 内置 Discover-ability；
• 创立 topic 数量没有限度；
• 与 Kafka 兼容，易于集成。

Pulsar 的劣势

Pulsar 并不完满，Pulsar 也存在一些问题：

• 绝对不足反对、文档和案例；
• n 层体系结构导致须要更多组件：BookKeeper；
• 插件和客户端绝对 Kafka 较少。
• 云中的反对较少，Confluent 具备托管云产品。

不过，下面的状况都在失去疾速改善，目前 Pulsar 也逐步被越来越多的公司和组织应用，Apache Pulsar 商业反对公司 StreamNative 也推出了 StreamNative Cloud，Apache Pulsar 正在疾速成长，咱们都能够看到令人欣慰的变动。Confluent 曾公布博客比照 Pulsar 和 Kafka， 但请留神，这些问题可能有偏见 。

Pulsar 应用场景

Pulsar 可用于宽泛的场景：

• 公布 / 订阅队列消息传递；
• 分布式日志；
• 事件溯源，用于永久性事件存储；
• 微服务；
• SQL 剖析；
• Serverless 性能。

什么时候应该思考 Pulsar

• 同时须要像 RabbitMQ 这样的队列和 Kafka 这样的流处理程序；
• 须要易用的天文复制；
• 实现多租户，并确保每个团队的拜访权限；
• 须要长时间保留音讯，并且不想将其卸载到另一个存储中；
• 须要高性能，基准测试表明 Pulsar 提供了更低的提早和更高的吞吐量；

如果在云端，请留神思考基于云的解决方案。云提供商领有涵盖某些场景的不同服务。例如，对于队列音讯，云提供商提供了许多服务，比方 Google pub / sub；对于分布式日志，有 Confluent 云或 AWS Kinesis；StreamNative 也提供了基于 Pulsar 的云端服务。云提供商还提供了十分好的安全性。Pulsar 的劣势在于能够在一个平台上提供许多性能。一些团队可能将其用作微服务的消息传递零碎，而另一些团队则将其用作数据处理的分布式日志。

论断

我是 Kafka 的忠诚粉丝，我对 Pulsar 如此感兴趣的起因是：竞争驱动翻新。

Kafka 是一种成熟，富裕弹性且通过考验的产品，在世界范畴内取得了巨大成功，无奈设想大多数公司没有它会怎么。然而我的确看到 Kafka 成为其本身胜利的受害者，因为须要反对许多大型公司导致微小的增长减慢了性能开发的速度、移除 ZooKeeper 依赖项等重要性能破费的工夫太长，这为诸如 Pulsar 等工具蓬勃发展发明了空间。

Pulsar 尽管年老却势头很猛，在将 Pulsar 纳入组织之前，需进行剖析、基准测试、钻研并进行 POC。从小处着手，在将 Kafka 迁徙到 Pulsar 之前进行概念验证，并在决定进行齐全迁徙之前评估影响。

相干浏览

· 译文|Apache Pulsar 性能调优之架构

· Pulsar 读写过程的性能调优

· 为什么说 Pulsar 是云原生的音讯平台？

Pulsar 2020 用户考察流动行将截止，没有填写的小伙伴不要错失为 Pulsar 提倡议的良机???? 赶快扫描下方二维码填写，有机会取得新版 Pulsar 社区周边哦！