Apache Pulsar 消息传递语义

Apache Pulsar message delivery semantics

我浏览了 Apache Pulsar 消息传递语义文档。提到的 Apache 函数的交付语义(至少一次,至多一次,有效一次),如果我们不使用 Apache 函数,那么有哪些不同的交付语义可用?

Pulsar 提供至少一次语义。它还可以删除对其日志的重复写入(称为幂等生产),并且可以使用外部数据存储(与其他消息传递系统一样)合成有效的一次消费。对于自给自足的 effectively/exactly-once 处理,例如进行流处理,您需要使用 Kafka 或 Flink。

您可以实现您列出的所有消息传递语义,包括至少一次、最多一次和有效一次。

最多一次,您将使用独占订阅类型来确保只有消费者收到消息,并让您的消费者确认它收到的所有消息,无论是否发生异常。

对于 effectively-once,您将使用独占订阅类型来确保只有消费者收到消息,并且只有在您能够成功处理消息(即没有例外等)时才发送确认,否则,您会否定消息以重新传递它。

所有其他行为组合都属于至少一次交付保证。

https://pulsar.apache.org/docs/en/2.5.1/concepts-messaging/#consumers

TL;DR: 今天,Pulsar Functions、Pulsar+Spark (you will see duplicates), nor Pulsar+Flink (you will see duplicates) 都不支持 effectively-once 语义又名 exactly-once 语义。只有在某些边缘情况下,您才能通过 DIY 设置手动实现此类语义。 Pulsar 今天支持的是 (1) at-most-once 语义 = 你可能会丢失数据和 (2) at-least-once 语义= 您不会丢失数据,但可能会看到重复数据。

关于(3) effectively-once support:我当然可以想象你被搞糊涂了。尽管 Pulsar 文档中声称支持 effectively-once 语义,并且有几篇(不幸的是误导性的)关于该主题的博客文章 (example),但 Pulsar 实际上并不支持这一点。 Pulsar 支持的是幂等生产者和消息去重。这个功能确实是必需的,但是——这是重要的方面——对于恰好一次语义来说不够。当前功能仅在生成一条消息且仅发送到一个分区时才有效。例如,您现在无法使用 Pulsar 以原子方式向一个分区生成多条消息,更不用说多个分区了。这也意味着与状态的交互(例如,用于聚合数据,如计数、执行数据流之间的连接)不是恰好一次。

缺少什么,Pulsar 什么时候支持恰好一次语义? 为了保证恰好一次语义,Pulsar 必须首先添加对 transactions[=39 的支持=].这确实是一个计划中的功能,Pulsar 2.6.0 的原始 ETA 于 2020 年 6 月发布,但截至今天 still a lot of work left to be done。恐怕我不知道更新的预计到达时间。

在哪里可以了解更多信息: Pulsar 提交者在 2019 年 12 月的演讲 Apache Pulsar: Transactions Preview 总结了当前的不足exactly-once 支持,并解释了为什么需要支持 Pulsar 中的事务才能实现它。

从总体上理解这个棘手主题的另一个很好的来源是这个由 3 部分组成的系列文章,内容是关于 Apache Kafka (blog series part1, part2, part3), which is a technology similar to Apache Pulsar. The series explains why idempotent producers are just one piece of the puzzle, and why transactions are needed (which utilize the former), and how this was designed and implemented in Apache Kafka, and released back in 2017. That's why you benefit from exactly-once semantics when processing data in Kafka with e.g. Kafka Streams (included in Kafka) or with Kafka and Apache Flink 如何提供 exactly-once 语义。如果您查看 Pulsar 在 2020 年引入一次性支持的计划和路线图,您会清楚地看到与 Kafka 的方法非常相似。作为用户,显着的区别是 Kafka 一次发布了所有功能(这也解释了为什么 Kafka 社区花了几年时间来设计、构建和测试该功能),而不是一个接一个地发布,它有更清楚地了解实际支持的内容和不支持的内容。

免责声明:我在 Confluent 工作,这是为 Apache Kafka 做出贡献的公司之一。