【Kafka从入门到放弃系列 五】Kafka架构深入——消费者策略

简介: 【Kafka从入门到放弃系列 五】Kafka架构深入——消费者策略

在上一篇blog【Kafka从入门到放弃系列 四】Kafka架构深入——生产者策略中详细分析了较为复杂的生产者策略,本篇blog就聊聊相对简单的消费者策略吧。

消费方式

消息有两种方式被投递,一种是broker推给消费者,一种是消费者从broker拉。这两种方式各自有优缺点:

  • push 模式很难适应消费速率不同的消费者,因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息,但是这样很容易造成 consumer 来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。
  • pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。pull 模式不足之处是,如果 kafka 没有数据,消费者可能会陷入循环中,一直返回空数据

对于 Kafka 而言,pull 模式更合适,它可简化 broker 的设计,consumer 可自主控制消费消息的速率,同时 consumer 可以自己控制消费:

  • 控制消费方式——既可批量消费也可逐条消费,同时还能选择不同的提交方式从而实现不同的传输语义
  • 超时返回机制——Kafka 的消费者在消费数据时会传入一个时长参数 timeout,如果当前没有数据可供消费,consumer 会等待一段时间之后再返回,这段时长即为 timeout

通过pull以及一定的策略可以满足Kafka的消费诉求。需要注意:

  • 如果消费线程大于 patition 数量,则有些线程将收不到消息;
  • 如果 patition 数量大于消费线程数,则有些线程多收到多个 patition 的消息;
  • 如果一个线程消费多个 patition,则无法保证你收到的消息的顺序,而一个 patition 内的消息是有序的。

这三点需要注意,消息的消费和分区个数的关系。

分区分配策略

一个 consumer group 中有多个 consumer,一个 topic 有多个 partition,所以必然会涉及到 partition 的分配问题,即确定那个 partition 由哪个 consumer 来消费。Kafka 有三种分配策略: RoundRobin, Range,Sticky。无论是哪种策略,当消费者组里的消费者个数的变化【增多或减少】或者订阅主题分区的增加都会触发重新分配

Rang策略

Range分配策略是面向每个主题的,首先会对同一个主题里面的分区按照序号进行排序,并把消费者线程按照字母顺序进行排序。然后用分区数除以消费者线程数量来判断每个消费者线程消费几个分区。如果除不尽,那么前面几个消费者线程将会多消费一个分区。当然,这样的缺点就是对每个组内的每个消费者分布不均匀。举例如下:

这样ConsumerA承受的压力会越来越大。假设n=分区数/消费者数量m=分区数%消费者数量,那么前m个消费者每个分配n+1个分区,后面的(消费者数量-m)个消费者每个分配n个分区。

假如有10个分区,3个消费者线程,把分区按照序号排列0,1,2,3,4,5,6,7,8,9;消费者线程为C1-0,C2-0,C2-1,那么用partition数除以消费者线程的总数来决定每个消费者线程消费几个partition,如果除不尽,前面几个消费者将会多消费一个分区。在我们的例子里面,我们有10个分区,3个消费者线程,10/3 = 3,而且除除不尽,那么消费者线程C1-0将会多消费一个分区,所以最后分区分配的结果看起来是这样的:

C1-0:0,1,2,3
C2-0:4,5,6
C2-1:7,8,9

如果有11个分区将会是:

C1-0:0,1,2,3
C2-0:4,5,6,7
C2-1:8,9,10

假如我们有两个主题T1,T2,分别有10个分区,最后的分配结果将会是这样:

C1-0:T1(0,1,2,3) T2(0,1,2,3)
C2-0:T1(4,5,6) T2(4,5,6)
C2-1:T1(7,8,9) T2(7,8,9)

可以看出, C1-0消费者线程比其他消费者线程多消费了2个分区

如上,只是针对 1 个 topic 而言,C1-0消费者多消费1个分区影响不是很大。如果有 N 多个 topic,那么针对每个 topic,消费者 C1-0 都将多消费 1 个分区,topic越多,C1-0 消费的分区会比其他消费者明显多消费 N 个分区。这就是 Range 范围分区的一个很明显的弊端了

RoudRobin策略

RoudRobin策略也即轮询策略,RoundRobin策略的原理是将消费组内所有消费者以及消费者所订阅的所有topic的partition按照字典序排序,然后通过轮询算法逐个将分区以此分配给每个消费者:

  • 如果同一消费组内,所有的消费者订阅的消息都是相同的,那么 RoundRobin 策略的分区分配会是均匀的。
  • 如果同一消费者组内,所订阅的消息是不相同的,那么在执行分区分配的时候,就不是完全的轮询分配,有可能会导致分区分配的不均匀。如果某个消费者没有订阅消费组内的某个 topic,那么在分配分区的时候,此消费者将不会分配到这个 topic 的任何分区。

这样的好处是,分配较为均衡

当然前提是同一个消费者组里的每个消费者订阅的主题必须相同,如果同一个消费组内所有的消费者的订阅信息都是相同的,那么RoundRobinAssignor策略的分区分配会是均匀的。

举例,假设消费组中有2个消费者C0和C1,都订阅了主题t0和t1,并且每个主题都有3个分区,那么所订阅的所有分区可以标识为:t0p0、t0p1、t0p2、t1p0、t1p1、t1p2。最终的分配结果为:

消费者C0:t0p0、t0p2、t1p1
消费者C1:t0p1、t1p0、t1p2

如果同一个消费组内的消费者所订阅的信息是不相同的,那么在执行分区分配的时候就不是完全的轮询分配,有可能会导致分区分配的不均匀。如果某个消费者没有订阅消费组内的某个topic,那么在分配分区的时候此消费者将分配不到这个topic的任何分区。

Sticky策略

这样的分区策略是从0.11版本才开始引入的,它主要有两个目的

  • 分区的分配要尽可能均匀
  • 分区的分配要尽可能与上次分配的保持相同

举例进行分析:比如有3个消费者(C0,C1,C2),都订阅了2个主题(T0 和 T1)并且每个主题都有 3 个分区(p0、p1、p2),那么所订阅的所有分区可以标识为T0p0、T0p1、T0p2、T1p0、T1p1、T1p2。此时使用Sticky分配策略后,得到的分区分配结果和RoudRobin相同:

但如果这里假设C2故障退出了消费者组,然后需要对分区进行再平衡操作,如果使用的是RoundRobin分配策略,它会按照消费者C0和C1进行重新轮询分配,再平衡后的结果如下:

但是如果使用的是Sticky分配策略,再平衡后的结果会是这样:

虽然触发了再分配,但是记忆了上一次C0和C1的分配结果。这样的好处是发生分区重分配后,对于同一个分区而言有可能之前的消费者和新指派的消费者不是同一个,对于之前消费者进行到一半的处理还要在新指派的消费者中再次处理一遍,这时就会浪费系统资源。而使用Sticky策略就可以让分配策略具备一定的“粘性”,尽可能地让前后两次分配相同,进而可以减少系统资源的损耗以及其它异常情况的发生

offset的维护

在现实情况下,消费者在消费数据时可能会出现各种会导致宕机的故障问题,这个时候,如果消费者后续恢复了,它就需要从发生故障前的位置开始继续消费,而不是从头开始消费。所以消费者需要实时的记录自己消费到了哪个offset,便于后续发生故障恢复后继续消费。Kafka 0.9版本之前,consumer默认将offset保存在Zookeeper中,从0.9版本开始,consumer默认将offset保存在Kafka一个内置的topic中,该topic为 __consumer_offsets :

同一个组里的,当动态扩展分区分配时新进入的消费者接着消费分区消息而不是重新消费。offset是按照:goup+topic+partion来划分的,这样保证组内机器有问题时能接着消费

消费者组测试

修改机器配置文件,让102机器和103机器处于一个分组中:

然后在101启动生产者发送消息,同时在102和103接收消息:

发现在同一时间只有102机器收到了消息:

103机器则没有收到任何消息:

验证了Kafka的消费准则:同一个组内同一分区只能被一个消费者消费,可以理解,如果一个组内多个消费者消费同一个分区,那么该消费者组如何保证单分区消息的顺序性呢?

相关文章
|
10天前
|
消息中间件 分布式计算 Kafka
Kafka(四)【Kafka 消费者】(4)
Kafka(四)【Kafka 消费者】
|
17天前
|
机器学习/深度学习 运维 Cloud Native
构建未来:云原生架构在企业数字化转型中的关键作用构建高效机器学习模型的五大策略
【5月更文挑战第31天】 随着企业数字化进程的加速,传统的IT架构日益显示出其局限性。本文将探讨云原生架构如何成为推动企业敏捷性、可扩展性和创新能力的核心力量。通过深入分析云原生技术的基本原理及其在业务连续性、资源优化和跨云协作方面的应用,揭示了其在实现高效、灵活的企业IT环境中所扮演的角色。
|
4天前
|
消息中间件 Kafka
Kafka生产者和消费者相关命令行操作
Kafka生产者和消费者相关命令行操作
11 1
|
10天前
|
消息中间件 存储 算法
Kafka(四)【Kafka 消费者】(3)
Kafka(四)【Kafka 消费者】
|
10天前
|
消息中间件 Kafka API
Kafka(四)【Kafka 消费者】(2)
Kafka(四)【Kafka 消费者】
|
10天前
|
消息中间件 存储 Java
Kafka(四)【Kafka 消费者】(1)
Kafka(四)【Kafka 消费者】
|
13天前
|
消息中间件 Java Kafka
springboot整合kafka消费者最佳实践
springboot整合kafka消费者最佳实践
19 1
|
13天前
|
消息中间件 负载均衡 监控
Kafka消费者:监听模式VS主动拉取,哪种更适合你?
Kafka消费者:监听模式VS主动拉取,哪种更适合你?
14 1
|
15天前
|
数据库 微服务 NoSQL
探索微服务架构下的数据库选型与优化策略
在现代软件开发中,微服务架构已成为一种常见的设计范式。而数据库在微服务架构中的选型与优化策略对整个系统的性能和稳定性至关重要。本文将探讨在微服务环境下,如何选择适合的数据库类型以及优化数据库性能的策略。
|
17天前
|
消息中间件 数据库 网络架构
构建高效后端:微服务架构的优化策略
【5月更文挑战第31天】在这篇文章中,我们将深入探讨如何通过采用微服务架构来提升后端开发的效率和性能。我们将分析微服务架构的关键优势,并讨论如何克服实施过程中的挑战。通过具体的案例研究,我们将展示如何优化微服务架构以实现最佳的性能和可维护性。无论你是后端开发的新手还是经验丰富的专业人士,这篇文章都将为你提供有价值的见解和实用的技巧。

热门文章

最新文章