Kafka 已落伍，转角遇见 Pulsar！

自 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 。

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

Kafka 没有原生的多租户功能来实现租户的完全隔离，它是通过使用主题授权等安全功能来完成的。

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

现在，我们来聊聊 Pulsar，这个竞争领域中的领跑者。

什么是 Apache Pulsar？

Apache Pulsar 是一个开源分布式发布-订阅消息系统，最初由雅虎创建。如果你了解 Kafka，可以认为 Pulsar 在本质上和 Kafka 类似。

Pulsar 性能

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

与 Kafka 相比，Pulsar 的速度提升了 2.5 倍，延迟降低了 40％。（来源在这里）。

请注意，该性能比较是针对 1 个分区的 1 个主题，其中包含 100 字节消息。而 Pulsar 每秒可发送 220,000+ 条消息，如下所示。

这点 Pulsar 做的确实很棒！

就冲这一点，放弃 Kafka 而转向 Pulsar 绝对很值，接下来，我会详细剖析 Pulsar 的优势和特点。

Apache 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，会经历一个小小的学习曲线，但相应的投资回报率还是很客观的！

— THE END —