阅读本文需要约 10 分钟。
Apache Kafka 是一个存在已久的大规模分布式消息收发系统，它在 2011 年由 LinkedIn创建，在当时是大多数对性能要求严格的大规模消息传递需求的唯一选择。每天需传递数百万条消息，这样的消息收发规模确实很庞大（2018 年 Twitter 推文平均每天 500 万条，用户数平均每天为 1 亿）。那时，我们没有这样的 MOM 系统来处理大型用户群的分组功能。因此，当时 Kafka 是大多数大牌公司 LinkedIn、Yahoo、Twitter、Netflix 和 Uber 的仅有选择。
2019年情况发生了巨变，每日消息增量高达数十亿，因此需要相应扩展平台支持，以满足持续增长的需求。为了做到这一点，消息传递系统需要在不影响客户的情况下持续无缝地扩展。
Kafka 在扩展方面存在很多问题，并且它的系统也较难管理。 喜欢 Kafka 的人可能会对这种说法颇有微词，这并非出于主观臆断，我本身也是 Kafka 的粉丝，但客观的说，随着世界范围内新工具的不断创新，它们与旧工具相比显而易见的是，人们往往还是觉得新工具似乎更加便捷，而旧工具更难以管理和处理。这是问题的本质。
一款新的产品应运而生 —— 它就是 “Apache Pulsar” ！
雅虎于 2013 年创建了 Pulsar ，并于 2016 年把 Pulsar 捐给了 Apache 基金会。Pulsar 现已成为 Apache 的顶级项目，并且取得较大成功。 现在雅虎和 Twitter 都是 Pulsar 的用户，雅虎每天发送 1000 亿条消息，其中主题消息超过了 2 亿条 —— 消息数之大，让人难以置信。
接下来我们了解下 Kafka 现存的问题以及 Pulsar 的解决方案。
Kafka 要进行扩展是很困难的，这是因为 Kafka 将数据存储在 broker 中的方式是消息传递持久性存储的分布式日志的方式。脱离另一个 broker 意味着它必须完全复制主题分区和副本，所以完成 broker 脱离需要额外的时间。
更改分区大小以获得更多的存储空间可能会因与消息索引冲突而破坏消息顺序。如果消息顺序是主要问题，那么这一点至关重要。
如果分区副本不处于 ISR（同步）状态，那么 leader 选取可能会紊乱。基本上，当原始主分区失败时，至少应该有一个 ISR 副本被选为租用，但是这点并不能完全保证。有一个设置可以禁用此功能，但如果启用了此功能，则非 ISR 副本将被选为 leader，这比没有 leader 分区的服务中断更糟糕，因为这会导致更糟糕的情况。
理想情况下，你必须首先规划和计算 broker、主题、分区和复制副本的数量（这符合计划中的未来使用增长），以避免出现扩展问题，但现在，面对不可预测的流量需求和高峰，很难再进行规划。
Kafka 集群的再平衡可能会影响关联的生产者和消费者的性能。
Kafka 主题可能会在失败的情况下丢失消息（特别是在第 3 点）。
使用 offsets 会比较痛苦，因为 Kafka 是愚蠢的（“愚蠢”的用词来自于体系结构概念“愚蠢 broker 和智能客户”）。
如果使用率很高，则必须尽快删除旧消息以避免磁盘空间问题。
Kafka 的本地跨区域地理复制机制（MirrorMaker）问题是一个大家比较熟知的问题，即使是在两个数据中心内这个问题也依然存在。因此，甚至 Uber 也创建了另一个解决方案来解决这个问题，并将其称为 uReplicator 作为问题案例。
如果需要，你必须使用另一个实时事件分析器工具，如 Apache Storm、Apache Heron 或 Apache Spark，这也应该有助于支持传入流量速率。
Kafka 没有完全隔离租户的原生多租户功能，而是通过使用主题授权等安全功能来完成的。
当然，在生产环境中，架构师和工程师有办法解决上述问题；但是在平台/解决方案或站点可靠性上，这是个让人头疼的问题，这并不像在代码逻辑中修复逻辑，然后将打包的二进制文件部署到生产环境中那么简单。
现在，我们来聊聊 Pulsar，这个竞争领域中的领跑者。
什么是 Apache Pulsar？
Apache Pulsar 是一个开源分布式 pub-sub 消息系统，最初由雅虎创建。 如果你了解 Kafka，Pulsar 在本质上和 Kafka 很像。
Pulsar 性能
Pulsar 表现最出色的就是性能，Pulsar 的速度比 Kafka 快得多，德克萨斯州一家名为 Gigaom 的技术研究和分析公司进行的性能比较很好地证明了这一点。
与 Kafka 相比，Pulsar 的速度大约提高了 2.5 倍，延迟时间缩短了40％。 是不是很棒？ 当然。
（来源请点击https://streaml.io/pdf/Gigaom-Benchmarking-Streaming-Platforms.pdf）
请注意，此性能比较是针对 1 个分区的 1 个主题，其中包含 100 字节消息，其中 Pulsar 每秒可发送 220,000+ 条消息，如下所示。
这点 Pulsar 做的确实很棒！
就冲这一点，放弃 Kafka 而转向 Pulsar 绝对不亏，接下来我继续介绍的内容也进一步佐证了这个观点。
Apache Pulsar 的优势和特点
Pulsar 既可以像 Kafka 那样按照基于 offset 的单分区只被一个consumer顺序消费的方式工作，也可以按照传统消息队列的单分区被多个consumer并发消费的方式工作。这是 Pulsar 的一大优势。
Pulsar 具有不同的数据持久性体系结构。Pulsar 没有像 Kafka 那样在本地 broker 中使用日志文件，而是将所有主题数据存储在由 Apache BookKeeper 提供支持的专用数据层中作为数据分类账。简单地说 BookKeeper 是一种扩展性强、容错和低延迟的存储服务，并且针对实时持久的数据工作负载进行了优化。因此，BookKeeper 保证了数据的可用性，这与 Kafka 日志文件可能出现的问题不同，Kafka 日志文件驻留在各个 broker 以及灾难性服务器故障中。由于这个有保证的持久层，Pulsar 带来了另一个优势，即“ Broker 程序是无状态的”。这与 Kafka 相比有很大的不同。现在真正的优势是，Pulsar broker 可以无缝地横向扩展以满足不断增长的需求，因为它没有主题分区数据加载或同步，就像 Kafka 在拆分新 broker 时所做的那样。
如果一个 Pulsar broker 失效了怎么办？主题将立即重新分配给另一个 broker，这是可能的，因为 broker 的磁盘中没有主题数据，服务发现将处理发布者/消费者。
Kafka 需要清除旧数据才能使用磁盘空间； 与 Kafka 不同，Pulsar 将主题数据存储在一个分层结构中，你可以在该结构中连接其他磁盘或 Amazon S3，以无限制地扩展和卸载主题数据存储。更酷的是，Pulsar 向消费者无缝地显示数据，就好像它们来自一个驱动器。另一个有价值的用例是，由于不需要清除旧数据，所以你可以将这些有组织的 Pulsar 主题用作“数据湖（Data Lake）”。当然，如果需要，也可以设置 Pulsar 来清除旧数据。
Pulsar 原生支持在主题命名空间级别使用数据隔离的多租户，而在 Kafka 中，这样的隔离是不可能的。除此之外，为了使 Pulsar 应用程序更加可靠和安全，Pulsar 还支持细粒度访问控制功能。
Pulsar 具有多个客户端库，可用于 Java、Go、Python、C++ 和 WebSocket 语言。
Pulsar 本身支持功能即服务（FaaS），这是一个非常酷的功能，类似于 Amazon Lambda，可以实时分析，聚合或汇总实时数据流。 与 Kafka 相比，这是一个很大的优势，因为在 Kafka 中还需要一个流处理系统，比如 Apache Storm，这就增添了额外的成本并且维护起来也很麻烦。 截至目前，Pulsar Functions 支持 Java 和 Python 语言，其他语言将在以后的版本中陆续得到支持。
（注： 除 Java 和 Python 语言，Pulsar Functions 目前还支持 Go 语言。）
Pulsar Functions 的用户案例包括基于内容的路由、聚合、消息格式化、消息清洗等。
下面是一个字数计算的示例。
Pulsar 支持多个数据接收器，用于为主要产品（如 Pulsar 主题本身，Cassandra，Kafka，AWS Kinesis，弹性搜索，Redis，Mongo DB，Influx DB 等）路由处理过的消息。
此外，还可以将处理过的消息流持久化到磁盘文件。Pulsar 支持使用 Pulsar SQL 以 SQL 风格方式查询过去的消息，这可以通过使用 Presto 引擎高效地查询 BookKeeper 数据。 Presto 是一种用于大数据解决方案的高性能分布式 SQL 查询引擎，允许在单个查询中查询来自多个数据源的数据。 下面是使用 Pulsar SQL 查询的示例，
Pulsar 另一个非常重要的功能是内置强大的跨地域复制机制，可在不同区域的不同集群之间即时同步消息，以维护消息的完整性。 在 Pulsar 主题上生成消息时，它们首先保留在本地集群中，然后异步转发到远程集群。 在 Pulsar 中，启用跨地域复制是基于每个租户的。 只有在创建允许访问两个集群的租户时，才能在集群之间启用跨地域复制。
对于消息传递通道安全，Pulsar 支持基于 TLS 和基于 JWT token的授权机制。 因此，你可以指定谁可以发布或使用哪些主题的消息。 此外，为了提高安全性，Pulsar Encryption 允许应用程序在生产端加密所有消息，并在 Pulsar 传递加密消息到消费端时解密。Pulsar 使用应用程序配置的公钥/私钥对执行加密。 具有有效密钥的消费者才能解密加密消息。 但这会带来性能损失，因为每条消息都需要加密和解密才能进行处理。
目前在使用 Kafka 并且希望迁移到 Pulsar 的用户大可放心，这是因为 Pulsar 本身支持通过连接器直接使用 Kafka 数据，或者你可以很容易地将现有的 Kafka 应用程序数据导入到 Pulsar。
如需获取 Pulsar 的企业服务和支持，欢迎联系 StreamNative ([email protected]）。
总结
并不是说大规模信息处理平台使用 Kafka 不好，唯一的选择就是 Pulsar。我要强调的是，Kafka 中存在的一些痛点 Pulsar 已经为我们解决了，这对任何工程师或架构师来说都是一件好事。另外，随着雅虎和 Twitter（以及许多其他公司）已经在使用生产环境消息加载，在体系架构方面 Pulsar 在大型消息传递解决方案中的速度要快得多，这证明了其稳定性和生产已经为任何业务做好了准备。虽然从 Kafka 切换到 Pulsar，会经历一个小小的学习曲线， 但相应的投资回报率还是很客观的！
作者：Anuradha Prasanna
翻译：Zhanying
审校: Jennifer
编辑：Irene