关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。

GitHub 地址：http://github.com/apache/pulsar/

当新生事物出现时，人们总是有两种角度去观察它，要么把它看小，要么把它放大。

对于 Apache Pulsar 来说，把它看小的角度通常是“Apache Pulsar 只是一个新的消息队列而已“，或者“Apache Pulsar 只是一个新的数据管道而已”，又或者是“队列系统早就有了，只是 Apache Pulsar 更具扩展性也能解决某些场景问题而已，基本没啥本质区别”。

那么，事实果真如此吗？

带着这些问题，InfoQ 记者张浩在 QCon 2021 全球软件开发大会（https://qcon.infoq.cn/2021/beijing/）上采访了 StreamNative 联合创始人、Apache Pulsar 和 Apache BookKeeper PMC 成员翟佳，和他聊了聊 Apache Pulsar 的历史、特点以及未来的趋势。

点击链接，查看公众号视频采访的全部内容，为方便读者查看，视频下方也附上了文字内容。

InfoQ：翟老师，你好，欢迎来到 QCon 大会并接受我们的采访，请您先自我介绍一下吧。

翟佳：主持人好，我叫翟佳，来自 StreamNative，现在主要是做 Apache Pulsar、Apache BookKeeper 相关的设计和开发，也是这两个开源项目的项目管理委员会成员。更早之前，我还在 EMC 做过分布式文件系统的设计和开发。

InfoQ：我在 Pulsar 官网上看到它是这么定义的，它说 Pulsar 是一个云原生的分布式消息和流平台。在中文媒体的很多宣传里，对于 Pulsar 的定义怎么说的都有，我姑且就把它理解为是一个新一代的 Kafka。那么很多公司其实是把 Kafka 当成消息系统使用的，所以我想请你来聊一聊，这些年来开源消息系统都经历过怎样的迭代？

翟佳：你刚刚提到的消息系统确实是 Pulsar 诞生的一个初衷，因为在 2011 年、2012 年的时候，在雅虎内部需要解决的就是一个消息系统统一的问题。当时比较流行的 ActiveMQ、RabbitMQ 在雅虎内部也都有使用，所以 Pulsar 诞生的一个场景也是做内部的一个统一，要替换 ActiveMQ、RabbitMQ 这样的消息系统。也就是你刚才提到的 MQ 的场景需求。

你刚才也提到 Pulsar 是云原生的，这跟它当初诞生时雅虎的环境有关。雅虎当时是 Hadoop 生态的一个主要缔造者，它是先有的底层的存储层，也就是 BookKeeper 这样一个项目。我们之所以说它云原生也是因为 Pulsar 采用了一个存储和计算分离的这样一个架构，存储层就是我们刚刚提到到 BookKeeper，BookKeeper 它在雅虎内部主要是解决 Hadoop 生态，也就是 HDFS、NameNode 这样的一层 HA。你可以认为它是做元数据的存储，所以它有很高的一致性。刚好它又是一种 Log 的抽象，就是用 append-only 的模式，它跟我们提到的 MQ 的场景很类似，新的消息不断地追加，然后这个模式刚好可以应用在消息这个领域里面，所以它对云原生路线的选择跟它的技术背景有关系。就是先有了很优秀的、能够提供很好服务质量的存储系统，然后才有了 Pulsar 这样的存储和计算分离的架构。

有了这样的系统之后，它由于有存储和计算分离的架构，有 Write-Ahead-Log（WAL）存储层的抽象，它不仅可以支撑很多 MQ 的关键业务场景，不丢消息，对一致性要求很高，又可以提供比较高的带宽、比较低的延迟。所以这是很多用户把它用在原来 Kafka 的场景里面的原因。可能最开始的选择是 MQ 的方向，但是由于架构、由于本身存储层的特性，也会用到一些 Kafka 的场景里面，这是它跟 Kafka 的关系。

InfoQ：刚才你提到 Pulsar 是诞生于雅虎，你能更详细的介绍一下这个项目诞生的背景吗？这些年 Pulsar 发展得怎么样？

翟佳：Pulsar 的诞生我们刚刚提到过一点，开始做这个项目是在 2012 年，在当时，2011 年国内诞生了 RocketMQ，再往前一年，2010 年诞生了 Kafka，然后 Pulsar 在 2012 年诞生。

在 2012 年要选择云原生的存储计算分离的架构是一个很有挑战的事情。因为当时单个节点的网卡，单个节点的磁盘可能都不适合云原生这样的架构。所以在 2012 年之前，也就是 2010 年下半年到 2011 年，雅虎内部做了一个 Pulsar 的原型系统，它叫 HedWig。它主要是做这样的一个尝试：就是存储计算分离这样的架构能不能服务于消息这个场景。所以它诞生可能更早一些，先有 HedWig 这样一个原型系统，然后再立项 Pulsar。Pulsar 开源之前在雅虎内部的代号叫 CMS（Cloud Message Service），所以说它最开始诞生的初衷就是要做一个云的消息的服务。

有了前期原型系统的铺垫，决定了云原生这个路线之后，再往后 2013 年主要是做功能开发，2014 年开始在雅虎内部大规模部署，在雅虎内部经过线上产品的检验，又稳定运行了一两年以后，在 2016 年开源出来，2017 年捐给 Apache 软件基金会，2018 年从 Apache 软件基金会毕业成为顶级项目。

捐给 Apache 软件基金会之后，这个项目就开始了一个快速的发展期，很多国内外的互联网公司都开始使用 Pulsar，因为它确实解决了 MQ 场景里的问题，也解决了 Kafka 场景里面的一些问题。

特别是在 2019 年有了我们商业化的公司 StreamNative 的成立，用户对这个项目就更有信心了。包括腾讯最开始上线的一个很关键的业务场景，就是腾讯计费平台，也都是基于 Pulsar 来做所有计费的业务。还有国外的 Splunk 以及雅虎内部也有很多的场景都使用了 Pulsar，这样 Pulsar 的生态也随着我们国内外社区不断地成长，发展得越来越好了。

在 2018 年成为顶级项目之前，GitHub 的 Star 数增长虽然还好，但不是那么显著，在 2018 年底变成顶级项目之后，2019 年公司（StreamNative）成立，Star 数的增长就更加迅速了。我觉得国内的开源土壤对我们开源社区的构建，对我们开源项目初期的成长有很大的帮助。

InfoQ：我看到网上很多人对比 Kafka 和 Pulsar，包括刚才我们也做了一个对比，那你怎么去看待这两个技术呢？

翟佳：我们刚刚也提到，Pulsar 项目诞生的背景就是要解决雅虎内部的需求。它要有大集群、多租户的能力，能让雅虎内部各个业务部门的数据打通，所以它诞生的初衷不是为了去做 Kafka 的事情，大家都在同一个时代。

而且在 2012 年 Kafka 也没有像现在这么火，Pulsar 还是从自身的角度出发，就是要解决雅虎内部的问题，然后就有了这样的产品。之后它又选择了开源的路线，让产品变得更加稳定，能够借助社区给它添加更多的功能。所以说它最开始不是专门针对 Kafka 而设计的，但是诞生之初，它的设计为了解决自身的问题，会考虑到更丰富的应用场景，考虑自身业务的一些需求，所以说它确实也能够支撑 Kafka 所对应的一些业务需求。自然而然地，在开源之后，可能它解决了 Kafka 用户的一些痛点，被一些用户所选择，但这是一个自然而然的过程，并不是专门针对 Kafka 来做这个事。

InfoQ：郭斯杰之前说过，消息、流、存储将会逐步融合，你怎么理解这个观点呢？

翟佳：刚刚提到三个方向，消息、流和存储。我发现消息和流是很相关、模式也很类似的两个系统，你的消息也是需要一个载体来提供消息的存储和服务，消息进来的模式也是要按照时间、用户的数据等等固定的顺序，这样才能对外提供顺序性和一致性的保障。

流的场景也是一样，所有的数据源源不断地流入，然后按照时间顺序来做一个消费，所以从这个角度来看，它们两个是很贴近、概念很类似的一个场景。只不过在之前可能由于技术架构的原因，我们把消息和流分成了两种模型。在很多企业内部关键的业务场景里用各种 MQ 来保证消息的服务，在数据管道这种场景下用 Kafka 提供流的服务，但是本质上来说它们都是一样的，只是之前由于技术原因，把它们天然做了一个分隔。

Pulsar 的一个优势是它有很好的底层储存层 BookKeeper，它既可以保证很高的一致性，也可以通过 append-only Write-Ahead-Log（WAL）这种抽象来保证比较高的吞吐，它可以从技术上解决两个场景不同的需求，所以 Pulsar 从这个角度提供了很好的消息和流的融合。

在存储这个方向，之前大家可能把消息的存储这个事情看得有些太简单了，有很多用户认为我的消息要做系统解耦，在 MQ 的场景里面，可能有很多的消息都是从内存里直接就把消息消费完了，很少有需要把消息落地、存储的场景，所以当时的实现都很简单，包括 Kafka 在内，大家都是把消息直接落到文件系统里面，怎么简单怎么实现，这样对很多关键的业务场景，对很多需要数据堆积的场景来说，如果单单依靠一个文件系统来做，你的服务质量，你的稳定性可能就不太容易保障，因为文件系统不是专门为这个场景设计的，比如说你在 MQ 场景，我需要实时地刷盘，我需要保证这个数据持久性，它的备份数以及一致性要足够高，这个场景下它的性能可能就会降下来了，这也是我们说随着用户的应用数据场景不断丰富，随着你对消息系统的要求不断提高，它对底层消息系统的一些要求也会改变。所以现在来看，随着大数据的发展，随着用户数据量的提高，Pulsar 真正发挥了它的价值，它有一个专门为消息做的存储层，有了这样一个存储层，它可以跟我们刚刚提到的消息的服务、流的服务能够很好地结合起来。

所以说消息、流和存储在 Pulsar 这边是一个融合的方向，是一个融合的架构，这是我们从 Pulsar 这个角度来看这三个方向时一个很直观的感受。

InfoQ：Pulsar 之所以敢说它是新一代的消息系统，那它肯定是顺应了一些趋势，除了前面的消息、流、存储的趋势外，你们还看到了什么样的趋势？

翟佳：我们觉得这个趋势可能就是我们在第一个问题中提到的，它和云原生比较相关。因为云原生是一个很大的趋势。刚刚我们也提到过，Pulsar 选的这套架构，当时也是一个很超前的架构，在 2012 年它就选择了存储计算分离这样的架构，它具备云原生这个优势，同时再结合 Pulsar 本身每一层节点都是一个对等的架构，这样会对线上运维有很大的帮助。包括我们说在你的服务层，你所有的 Broker 都是一个对等的架构。然后你的存储层 BookKeeper 也是一个对等的架构。这样你扩缩容的时候，你的大集群不用维护每个节点 master/slave 的状态。它的维护更加简单。同时我们在云上有一个很重要的初衷，就是我要做一个弹性的资源调度，从这个角度来说 Pulsar 也是刚好顺应这个趋势，跟它诞生的代号 CMS（Cloud Message Service）是一脉相承的关系，就是要做一个消息的云，要把云上的各种资源能够很容易地调度起来，能够为消息系统做一个服务。所以我觉得云原生是 Pulsar 很大的一个优势，也是我们顺应的一个大趋势。

InfoQ：好的，谢谢翟老师。

翟佳：感谢主持人。

相关阅读

• QCon 北京 2021：Pulsar PMC 成员翟佳出席并演讲
  

• StreamNative CEO 郭斯杰带你深度解析“消息、流、存储”三位一体融合趋势
  

点击链接，获取 Apache Pulsar 硬核干货资料！