强无敌！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 提供的成果。

（编辑：湖南网）

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