强无敌！Apache 开源超级卓越项目Pulsar

假设有一个企业，之前从未使用过消息系统，现在需要通过一个简单的消息系统，将消息从位置 A 发送到位置 B，但不需要复制消息。

数据架构师团队在深入研究 Pulsar 和 Kafka 的业务案例后，得出如下结论：在这一使用场景中，Pulsar 和 Kafka 都没有绝对优势。并且，他们认为在短时间内，该使用场景基本不会发生改变。

对于类似这样的简单消息使用场景而言，我也赞同 Pulsar 和 Kafka 都没有绝对优势。仅从技术角度出发，Pulsar 和 Kafka 这一回合打成平局，那么我们只能考虑成本。二者的运营成本、员工培训成本分别是多少？我打算根据 Kafka 或 Pulsar 的服务提供商的收费标准进行对比。 对比开销时，选好服务提供商也可以在一定程度上减少运营成本和员工培训成本 。Kafka 的云服务提供商，我参考了使用  Kafka API（Azure）  [1] 的  Confluent Cloud [2] 、 MSK（AWS） [3] 和  Event Hubs [4] 。Pulsar 的云服务提供商，我选择  StreamNative Cloud [5] 。

出于稳妥考虑，我们决定选择 Kafka API。目前，已有多种技术支持非 Kafka broker 使用 Kafka API 或传输协议。使用 Kafka API，非 Kafka broker 可通过添加新库支持 Kafka 的传输协议，保证对 Kafka API 的兼容性，从而最大化技术选择的多样性。例如，可以通过修改 Kafka API 的实现重新编译或通过 Pulsar broker 解析 Kafka 的协议（KOP），将 Pulsar 用作 Kafka 的后端。

我们在对比单位成本后，选择了 成本效益高 的一方。Kafka API 可以保证后端质量，用户在后端之间的数据移动不会受到影响，有效规避风险。即使社区不活跃，技术热度不高，我们的使用也不会受到影响。

假设一个公司需要 复杂消息系统 。由于需要处理世界各地的数据，必须支持跨地域复制。该企业一直在使用消息系统，因此对实时系统的复杂性有一定的了解，也发现了当前消息系统的不足之处。因此该企业对消息系统的要求是能够处理高级的消息传递和复杂的消息特性。

数据架构师团队和股东以及业务部门详细讨论了当前和未来需求。最后得出的结论是，Pulsar 和 Kafka 各有优势。同时，他们认为随着时间的推移，该使用场景和数据量都会有所增长。

在这种情况下，Pulsar 和 Kafka 难分胜负。要想作出正确决策，必须深入研究二者的使用场景。

Kafka 既提供私有的（价格高）跨地域复制，也提供开源的（附加服务）跨地域复制解决方案。私有的跨地域复制解决方案为其内置特性，但价格高昂。开源的解决方案（MirrorMaker）实际上就是数据复制，但由于不是其内置特性，会增加运营开销。

Pulsar 提供开源内置的跨地域复制特性，支持复杂的复制策略。对于使用场景和数据量都在增加的企业而言，显然，支持内置跨地域复制策略的 Pulsar 完胜。

由于企业正在向新消息平台迁移，消息系统最好可以处理新使用场景。数据架构师团队一直在了解各个平台，尝试寻找最佳解决方案。在当前使用的消息系统中，一旦出现处理错误，必须重新生成消息，再手动重试，因此最好还可以引入消息延迟发送。另外，当前消息系统的 schema 实施功能也有待加强，各个团队选择不同的 schema 实现时，团队合作的难度显著增加。

Kafka 没有内置死信队列特性，一旦消息处理失败，必须手动处理，或修改代码重试。Kafka 也没有延迟发送消息的内置机制，延迟发送消息流程复杂、工作量大。另外，Kafka 没有内置 schema 实施机制，导致云服务提供商分别提供了不同的 schema 解决方案。

Pulsar 内置死信队列特性，当消息处理失败，收到否认 ack 时，Pulsar 可以自动重试，但次数有限。Pulsar 也支持延迟发送消息，可以设定延迟时间。对于 Pulsar 而言，schema 级别高，因此 Pulsar 有内置 schema 注册，Pulsar API 也原生支持 schema。

随着对架构的深入了解，我们发现为了确保均匀分配资源，需要循环发送同一 topic 上的数据，并且需要通过排序确保消息有序排列。

Kafka 不能分发消息给指定的 consumer。当 consumer 接收到不属于它消费的消息时，要保证这些消息被正确消费，我们只能重新发送这些消息到额外的 topic 中，但这样会造成数据冗余，增加使用成本。因此，我们需要可以制定路由规则发送给指定 consumer 的产品。

Pulsar broker 可以通过制定的路由规则，把一个 topic 的不同消息根据路由规则发送到指定的 consumer 中。Pulsar broker 轻松实现了我们的目标，无需任何额外工作。

为了全面比较 Pulsar 和 Kafka，我们还需要看一下二者的部署数量和社区概况。

从服务市场来看，Kafka 的提供商更多，销售和支持 Kafka 产品的团队也更多。Kafka 和 Pulsar 的开源社区都积极活跃，但 Kafka 的社区规模更大。

从使用市场来看，Kafka 和 Pulsar 都已部署在大公司的大型生产环境中。在生产环境中部署 Kafka 的公司在数量上更胜一筹。

从用户数量来看，Kafka 的用户更多。但是，数据工程师团队认为， Kafka 的使用者可以轻松学习 Pulsar。

就服务支持和社区而言，我们选择 Kafka。但值得一提的是，Pulsar 社区正在迅速发展。

由于 Pulsar 和 Kafka 在这一使用场景中都有明显的优劣势，决策难度大大增加。

Pulsar 可以在社区和部署上奋起直追，Kafka 则可以努力丰富产品特性。

在作出决策前，我们先来总结一下，该企业在技术上最看重哪方面；在技术方面，我们是否需要做最保守的选择。根据以往的经验，新的开源技术会带来更多惊喜，因此我们更倾向于选择 Pulsar。

如果选择 Kafka，我们需要承担向业务赞助商坦诚 “我们无法处理这一使用场景” 的风险。甚至，即使支付大笔资金购买跨地域复制许可，也无法保证顺利实现客户的需求。业务团队最终可能需要花大量时间（甚至几个月）来编写、完善、测试他们的工作方案。

如果选择 Pulsar，我们可以告诉业务赞助商 “一切尽在掌握中”。由于 Pulsar 的各项内置特性都已经过测试，使用团队可以在短时间内完成部署。

在这种情况下，因为我们不需要 Kafka API 的独有特性，所以我们没有使用支持 Kafka 协议（KOP）的 Pulsar Broker，而是选择 Pulsar API，因为 Pulsar API 支持所有我们需要 Kafka API 提供的功能。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!