前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Kafka-9.设计-消息分发语义

Kafka-9.设计-消息分发语义

作者头像
悠扬前奏
发布2019-06-15 19:17:19
4790
发布2019-06-15 19:17:19
举报

4.6 消息分发语义

在了解了生产者和消费者的工作方式之后,我们来讨论Kafka在生产者和消费者之间提供的语义保证。 显然,有多个可能的消息专题保证可以提供:

  • 最多一次——消息可能会丢失,但是永远不会重复传递
  • 至少一次——消息永远不会丢失,但是可能会被重新传递
  • 恰好一次——这是人们真正想要的,每条消息传递一次

值得注意的是,这会分解成两个问题:发布消息的持久性保证以及消费消息时的保证。 许多系统声称可以提供恰好一次的交付语义,但是阅读细则很重要,这些声明中的大多数具有误导性(即它们不能翻译为消费者或生产者可能失败的情况,有多个消费者进程,或者数据写入磁盘可能失败的情况)。

Kafka的语义很直接。在发布消息时,我们有一个消息被“提交”到日志的概念。一旦提交已经发布的消息,只要把消息复制到分区的broker保持“活动”,它就不会丢失。提交消息的定义,活动分区以及我们尝试处理那些类型的故障的描述将在下一节中详细描述。现在让我们假设一个完美的broker,并且尝试了解对生产者和消费者的保证。如果生产者尝试发布消息并遇到网络错误,则无法确定在提交消息之前或者之后发生了此错误。这类似于使用自动生成的密钥插入数据库表的语义。

在0.11.0.0之前,如果生产者未能收到表明消息已经提交的响应,则除了重新发送请求之外别误选择。这提供了至少一次传递语义,因为如果原始请求实际上请求成功了,则在重新发送期间可以再次将消息写入日志。从0.11.0.0开始,Kafka还支持幂等传递选项,该选项保证重新发送不会在日志中导致重复条目。为了实现这个目的,broker为每个生产者分配一个ID,并使用生产者发送的序列号和每条消息对每条消息进行重复数据删除。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019.06.13 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 4.6 消息分发语义
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档