标签:nbsp 了解 方便 两阶段 工作方式 实现 禁用 主题 记录
4.6 Message Delivery Semantic(消息传递语义)
现在我们了解了生产者和消费者的工作方式,让我们讨论Kafka在生产者和消费者之间提供的语义保证。显然,可以提供多种可能的消息传递保证:
值得注意的是,这会分解为两个问题:发布消息的持久性保证以及消费消息时的保证。
许多系统声称提供“恰好一次”的交付语义,但阅读细则会发现,大多数这些说法具有误导性(即它们不会转化为消费者或生产者可能失败的情况,或者存在多个消费者进程情况,或者写入磁盘的数据可能丢失的情况)。
kafka的语义很直接。在发布消息时,我们有一个消息被“提交”到日志的概念。一旦已发布的消息被确认提交了;在该消息所有的副本中有一个副本所对应的分区代理中,只要有一个代理保持“活动”,它就不会丢失。alive的定义以及我们尝试处理哪些类型的故障的描述将在下一节中更详细地描述。现在让我们假设一个完美无损的broker,并尝试了解生产者和消费者对消息传递语义的保证。如果生产者尝试发布消息并遇到网络错误,并且无法确定在提交消息之前,还是之后是否发生了此错误。这类似于使用自动生成的key插入数据库表的情况。
这并不是生产者最想要表达的意思。虽然我们无法确定在网络错误的情况下发生了什么,但是可以允许生产者生成一种“主键”,使得重新生成请求是幂等的。对于复制系统而言,此功能并非易事,因为它必须在服务器发生故障的情况下能够工作。使用此功能,生产者可以重试,直到它收到成功提交的消息的确认,此时我们将保证消息仅仅只发布一次。我们希望在未来的Kafka版本中添加它。
并非所有用例都需要这样强有力的保证(每条消息只发布一次)。对于延迟敏感的用途,我们允许生产者指定它所需的耐久性等级。如果生产者指定它要等待提交的消息,则可以采用10毫秒的量级。然而,生产者也可以指定它想要完全异步地执行发送,或者它只想等到领导者(没有必要是followers)有消息。
现在让我们站在消费者的角度来描述语义。所有副本都具有完全相同的日志,具有相同的偏移量。消费者控制其在此日志中的位置(偏移量)。如果消费者从未崩溃,它可以将此位置(偏移量)存储在内存中,但如果消费者失败,此时我们希望该主题分区被另一个进程接管,则新进程将需要选择适当的位置以开始处理。假设消费者已经读取了一些消息 - 它有几种处理消息和更新其位置(偏移量)的选项(方式)。
因此,Kafka保证默认情况下至少一次交付,并允许用户通过禁用生产者的重试并在处理一批消息之前提交其偏移量,实施最多一次交付。完全一次交付需要与目标存储系统合作,但Kafka提供了偏移,这使得实现这一点变得更加简洁方便。
标签:nbsp 了解 方便 两阶段 工作方式 实现 禁用 主题 记录
原文地址:https://www.cnblogs.com/dreamfor123/p/9415630.html