Pulsar与Rocketmq、Kafka、Inlong-TubeMQ，谁才是消息中间件的王者？

导语 | Pulsar作为下一代消息中间件的典型代表，在设计和实现上面都具备很好的前瞻性，综合考量了业界现存的一些比较常用的、优秀的消息中间的架构设计、适用场景、运营中的问题等，如目前用的比较多的Kafka、Rocketmq、Inlong-TubeMQ等。本文仅从设计角度出发，说明下Pulsar与Kafka、Rocketmq及腾讯开源的Inlong-TubeMQ在实现上的几点区别和可能遇到的问题，供大家参考。

一、云原生多租户设计

（一）分级命名

Pulsar原生支持多租户设计，非常适合作为云产品进行管理。Pulsar的topic名称如下图所示：

persistent://tenant/namespaces/topic

分为四个部分：

• 第一部分：Domain，表示存储方式，分为nonpersistent和persistent，对应非持久化和持久化存储；

• 第二部分：tenant，表示租户名称，公司或团队内部使用时，也可以作为部门名称、业务分类等；

• 第三部分：namespace，表示命名空间，作为租户内部的一个层级划分；

• 第四部分：topic名称，具体的topic。Pulsar支持分区和非分区topic。但是，在业务侧视角，很难看出是否是分区topic，需要查看元数据或者日志信息。

Kafka/Rocketmq/Inlong-TubeMQ，从设计上和管理的角度看，对上云并不是特别友好。Topic管理上完全是平级的，如果需要区分不同的用户、不同的部门的topic，需要在运营层面做一定的设计支持。

（二）多级流控

Pulsar支持Broker级别、Namespace级别、Topic级别的流控，包括生产、消费的出入流控，客户端的连接数，存储配额等。

Kafka/Rocketmq/Inlong-TubeMQ的流控措施和策略相对来说要少很多，具体可以参考相关资料。

二、计算与存储

（一）Broker状态

Pulsar的broker是无状态的，这和它的计算、存储分离的架构设计有关，broker端不需要保存任何的元数据和消息信息。可以根据系统的需求，进行动态的扩/缩容处理。

Rocketmq broker具备主备的概念，且broker侧本地需要存储消息。单个broker使用一个逻辑的commitlog文件，以wal的方式写入消息。（目前，高版本已经引入自动主备选主能力和Dledger进行计算与存储分离处理，有需要的也可以关注下），所以默认方式下，算是一个有状态的broker。

另外，Rocketmq的备，仅在主挂掉或者主负载过高的时候才会提供读取服务，算是冷备份。这在目前逐步强调机器利用率的环境下，算是一个待优化的设计点。

Kafka中也有主、备的概念区分，但是主备是partition维度的。Kafka broker端也需要存储消息，它的每个分区会使用wal方式存储消息，相对Rocketmq而言会多用很多写FD（即会同时对应到多个以wal方式写入的文件句柄），这块也是Kafka在broker端分区总数过多的时候，性能下降的一个原因。

Inlong-TubeMQ中broker没有主备的概念，消息仅会存储在broker本地一份，从存储角度看Inlong-TubeMQ中的broker算是个有状态的。由于消息只会被存储一份，Inlong-TubeMQ的使用场景会受到一定的限制。但是，Tubemq broker也因此具备很高的处理性能，比较适合容忍少量丢失和需要高性能的应用场景，目前公司内部在大数据场景，有大规模的应用。

（二）集群扩展能力

Puslar的服务器端，分为broker和bookie两个部署，broker负责接入、计算、拉取、分发消息等，bookie负责消息存储存储。broker、bookie均可以按需动态的