Kafka简单汇总

java 复制代码
Kafka的结构图
多个Parttion共同组成这个topic的所有消息。

每个consumer都属于一个consumer group,每条消息只能被consumer group中的一个Consumer消费,
但可以被多个consumer group消费。即组间数据是共享的,组内数据是竞争的。

二、消费模型

1、点对点消息传递模式

【发布者】-【queue】-【消费者】

java 复制代码
点对点消息系统中,消息持久化到一个queue(队列)中。此时,将有一个或多个消费者消费队列中的数据。
但是一条消息只能被消费一次。当一个消费者消费了队列中的某条数据之后,该条数据则从消息队列中删除,
也就是消费者从Queue里面抢消息。

2、发布-订阅消息传递模式

【发布者】-【Topic】-【消费者】

java 复制代码
发布-订阅消息系统中,消息被持久化到一个topic中。与点对点消息系统不同的是,消费者可以订阅一个或多个topic(分类),
消费者可以消费该topic中所有的数据,同一条数据可以被多个消费者消费,数据被消费后不会立马删除。

需要注意上面两种模式,是有条件的,只有Gruop组和Consumer达到一定的数量比,才会触发。

1、当某个Topic只有一个消费组订阅,且该消费组只有一个消费者时,就是队列(queue)下的点对点消费模式。
2、当某个Topic有多个消费组订阅,且每个消费组只有一个消费者时,就是发布订阅模式

三、消费过程

当2个消费者在消费同一个分区时,2个消费者都在在各自里面记录当前的offset。

生产者生产消息,添加到topIc时,每次都是追加到末尾。

java 复制代码
为了提高Kafka的吞吐量,物理上把Topic分成一个或多个Partition,每个Partition都是有序且不可变的消息队列。
每个Partition在物理上对应一个文件夹,该文件夹下存储这个Partition的所有消息和索引文件。
java 复制代码
消费者组,在不同的分区有不同的offset。

四、分区策略

java 复制代码
所谓分区策略是决定【生产者】将消息发送到哪个分区的算法。Kafka为我们提供了
默认的分区策略,同时它也支持自定义分区策略。


1、轮询策略:Round-robin 策略,即顺序分配。
轮询策略有非常优秀的负载均衡表现,它总是能保证消息最大限度地被平均分配到所有分区上,故默认情况下它是最合理的分区策略,也是最常用的分区策略之一。


2、随机策略-Randomness 策略。随机就是随意地将消息放置到任意一个分区上。

4、按消息键保序策略-Key-ordering 策略。
Kafka 允许为每条消息定义消息键,简称为 Key。这个 Key 的作用非常大,它可以是一个有着明确业务含义的字符串;也可以用来表征消息元数据。一旦消息被定义了 Key,那么你就可以保证同一个 Key 的所有消息都进入到相同的分区里面,由于每个分区下的消息处理都是有顺序的,故这个策略被称为按消息键保序策略。


默认分区规则
1、如果指定的partition,那么直接进入该partition
2、如果没有指定partition,但是指定了key,使用key的 hash一选择partition。
3、如果既没有指定partition,也没有指定key,使用轮询一的方式进入partition。

五、ACK 应答机制

1、生产者确认机制

生产者发送消息,Broker落盘状态,0、1、all

2、消费者确认机制

在Kafka中,消费者确认是通过消费者位移的提交实现的。类似RabbitMQ的ACK机制。

java 复制代码
消费者位移
每个 consumer 实例都会为它消费的分区维护属于自己的位置信息来记录当前消费了多少条消息。这在 Kafka 中有一个特有的术语:位移(offset)。
相比较将offset保存在服务器端(broker),这样虽然简单,但是有如下的问题:
	1、broker变成了有状态的,增加了同步成本,影响伸缩性。
	2、需要引入应答机制来确定消费成功。
	3、由于需要保存众多consumer的offset,可能需要引入复杂的数据结构,对资源有一定的浪费。

在Kafka中,消费者组(Consumer Group)负责管理分发消费消息,因此将offset保存在消费者组中是比较合适的选择。其数据格式只需要是特定格式的整形数据即可。
offset 对于 consumer 非常重要,因为它是实现消息交付语义保证(message delivery semantic)的基石。
消息交付语义即最多一次、最少一次、精确一次。
相关推荐
gQ85v10Db8 小时前
Redis分布式锁进阶第十七篇:微服务分布式锁全局治理 + 跨团队统一规范落地 + 全链路稳定性提升方案
redis·分布式·微服务
gQ85v10Db15 小时前
Redis分布式锁进阶第十八篇:本地缓存+分布式锁双锁架构 + 高并发削峰兜底 + 极致性能无损优化实战
redis·分布式·缓存
小江的记录本15 小时前
【Kafka核心】Kafka高性能的四大核心支柱:零拷贝、批量发送、页缓存、压缩
java·数据库·分布式·后端·缓存·kafka·rabbitmq
gQ85v10Db15 小时前
Redis分布式锁进阶第十四篇:全系列终局架构复盘 + 锁体系统一规范 + 线上全年零事故收官方案
redis·分布式·架构
KmSH8umpK15 小时前
Redis分布式锁进阶第十二篇
数据库·redis·分布式
gQ85v10Db16 小时前
Redis分布式锁进阶第十六篇:番外高阶避坑篇 + 隐性埋点锁故障深挖 + 疑难杂症终极兜底方案
数据库·redis·分布式
KmSH8umpK17 小时前
Redis分布式锁从原生手写到Redisson高阶落地,附线上死锁复盘优化方案进阶第九篇
数据库·redis·分布式
gQ85v10Db17 小时前
Redis分布式锁进阶第十五篇:全系列终极收官复盘 + 全站锁规范归档 + 生产零故障长期运维兜底总方案
运维·redis·分布式
_F_y18 小时前
仿RabbitMQ实现消息队列-服务端核心模块实现(5)
分布式·rabbitmq
Lyyaoo.18 小时前
Redis实现分布式锁
数据库·redis·分布式