Kafka -- 初识

目录

kafka是什么

Topic

Partition

Broker

Cousumer

CousumerGroup

Offset

reblance

[broker 消息存储](#broker 消息存储)

Isr


kafka是什么

Kafka 是一个分布式的消息引擎,能够发布和订阅消息流(类似于消息队列) 以容错的、持久的方式存储消息流 多分区概念,提高了并行能力。

架构如下图:

Topic

消息的主题、队列,每一个消息都有它的 topic,Kafka 通过 topic 对消息进行归类。Kafka 中可以将 Topic 从物理上划分成一个或多个分区(Partition),每个分区在物理上对应一个文件夹,以"topicName_partitionIndex" 的命名方式命名,该 dir 包含了这个分区的所有消息 (.log) 和索引文件 (.index),这使得 Kafka 的吞吐率可以水平扩展。

Partition

每个分区都是一个顺序的不可变的消息队列, 并且可以持续的添加;

分区中的消息都被分了一个序列号,称之为偏移量 (offset),在每个分区中此偏移量都是唯一的。

producer 在发布消息的时候,可以为每条消息指定 Key,这样消息被发送到 broker 时,会根据分区算法把消息存储到对应的分区中(一个分区存储多个消息),如果分区规则设置的合理,那么所有的消息将会被均匀的分布到不同的分区中,这样就实现了负载均衡。

Broker

Kafka server,用来存储消息,Kafka 集群中的每一个服务器都是一个 Broker,消费者将从 broker 拉取订阅的消息 Producer 向 Kafka 发送消息,生产者会根据 topic 分发消息。生产者也负责把消息关联到 Topic 上的哪一个分区。最简单的方式从分区列表中轮流选择。也可以根据某种算法依照权重选择分区。算法可由开发者定义。

Cousumer

Consermer 实例可以是独立的进程,负责订阅和消费消息。消费者用 consumerGroup 来标识自己。同一个消费组可以并发地消费多个分区的消息,同一个 partition 也可以由多个 consumerGroup 并发消费,但是在 consumerGroup 中一个 partition 只能由一个 consumer 消费。

CousumerGroup

同一个 Consumer Group 中的 Consumers,Kafka 将相应 Topic 中的每个消息只发送给其中一个 Consumer

Offset

onsumer 的消息位移代表了当前 group 对 topic-partition 的消费进度,consumer 宕机重启后可以继续从该 offset 开始消费。 在 kafka0.8 之前,位移信息存放在 zookeeper 上,由于 zookeeper 不适合高并发的读写,新版本 Kafka 把位移信息当成消息,发往 **consumersoffsets 这个 topic 所在的 broker, _consumersoffsets 默认有 50 个分区。 消息的 key 是 groupId+topicpartition,value 是 offset.

reblance

一些原因导致 consumer 对 partition 消费不再均匀时,kafka 会自动执行 reblance,使得 consumer 对 partition 的消费再次平衡。以下导致再平衡:

  • 组订阅 topic 数变更
  • topic partition 数变更
  • consumer 成员变更
  • consumer 加入群组或者离开群组的时候
  • consumer 被检测为崩溃的时候

新版本之后,通过延迟进入 PreparingRebalance 状态减少 reblance 次数;

broker 消息存储

Kafka 的消息以二进制的方式紧凑地存储,节省了很大空间 此外消息存在 ByteBuffer 而不是堆,这样 broker 进程挂掉时,数据不会丢失,同时避免了 gc 问题 通过零拷贝和顺序寻址,让消息存储和读取速度都非常快 处理 fetch 请求的时候通过 zero-copy 加快速度

Isr

Kafka 结合同步复制和异步复制,使用 ISR(与 Partition Leader 保持同步的 Replica 列表)的方式在确保数据不丢失和吞吐率之间做了平衡。Producer 只需把消息发送到 Partition Leader,Leader 将消息写入本地 Log。Follower 则从 Leader pull 数据。Follower 在收到该消息向 Leader 发送 ACK。一旦 Leader 收到了 ISR 中所有 Replica 的 ACK,该消息就被认为已经 commit 了,Leader 将增加 HW 并且向 Producer 发送 ACK。这样如果 leader 挂了,只要 Isr 中有一个 replica 存活,就不会丢数据。

相关推荐
8Qi87 小时前
DDD架构演进
java·分布式·mvc·ddd
方方洛7 小时前
ray教程-23-附录C-术语表
人工智能·分布式·机器学习
皮皮林5518 小时前
Kafka 怎么保证消费只消费一次的?
kafka
茶海棠13 小时前
Hadoop+zookeeper+HBase+Kafka集群搭建全流程
hadoop·zookeeper·kafka·hbase
海棠Flower未眠15 小时前
下单请求处理流程:商品维度分布式锁与 Redis 预扣库存
redis·分布式·junit
罗四强16 小时前
第10篇:打包上架:签名、打包 HAP、发布到华为应用市场
分布式·操作系统·harmonyos·arkts·鸿蒙系统
秋饼16 小时前
Redis 全面解析:从数据结构到主从/哨兵/集群、分布式锁与面试高频考点,代码到原理一次讲透
数据库·redis·分布式·面试·后端开发
二月夜16 小时前
Redis 高频面试题全解:缓存三大问题、大 key 治理与分布式锁之争(2026 招聘 JD 真题复盘)
redis·分布式·后端·缓存
后台模板学习17 小时前
Kafka 与 RabbitMQ 在用户认证与权限管理场景
kafka·rabbitmq·linq
樱花落木兰17 小时前
Redis 消息队列的可靠性演进:从 List、Pub/Sub 到 Stream 消费者组,以及 8.x 版本改变了什么
java·开发语言·经验分享·redis·分布式·python·软件工程