Gre*_*Nun 5 apache-kafka kafka-producer-api
阅读有关主题分区中消息排序的文章:https : //blog.softwaremill.com/does-kafka-really-guarantee-the-order-of-messages-3ca849fd19d2
允许重试而不将max.in.flight.requests.per.connection设置为1可能会更改记录的顺序,因为如果将两个批次发送到单个分区,并且第一个批次失败并被重试,但是第二个批次成功,则记录在第二批中可能会首先出现。
据此,可以通过两种类型的生产者配置来实现订购保证:
max.in.flight.requests.per.connection=1 // can impact producer throughput
Run Code Online (Sandbox Code Playgroud)
或替代
enable.idempotence=true
max.in.flight.requests.per.connection //to be less than or equal to 5
max.retries // to be greater than 0
acks=all
Run Code Online (Sandbox Code Playgroud)
谁能解释第二种配置如何实现订单保证?另外,在第二个配置中,仅启用一次语义。
幂等性:(每个分区的顺序语义恰好一次)
幂等交付使生产者能够在单个生产者的生命周期内将消息准确地写入 Kafka 到主题的特定分区一次,而不会丢失数据和每个分区的顺序。
幂等是在 Kafka 中实现Exactly-once Semantics的关键特性之一。设置“enable.idempotence=true”最终会为每个分区获得恰好一次语义,这意味着特定分区没有重复,没有数据丢失。如果发生错误,即使生产者多次发送消息也会被写入 Kafka 一次。
Kafka生产者的PID和序列号概念实现幂等,解释如下:
PID 和序列号
幂等生产者在生产消息时使用产品 ID(PID)和序列号。生产者不断增加发布的每条消息的序列号,这些消息映射到唯一的 PID。代理总是将当前序列号与前一个序列号进行比较,如果新序列号不比前一个序列号大 +1,则它会拒绝,以避免重复,同时,如果消息中丢失了更多,则显示丢失。
在失败的情况下,它仍然会保持序列号并避免重复,如下所示:
注意:当生产者重新启动时,会分配新的 PID。所以幂等性只对单个生产者会话承诺
如果您使用 enable.idempotence=true 您可以将 max.in.flight.requests.per.connection 保持为 5,您可以实现顺序保证,从而带来更好的并行性并提高性能。
在我们使用 max.in.flight.requests.per.connection 和重试和确认设置达到一定程度的保证之前,Kafka 0.11+ 中引入了幂等特性:
max.in.flight.requests.per.connection to 1
max.retries bigger number
acks=all
Run Code Online (Sandbox Code Playgroud)
max.in.flight.requests.per.connection=1:确保在重试消息时,不会发送其他消息。
这提供了至少一次的保证,并伴随着性能和吞吐量的成本,这鼓励引入 enable.idempotence 功能来提高性能,同时保证排序。
Exactly_once:为了实现 Exactly_once 和幂等性,我们需要将事务设置为 read_committed 并且不允许覆盖以下参数:
isolation.level:read_committed(消费者将始终只读取提交的数据)
enable.idempotence=true(生产者将始终启用幂等性)
MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=5(生产者每个连接总是有一个进行中的请求)
归档时间: |
|
查看次数: |
132 次 |
最近记录: |