关于apache:Kafka-已落伍转角遇见-Pulsar

3次阅读

共计 4950 个字符，预计需要花费 13 分钟才能阅读完成。

浏览本文须要约 10 分钟。

自 LinkedIn 2011 年创立了 Apache Kafka 后，这款音讯零碎一度成为大规模音讯零碎的惟一抉择。为什么呢？因为这些音讯零碎每天须要传递数百万条音讯，音讯规模的确很宏大（2018 年 Twitter 推文均匀每天 500 万条，用户数均匀每天为 1 亿）。那时，咱们没有 MOM 零碎来解决基于大量订阅的流数据能力。所以，很多大牌公司，像 LinkedIn、Yahoo、Twitter、Netflix 和 Uber，只能抉择 Kafka。

现在到了 2019 年，世界产生了巨变，每天的音讯增量高达数十亿，反对平台也须要相应扩大，以满足持续增长的须要。因而，音讯零碎须要在不影响客户的状况下继续地无缝扩大。Kafka 在扩大方面存在诸多问题，零碎也难以治理。Kafka 的粉丝对此说法可能颇有微词，然而这并非集体偏见，我自身也是 Kafka 的粉丝。主观的说，随着世界的倒退和翻新，新工具比旧工具更加不便易用，咱们天然会感觉原来的工具漏洞百出，很难应用。天然倒退，始终如此。

这时，一款新的产品应运而生——它就是“Apache Pulsar”！

2013 年雅虎创立了 Pulsar，并于 2016 年把 Pulsar 捐给了 Apache 基金会。Pulsar 现已成为 Apache 的顶级我的项目，取得举世瞩目的认可。雅虎和 Twitter 都在应用 Pulsar，雅虎每天发送 1000 亿条音讯，两百多万个主题。这样的音讯量，听起来很不堪设想吧，但的确是真的！

接下来咱们理解下 Kafka 痛点以及 Pulsar 对应的解决方案。

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/ureplica…)。

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

Kafka 没有原生的多租户性能来实现租户的齐全隔离，它是通过应用主题受权等平安性能来实现的。

当然，在生产环境中，架构师和工程师有方法解决上述问题；然而在平台 / 解决方案或站点可靠性上，这是个让人头疼的问题，这并不像在代码中修复逻辑，而后将打包的二进制文件部署到生产环境中那么简略。

当初，咱们来聊聊 Pulsar，这个竞争畛域中的领跑者。

Apache Pulsar 是一个开源分布式公布 - 订阅音讯零碎，最后由雅虎创立。如果你理解 Kafka，能够认为 Pulsar 在实质上和 Kafka 相似。

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

与 Kafka 相比，Pulsar 的速度晋升了 2.5 倍，提早升高了 40%。（起源：https://streaml.io/pdf/Gigaom…）。

请留神，该性能比拟是针对 1 个分区的 1 个主题，其中蕴含 100 字节音讯。而 Pulsar 每秒可发送 220,000+ 条音讯，如下所示。

这点 Pulsar 做的的确很棒！就冲这一点，放弃 Kafka 而转向 Pulsar 相对很值，接下来，我会具体分析 Pulsar 的劣势和特点。

Pulsar 既反对作为音讯队列以 Pub-Sub 模式应用，又反对按序拜访（相似 Kafka 基于 Offset 的浏览），这给用户提供了极大的灵活性。

针对数据长久化，Pulsar 的零碎架构和 Kafka 不同。Kafka 在本地 broker 中应用日志文件，而 Pulsar 把所有主题数据存储在 Apache BookKeeper 的专用数据层中。简略地说，BookKeeper 是一种高可扩大、强容灾和低延时的存储服务，并且针对实时长久的数据工作负载进行了优化。因而，BookKeeper 保障了数据的可用性。而 Kafka 日志文件驻留在各个 broker 以及灾难性服务器故障中，所以 Kafka 日志文件可能呈现问题，不能齐全确保数据的可用性。这个有保障的长久层（guaranteed persistence layer）给 Pulsar 带来了另一个劣势，即“broker 是无状态的”。这与 Kafka 有实质的区别。Pulsar 的劣势在于 broker 能够无缝地程度扩大以满足一直增长的需要，因为它在扩大时不须要挪动理论数据。

如果一个 Pulsar broker 宕机了怎么办？主题会被立刻重新分配给另一个 broker。因为 broker 的磁盘中没有主题数据，服务发现会自行处理 producer 和 consumer。

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，还须要配套应用像 Apache Storm 这样的流解决零碎，这会额定减少老本，保护起来也很麻烦。在这点上，Pulsar 就远远胜过 Kafka。截至目前，Pulsar Functions 反对 Java、Python 和 Go 语言，其余语言将在当前的版本中陆续失去反对。

Pulsar Functions 的用户案例包含基于内容的路由（content based routing）、聚合、音讯格式化、音讯荡涤等。

如下是字数计算示例。

package org.example.functions;
import org.apache.pulsar.functions.api.Context;
import org.apache.pulsar.functions.api.Function;
import java.util.Arrays;
public class WordCountFunction implements Function<String, Void> {
    // This is invoked every time messages published to the topic
    @Override
    public Void process(String input, Context context) 
        throws Exception {Arrays.asList(input.split(" ")).forEach(word -> {String counterKey = word.toLowerCase();
            context.incrCounter(counterKey, 1);
        });
        return null;
    }
}

Pulsar 反对多个数据接收器（data sink），用于为次要产品（如 Pulsar 主题自身、Cassandra、Kafka、AWS Kinesis、弹性搜寻、Redis、Mongo DB、Influx DB 等）路由解决过的音讯。

此外，还能够把解决过的音讯流长久化到磁盘文件。

Pulsar 应用 Pulsar SQL 查问历史音讯，应用 Presto 引擎高效查问 BookKeeper 中的数据。Presto 是用于大数据解决方案的高性能分布式 SQL 查问引擎，能够在单个查问中查问多个数据源的数据。如下是应用 Pulsar SQL 查问的示例。

show tables in pulsar."public/default"

Pulsar 内置弱小的跨地区复制机制，可在不同区域的不同集群之间即时同步音讯，以保护音讯的完整性。在 Pulsar 主题上生成音讯时，音讯首先保留在本地集群中，而后异步转发到近程集群。在 Pulsar 中，启用跨地区复制是基于租户的。只有创立的租户能够同时拜访两个集群时，这两个集群之间能力启用跨地区复制。

对于消息传递通道平安，Pulsar 原生反对基于 TLS 和基于 JWT token 的受权机制。因而，你能够指定谁能够公布或应用哪些主题的音讯。此外，为了进步安全性，Pulsar Encryption 容许应用程序在生产者端加密所有音讯，并在 Pulsar 传递加密音讯到消费者端时解密。Pulsar 应用应用程序配置的公钥 / 私钥对执行加密。具备无效密钥的消费者能力解密加密音讯。但这会带来性能损失，因为每条音讯都须要加密和解密能力进行解决。

目前在应用 Kafka 并且心愿迁徙到 Pulsar 的用户大可释怀，Pulsar 原生反对通过连接器（connector）间接应用 Kafka 数据，或者你能够把现有的 Kafka 应用程序数据导入到 Pulsar，这个过程也相当容易。

这篇文章并不是说大规模音讯解决平台不能应用 Kafka，只能抉择 Pulsar。我要强调的是，Kafka 的痛点 Pulsar 曾经有了很好的解决方案，这对任何工程师或架构师来说都是一件坏事。另外，在体系架构方面 Pulsar 在大型消息传递解决方案中的速度要快得多，随着雅虎和 Twitter（以及许多其余公司）把 Pulsar 部署到生产环境，阐明 Pulsar 稳定性足以撑持任何生产环境。尽管从 Kafka 转到 Pulsar，会经验一个小小的学习曲线，但相应的投资回报率还是很主观的！

如需获取 Pulsar 的企业服务和反对，欢送分割 StreamNative（info@streamnative.io）。

作者 : Anuradha Prasanna

翻译 : Zhanying

审校 : Jennifer + Sijie + Yjshen

编辑 : Irene

Apache Pulsar 是下一代云原生分布式流数据平台，它源于 Yahoo，2016 年 12 月开源，2018 年 9 月正式成为 Apache 顶级我的项目，逐步从繁多的音讯零碎演化成集音讯、存储和函数式轻量化计算的流数据平台。在 Apache Pulsar 疾速倒退的过程中，社区的搭档们也致力于硅谷以外的布道之旅，在中国社区开始了不平庸的历程。

点击链接，浏览英文原文。

正文完