kafka底层原理分析

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: kafka底层原理分析

Kafka是由Linkedin公司开发的一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据

kafka具有众多良好的特性:

  • 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒
  • 可扩展性: kafka集群支持热扩展
  • 持久性、可靠性:消息被持久化到本地磁盘并且支持数据备份防止数据丢失
  • 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败
  • 高并发:支持数千个客户端同时读写

那么Kafka为什么如此一枝独秀?

系统架构

Kafka如此优良的特性来源于它良好的架构设计:

a17aad60d2b1053aa545d08c5a79d35d.png

在上图中:

  • Producer:消息的生产者;
  • Kafka Cluster:运行Kafka实例的集群;
  • Broker:一个kafka实例,可认为就是一台服务器;
  • Topic:消息的分类主题;
  • Partition:消息的分区,是指同一个topic的消息被分成了多个部分,减小了单独brokr的压力,实现负载均衡,不同分区的数据是不同的;注:分区的好处除了负载均衡,还有就是便于水平扩展
  • Follower、Leader:前者是备份,后者是主体,只有当主体出现故障时,才会选择一个备份(replica)作为新的主体;(注:主体和备份必定不在同一个实例上)
  • Consumer (Group):消息的消费者,多个消费者组成一个Group,kafka规定同一个Topic的消息只能被同一个消费者组的消费者消费;(提高吞吐量!)
  • Zookeeper:保存集群的信息,保证分布式系统的可用性;

工作流程

发送数据的流程如下:

ae55bdaa4b14aaf5022a6c8a51b5a966.png

从上图可知有几点需要注意:

  • 信息是往Leader传输的;
  • follower是主动pull消息的;
  • 只有follower完成了backup,才算是一次正常的消息发送;(保证消息不会丢失)

有一个问题,消息发送到哪一个partition呢

  • 如果消息中指定了Partition id,那就发送到对应的partition;
  • 如果没有,那就消息的key进行hash一下;
  • 如果id和key都没有,那就随机;

另外,kafka备份策略的的可以配置的,ACK可以配置为:0、1、all

  • 0表示不需要ACK,安全性低效率高;
  • 1表示需要一个ACK才会继续下一条;(一个follower接收就可以)
  • all表示所有的follower都完成才会继续下一条,效率最低;

**保存数据时,**kafka预先在磁盘开辟一块空间,而后顺序写入数据(比随机快多了),上文说topic是以partition的形式分布于集群中的,而partition表现为一个一个的文件夹,其中包含了多个segment文件夹,而segment下包含.index .log .timeindex文件(后者为新增的版本特性)。

c765c70621ff82ddab51447b528b4e3a.png

其中,index和timeindex为索引文件,log为实际存储message的文件。注意到每一个文件前都有一串序号,这就是kafka提高查找效率的方式——分段+索引。

log文件存储了message的三个重要属性:offset、消息大小、真正的消息数据

那么消费者是如何读取到特定的消息的呢?

6179e937c3fe23ee1e2dfc37c07a601e.png 需要注意的是:(怎么通知的?)

  • 消费者拉取数据时,也是从leader拉;
  • 多个partition可以被一个consumer消费但是反之不行

在读取消息时,需要通过offset从partiton中读取到相应的消息体,例如查找offset为368801的message,具体的过程详见:Kafka基本原理


7a51fc2a3ff7d6457e6f77b3a6bf4e9d.png

这套机制是建立在offset为有序的基础上,利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据!那么消费者如何知道自己消费了多少?以前,是放在zookeeper中,但可能造成重复消费,现在是存放在kafka集群的__consumer_offsets这个专有topic中

有一篇讲解kafkapartition和consumer之间的关系:stackflow

通信模式

目前流行的消息队列的通信模式主要有两种:点对点模式、发布订阅模式

  • 点对点模式

该模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。消息进入消息队列后,由消费者主动去拉取或轮询进而获得消息,这个模型的优点就在于由消费者来控制拉取消息的频率,缺点是需要额外的线程去监控是否有消息可用。(Kafka就是用的这个模型)

42ee9fc0e63a175e82c729c74e3f9db8.png

  • 发布订阅模式

发布订阅模式类似与报纸发行商与顾客:**当有新的消息放入消息队列中时,队列会将消息推送给订阅过该类消息的消费者。**优点即是不需要额外线程去感知消息是否存在,缺点就在于推送的速度是一个值得权衡的问题。

其他

为什么kafka只支持增加分区数量,而不能减小分区数量?

——减小分区数量有一个问题就在于,如何保证消息的可靠性?将数据移动至其他分区,又需要考虑offset的有序性,进一步讨论可查看为什么不能减小分区数量

Zookeeper

Zookeeper是Apache软件基金会的一个专为大型分布式计算机提供分布式配置服务、同步服务和命名注册的开源软件。

ookeeper的命名空间形似文件系统,以KV形式存储:

a1ff56f0da727fed68a9285c56988adb.png


注:一个分布式系统最多满足CAP理论中的其中两项;

注:BASE理论是指Basically Avaliable、Soft-state(软状态,即运行分布式系允许分布式系统出现中间状态)、Eventually Consistent(最终一致性)。(该理论是指虽然无法达到强一致性,但是要实现最终一致性)

详情可见:Zookeeper

相关文章
|
1月前
|
存储 消息中间件 大数据
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
32 4
|
1月前
|
消息中间件 druid 大数据
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(二)
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(二)
29 2
|
1月前
|
消息中间件 缓存 分布式计算
大数据-59 Kafka 高级特性 消息发送03-自定义拦截器、整体原理剖析
大数据-59 Kafka 高级特性 消息发送03-自定义拦截器、整体原理剖析
26 2
|
1月前
|
消息中间件 缓存 大数据
大数据-57 Kafka 高级特性 消息发送相关01-基本流程与原理剖析
大数据-57 Kafka 高级特性 消息发送相关01-基本流程与原理剖析
38 3
|
1月前
|
消息中间件 分布式计算 druid
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(一)
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(一)
49 1
|
1月前
|
消息中间件 NoSQL Kafka
大数据-116 - Flink DataStream Sink 原理、概念、常见Sink类型 配置与使用 附带案例1:消费Kafka写到Redis
大数据-116 - Flink DataStream Sink 原理、概念、常见Sink类型 配置与使用 附带案例1:消费Kafka写到Redis
113 0
|
1月前
|
消息中间件 druid Kafka
从Apache Flink到Kafka再到Druid的实时数据传输,用于分析/决策
从Apache Flink到Kafka再到Druid的实时数据传输,用于分析/决策
69 0
|
2月前
|
数据采集 消息中间件 存储
实时数据处理的终极武器:Databricks与Confluent联手打造数据采集与分析的全新篇章!
【9月更文挑战第3天】本文介绍如何结合Databricks与Confluent实现高效实时数据处理。Databricks基于Apache Spark提供简便的大数据处理方式,Confluent则以Kafka为核心,助力实时数据传输。文章详细阐述了利用Kafka进行数据采集,通过Delta Lake存储并导入数据,最终在Databricks上完成数据分析的全流程,展示了一套完整的实时数据处理方案。
66 3
|
3月前
|
消息中间件 Kafka 数据库
深入理解Kafka的数据一致性原理及其与传统数据库的对比
【8月更文挑战第24天】在分布式系统中,确保数据一致性至关重要。传统数据库利用ACID原则保障事务完整性;相比之下,Kafka作为高性能消息队列,采用副本机制与日志结构确保数据一致性。通过同步所有副本上的数据、维护消息顺序以及支持生产者的幂等性操作,Kafka在不牺牲性能的前提下实现了高可用性和数据可靠性。这些特性使Kafka成为处理大规模数据流的理想工具。
74 6
|
3月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
63 2
下一篇
无影云桌面