深入拆解消息队列 47 讲
许文强
前腾讯云 Kafka 技术负责人
5385 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 50 讲
深入拆解消息队列 47 讲
15
15
1.0x
00:00/00:00
登录|注册

09|消费端:消费者客户端的SDK有哪些设计要点?(下)

你好,我是文强。
这节课我们继续来讲消费端,上节课我们学习了消费模型的选择和分区消费模式设计,这节课我们将学习剩下的三部分,也就是消费分组(订阅)、消费确认、消费失败处理。

消费分组

消费分组是用来组织消费者、分区、消费进度关系的逻辑概念。为什么需要消费分组呢?
在没有消费分组直接消费 Topic 的场景下,如果希望不重复消费 Topic 中的数据,那么就需要有一个标识来标识当前的消费情况,比如记录进度。这个唯一标识就是消费分组。
在一个集群中可以有很多消费分组,消费分组间通过名称来区分。消费分组自身的数据是集群元数据的一部分,会存储在 Broker 的元数据存储服务中。消费分组主要有管理消费者和分区的对应关系、保存消费者的消费进度、实现消息可重复被消费三类功能。
消费分组和 Topic 是强相关的,它需要包含 Topic 才有意义,一个空的消费分组是没有意义的。如下图所示,消费分组内有很多个消费者,一个消费分组也可以订阅和消费多个 Topic,一个 Topic 也可以被多个消费分组订阅和消费。
因为 Topic 不存储真实数据,分区才存储消息数据,所以就需要解决消费者和分区的分配关系,即哪个分区被哪个消费者消费,这个分配的过程就叫做消费重平衡(Rebalance)
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

消费端SDK设计要点主要包括消费分组、协调者、消费分区分配策略等方面。消费分组用于组织消费者、分区、消费进度关系,管理消费者和分区的对应关系、保存消费者的消费进度、实现消息可重复被消费。协调者执行消费重平衡,并记录消费分组的消费进度。消费分区分配策略需遵循均匀分配、减少关系变动、根据业务特性制定分配关系等原则,一般包括轮询、粘性、自定义等类型的策略。一致性哈希算法和特色的分区分配策略也被广泛应用。 消费确认包括确认后删除数据和确认后保存消费进度数据两种形式。确认后删除数据指数据被消费成功后立即删除,不利于回溯消费;确认后保存消费进度是配合消费分组使用,保证消息的回溯消费和多次消费。提交位点信息一般支持自动提交和手动提交,建议使用手动提交以避免数据丢失。客户端自定义保存消费进度信息灵活但带来额外工作量。 消费失败处理包括从服务端拉取数据失败、本地业务数据处理失败、提交位点信息失败。异常处理需保证数据能被正常消费,重点关注不丢数据、不重复消费、不阻塞消费。消费端设计需满足基本消费需求、稳定性和性能需求、功能需求,支持回溯消费、消费删除、广播消费等。 在解决Topic消息写入倾斜问题时,可根据数据是否可丢弃、是否需要保证消费顺序选择重置消费位点、切换到共享消费模式或从发送端入手解决写入倾斜问题。 消费端SDK设计要点涵盖了消费分组管理、协调者执行、分区分配策略制定等多个方面,以满足消费者对消息队列的高效消费需求。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入拆解消息队列 47 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • shan
    消费者客户端SDK设计总结 消费分组 通过消费者分组可以管理消费者消息的消费,一个集群中可以有很多消费组,消费者相关的元数据信息会保存在Broker的元数据存储服务中。 一个消费组可以订阅多个Topic,一个Topic也可以被多个消费组订阅和消费。 消费重平衡(Rebalance) 一般会为每个消费者分配对应的消息队列,这个分配的过程叫做消费重平衡(Rebalance),协调者的工作就是执行消费重平衡。以下两种方案: (1)协调者进行分配:协调者内部完成消费重平衡之后,将分配结果同步给所有消费者; (2)在消费者端完成:不需要协调者,每个消费者在自己本地进行消费重平衡,RocketMQ在5.0之前采用的就是这种方式; 一般消费者发生变化(上线或者下线)/ Topic分区/队列发生变化的时候,会触发执行消费重平衡。 分配策略 分区/消费队列的分配策略一般有以下几大类: (1)轮询,将分区/队列排序,按顺序依次分配给各个消费者,如果分区/队列数量与消费者数量不均衡,有可能出现某个消费者分配过多或者有些消费者没有队列可以分配的情况,导致负载倾斜; (2)粘性:尽量减少分区分配关系的变动,从而减少重平衡所耗费的时间和资源损耗; (3)自定义分配策略; RocketMQ在5.0以前按队列粒度分配给消费者,主要有以下几种策略: (1)平均分配策略; (2)平均轮询分配策略; (3)一致性hash分配; (4)根据配置进行分配; (5)根据机房分配; (6)优先分配同机房策略; Rocket5.0以后可以按照消息粒度,将消息直接分配到消费者消费,具体可以参考官方文档: https://rocketmq.apache.org/zh/docs/featureBehavior/08consumerloadbalance 消费确认 消息消费完毕之后,需要向服务端发送ACK,服务端一般有两种方式处理消费后的消息: (1)删除数据:每条消只能被消费一次,这种方案一般很少采用; (2)保存消费进度:服务端保存每个队列的消费进度(一般会按消费者划分),数据的删除交由过期策略执行,消息队列大多数采用的就是这种方案;
    2023-09-23归属地:美国
  • Geek_368613
    “通过消费分组的名称计算出来一个 hash 值和 __consumer_offset 的分区数,取余计算得出一个分区号”,请问下文强老师,这个计算的操作是由谁来完成的呢?
    2023-07-19归属地:北京
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部