ToB企服应用市场:ToB评测及商务社交产业平台
标题:
Kafka消息存储核心架构计划及核心技术原理分析
[打印本页]
作者:
刘俊凯
时间:
5 天前
标题:
Kafka消息存储核心架构计划及核心技术原理分析
胡弦,视频号2023年度优秀创作者,互联网大厂P8技术专家,Spring Cloud Alibaba微服务架构实战派(上下册)和RocketMQ消息中间件实战派(上下册)的作者,资深架构师,技术负责人,极客时间训练营讲师,四维口袋KVP最具代价技术专家,技术范畴专家团成员,2021电子工业出版社年度优秀作者,获得2023电子工业出版技术成长领路人称号,荣获2024年电子工业出版社博文视点20周年荣誉专家称号,2024电子工业出版社年度优秀作者。
目次
1.概要计划
1.1 核心架构计划
1.1.1 组件概述
1.1.2 工作流程
1.2 核心技术原理
1.2.1 分区与副本机制
1.2.2 消息可靠传输
1.2.3 数据持久化
1.2.4 消耗者组与负载平衡
1.2.5 分区分配计谋
2.Kafka多副本机制架构计划
2.1 副本机制的根本概念
2.2 副本机制的工作原理
2.2.1 消息写入
2.2.2 消息读取
2.2.3 故障转移
2.3 ISR机制
2.4 副本机制的优势
2.5 副本机制的配置与调优
3.Kafka高可用架构计划
3.1 核心组件及功能
3.2 分区与副本机制
3.3 ISR与ACK计谋
3.4 故障转移与自动恢复
3.5 高可用架构计划的最佳实践
3.6 Kafka 2.8及以后的KRaft架构
4.Kafka的KRaft 集群管理架构计划
4.1 KRaft集群管理架构的核心组件
4.2 KRaft集群管理架构的工作原理
4.3 KRaft集群管理架构的优势
4.4 KRaft集群管理架构的部署和配置
Apache Kafka
是一种开源的分布式流处理平台,专为高性能、高吞吐量的实时数据处理而计划。以下是对
Kafka
消息存储核心架构计划及核心技术原理的分析。
1.概要计划
1.1 核心架构计划
1.1.1
组件概述
(1)Broker
:
Kafka
集群中的服务器,每个
Broker
存储一部门消息。
Kafka
集群通常由多个
Broker
组成,以提高可用性和负载平衡。
(2)Producer
:负责向
Kafka
发送消息的客户端。
Producer
可以选择将消息发送到特定的
Topic
和
Partition
。
(3)Consumer
:从
Kafka
中读取消息的客户端。
Consumer
可以组成消耗者组,以实现负载平衡和消息的顺序处理。
(4)Topic
:消息的分类,每个
Topic
可以有多个分区。
Topic
是
Kafka
中消息的逻辑概念,所有的消息都被发布到某个
Topic
下。
(5)Partition
:每个
Topic
下的分区,是消息的根本存储单位。
Partition
确保消息的顺序,并允许多个
Producer
和
Consumer
并行处理数据。
(6)Zookeeper
:用于管理
Kafka
集群的元数据,如
Broker
列表、分区信息等。
Zookeeper
负责协调各个
Broker
的状态和配置。
1.1.2
工作流程
(1)Producer发送消息
:Producer将消息发送到Kafka Broker,指定目的Topic。
(2)Broker存储消息
:Broker接收到消息后,将其存储在对应的Partition中,并将消息持久化到磁盘。
(3)Consumer读取消息
:Consumer从Broker中读取消息,指定要读取的Topic和偏移量。
1.2 核心技术原理
1.2.1
分区与副本机制
(1)分区(Partition)
:
Kafka
通过
Partition
将消息进行分区,每个
Partition
都是一个有序的、不可变的消息序列。
Partition
可以被分配到不同的
Broker
上,这样可以实现数据的分布式存储。通过
Partition
的机制,
Kafka
可以实现数据的并行处理和负载平衡。
(2)副本(Replica)
:每个
Partition
都可以设置多个副本,以提高容灾性。副本包括一个
Leader
和多个
Follower
。
Leader
负责处理所有的读写请求,
Follower
则从
Leader
复制数据。当
Leader
出现故障时,会从
Follower
中推举出新的
Leader
继承服务,从而包管了数据的高可用性和容错能力。
1.2.2
消息可靠传输
(1)ACK应答机制
:
Kafka
提供了三种
ACK
计谋来保障消息的可靠传输。
acks=0
:请求发送即以为乐成,常用于日记分析场景。
acks=1
:当
Leader
Partition
写入乐成即以为写入乐成,但有丢数据的可能。
acks=-1
:
ISR
列表中的所有副本都写入乐成才以为写入乐成,提供强可靠性包管。
(2)ISR(In-Sync Replicas)
:
Kafka
会为每个
Partition
维护一个
ISR
列表,只有在这个列表中的副本才能被以为是同步的。只有当所有
ISR
副本都写入乐成后,消息才会被以为已经提交。
1.2.3
数据持久化
(1)顺序写入与批量处理
:
Kafka
接纳顺序写入和批量处理技术,将多个消息批量发送,既节省带宽又提高了发送速度。
(2)日记文件与索引文件
:
Kafka
将每个
Partition
分为多个
Segment
,每个Segment包含一个日记文件和两个索引文件(.
index
和
timeindex
)。这种分段和索引机制使得Kafka可以或许高效地管理和检索消息。
(3)零拷贝技术
:
Kafka
使用零拷贝技术,提高了数据传输服从。
1.2.4
消耗者组与负载平衡
(1)消耗者组(Consumer Group)
:
Kafka
支持消耗者组的概念,消耗者组中的消耗者共同消耗一个
Topic
,
Kafka
会自动分配
Partition
给各个消耗者,实现负载平衡。
(2)重平衡机制
:当消耗者组中新增或删除一个消耗者时,
Kafka
会触发重平衡,重新分配
Partition
的所有权,以包管消息的负载平衡和容错性。
1.2.5
分区分配计谋
(1)默认分配计谋
:
Kafka
默认接纳哈希算法(
Hash
)进行
Partition
的分配,即根据消息的
Key
进行哈希盘算,然后将结果对
Partition
的数量取模,将消息分配到对应的
Partition
中。假如消息没有
Key
,则使用
Round-Robin
算法进行分配。
(2)自定义分配计谋
:
Kafka
还支持自定义的
Partition
分配计谋,以满足特定业务需求。
综上所述,
Kafka
通过其独特的架构计划、消息可靠传输机制、数据持久化计谋以及高性能实现方式,成为了分布式系统中不可或缺的消息中间件。
2.Kafka多副本机制架构计划
Kafka
的多副本机制是其确保数据高可靠性和高可用性的核心计划之一。以下是对
Kafka
多副本机制架构计划的具体分析。
2.1 副本机制的根本概念
(1)副本(Replica)
:在
Kafka
中,副本是指分布式系统对数据和服务提供的一种冗余方式。每个分区(
Partition
)可以有多个副本,这些副本分散存储在不同的
Broker
上,以实现数据的冗余和容错。
(2)领导者副本(Leader Replica)
:每个分区在创建时都会推举一个副本作为领导者副本,它负责处理该分区的所有读写请求。
(3)跟随者副本(Follower Replica)
:除了领导者副本外,其他副本都是跟随者副本。它们从领导者副本异步拉取消息,并写入到本身的提交日记中,以保持与领导者副本的数据一致。
2.2 副本机制的工作原理
2.2.1
消息写入
(1)
当生产者(
Producer
)发送消息到某个主题(
Topic
)时,消息首先会被发送到该主题对应分区的领导者副本。
(2)
领导者副本将消息写入到本身的提交日记中,并更新分区的高水位(
High Watermark
)。
(3)
跟随者副本从领导者副本异步拉取消息,并写入到本身的提交日记中。它们会定期向领导者副本发送心跳请求,以表明本身的存活状态。
2.2.2
消息读取
(1)
消耗者(
Consumer
)从领导者副本读取消息,它们通过向领导者副本发送读取请求来获取消息。
(2)
领导者副本会按照消息的偏移量(
Offset
)顺序返回消息给消耗者。
2.2.3
故障转移
(1)
当领导者副本出现故障时,
Kafka
会依托
ZooKeeper
提供的监控功能实时感知到这一变革。
(2)Kafka
会从跟随者副本中推举出一个新的领导者副本,继承处理该分区的读写请求。
(3)
旧的领导者副本恢复后,会自动作为跟随者副本加入到集群中。
2.3 ISR机制
(1)ISR(In-Sync Replicas)
:
ISR
是指与领导者副本保持同步状态的副本集合。只有当
ISR
中的所有副本都写入乐成后,消息才会被以为已经提交。
(2)Kafka
通过维护
ISR
集合来确保数据的一致性和可靠性。只有当
ISR
中的副本数量满足一定的条件时(通常要求
ISR
中的副本数量大于便是最小
ISR
副本数),
Kafka
才会以为该分区是可靠的。
(3)
假如某个跟随者副本落后领导者副本太多或出现故障,它会被从
ISR
集合中剔除。当该副本追上领导者副本或故障恢复后,它可能会被重新加入到
ISR
集合中。
2.4 副本机制的优势
(1)提高数据冗余
:通过多副本机制,
Kafka
实现了数据的冗余存储,即使某个
Broker
出现故障,数据也不会丢失。
(2)提高可用性
:当领导者副本出现故障时,
Kafka
可以或许自动从跟随者副本中推举出新的领导者副本,继承处理读写请求,从而包管了服务的高可用性。
(3)加强容错能力
:通过维护
ISR
集合和定期的心跳检测机制,
Kafka
可以或许及时发现并处理故障副本,加强了系统的容错能力。
2.5 副本机制的配置与调优
(1)副本因子(replication.factor)
:这是指每个分区配置的副本数量。副本因子越大,数据的冗余度越高,但也会增长写操作的耽误和存储本钱。
(2)最小ISR副本数(min.insync.replicas)
:这是指ISR集合中必须包含的副本数量。只有当ISR中的副本数量大于便是这个值时,Kafka才会以为该分区是可靠的。
(3)副本拉取耽误(replica.lag.time.max.ms)
:这是指跟随者副本落后领导者副本的最大时间间隔。假如跟随者副本落后领导者副本的时间凌驾了这个值,它可能会被从
ISR
集合中剔除。
在实际应用中,用户可以根据业务需求和数据规模来合理配置这些参数,以优化
Kafka
的性能和可靠性。
3.Kafka高可用架构计划
Kafka
的高可用架构计划旨在确保在集群中部门节点失效时,系统仍能提供稳定可靠的消息服务。以下是对
Kafka
高可用架构计划的具体分析。
3.1 核心组件及功能
(1)Producer(生产者)
:负责创建消息并发送到合适的
Broker
。
(2)Broker(服务实例)
:负责消息的持久化、中转等功能,是
Kafka
集群的核心节点。
Kafka
集群由多个
Broker
组成,每个
Broker
负责存储一定数量的分区。
(3)Consumer(消耗者)
:从
Broker
拉取消息并进行消耗,通常多个消耗者构成一个分组,消息只能被同组中的一个消耗者消耗。
(4)ZooKeeper(协调服务)
:负责管理和协调整个
Kafka
集群,包括
Broker
的元数据、主题的配置信息和消耗者组的状态信息。
Kafka
严重依赖于
ZooKeeper
集群来管理集群状态。
3.2 分区与副本机制
(1)分区(Partition)
:
Kafka
中的根本并行单位,每个主题(
Topic
)可以被分成多个分区,分布在不同的
Broker
上。分区确保了消息的顺序性,并允许多个
Producer
和
Consumer
并行处理数据。
(2)副本(Replica)
:为了提高数据的可靠性和容错性,每个分区可以配置多个副本。这些副本分布在不同的
Broker
上,此中一个副本被选为
Leader
,负责处理读写请求,其他副本作为
Follower
,从
Leader
复制数据。
3.3 ISR与ACK计谋
(1)ISR(In-Sync Replicas)
:与
Leader
副本保持同步的
Follower
副本集合。只有ISR中的副本才到场消息的提交和读取过程,以确保数据的一致性。
(2)ACK计谋
:
Kafka
提供了三种
ACK
计谋来保障消息的可靠传输:
acks=0
:生产者发送消息后不等待任何确认,消息可能丢失。
acks=1
:生产者等待
Leader
副本写入乐成后即以为消息发送乐成,但存在数据丢失的风险。
acks=all
:生产者等待
ISR
中的所有副本写入乐成后才以为消息发送乐成,提供最强的可靠性包管。
3.4 故障转移与自动恢复
(1)故障转移
:当
Leader
副本出现故障时,
Kafka
会自动从
ISR
中选择一个新的
Leader
副本,继承处理读写请求。这个过程由
ZooKeeper
和
Kafka
的自动领导推举机制共同实现。
(2)自动恢复
:新加入的
Broker
或恢复的
Broker
会从其他副本同步数据,确保数据的一致性。
3.5 高可用架构计划的最佳实践
(1)部署至少3个Broker
:以确保集群的高可用性和容错能力。
(2)合理配置分区和副本数
:分区数应根据数据量和消耗者实例数量进行调整,副本数至少为
3
以包管数据的高可用性。
(3)启用acks=all和min.insync.replicas >= 2
:以确保消息的可靠性,防止数据丢失。
(4)定期监控和备份数据
:使用
Kafka
自带的
JMX监
控和第三方监控工具来实时监控集群状态,并定期备份数据以防止劫难性故障。
(5)跨数据中央部署
:在不同的数据中央部署
Kafka
集群,实现容灾和备份。
3.6 Kafka 2.8及以后的KRaft架构
(1)KRaft协议
:
Kafka 2.8
引入了不依赖
ZooKeeper
的架构,通过新的
Raft
协议(
KRaft
)管理集群元数据。这种架构淘汰了
Kafka
对
ZooKeeper
的依赖,提高了系统的稳定性和可用性。
(2)选择使用
:用户部署
Kafka
集群时,可以选择继承使用
ZooKeeper
或倒霉用
ZooKeeper
而使用内嵌的
KRaft
。
综上所述,
Kafka
的高可用架构计划通太过区与副本机制、
ISR
与
ACK
计谋、故障转移与自动恢复等关键特性,确保了系统的高可用性和数据可靠性。同时,遵照最佳实践并定期监控和备份数据也是构建高可用
Kafka
集群的紧张步骤。
4.Kafka的
KRaft 集群管理架构计划
Kafka
的
KRaft
集群管理架构计划是一种旨在提高
Kafka
集群可靠性和可管理性的新架构模式,它取消了对
ZooKeeper
的依赖,通过内置的
KRaft
协议(基于
Raft
协议的一种实现)来管理集群的元数据和状态信息。以下是对
Kafka
的
KRaft
集群管理架构计划的具体分析。
4.1 KRaft集群管理架构的核心组件
(1)Controller节点
:在
KRaft
架构中,部门
Kafka Broke
r被指定为
Controller
节点,负责实行以前由
ZooKeeper
提供的共识服务,如推举领导者、管理集群状态等。
Controller
节点通常也是
Broker
节点,它们通过
Raft
协议进行通信和推举,以确保元数据的一致性和可用性。
(2)Raft协议
:
KRaft
架构使用Raft协议来管理集群的元数据和状态信息。
Raft
是一种用于管理复制日记的共识算法,它提供了强一致性包管,并允许集群在出现故障时自动恢复。
(3)元数据管理
:在
KRaft
架构中,所有的元数据(如分区信息、
Broker
信息、消耗者组信息等)都被存储在
Kafka
主题中,并通过
Raft
协议进行管理和同步。这消除了对
ZooKeeper
的依赖,并提高了系统的独立运行能力。
4.2 KRaft集群管理架构的工作原理
(1)Controller节点推举
:在
KRaft
架构中,
Controller
节点的推举是通过
Raft
协议自动完成的。当集群启动时,所有
Controller
节点都会到场推举过程,并最终推举出一个领导者(
Leader
)来负责处理集群的元数据更新请求。
(2)元数据更新
:当集群中的元数据发生变革时(如添加新的
Broker
、删除分区等),客户端会向
Leader Controller
节点发送更新请求。
Leader Controller
节点会将这些请求写入到复制日记中,并通过
Raft
协议将日记同步到所有
Follower Controller
节点。一旦大多数节点都确认了这些更改,它们就会被应用到集群的元数据中。
(3)故障转移和恢复
:假如
Leader Controller
节点出现故障,
Raft
协议会自动触发故障转移过程,从剩余的
Controller
节点中推举出一个新的领导者。这个过程是自动的,并且不需要人工干预。同时,由于所有的元数据都存储在Kafka主题中,并通过Raft协议进行同步,因此即使出现故障,数据也不会丢失,并且可以快速恢复。
4.3 KRaft集群管理架构的优势
(1)提高系统的独立运行能力
:由于取消了对
ZooKeeper
的依赖,
Kafka
集群可以独立运行,不再需要部署和维护额外的
ZooKeeper
集群。
(2)提高系统的可靠性和可用性
:
KRaft
架构使用
Raft
协议来管理集群的元数据和状态信息,提供了强一致性包管,并允许集群在出现故障时自动恢复。
(3)简化运维工作
:在
KRaft
架构中,所有的元数据都被存储在
Kafka
主题中,并通过
Raft
协议进行管理和同步。这消除了对
ZooKeeper
的依赖,并简化了运维工作。
(4)支持更大的集群规模
:由于取消了
ZooKeeper
的限制,
KRaft
架构可以支持更大的集群规模,包括更多的分区和
Broker
节点。
4.4 KRaft集群管理架构的部署和配置
(1)服务器规划
:部署
KRaft
集群时,需要规划好服务器的数量和配置。通常建议为
Controller
节点选择奇数个(如
3
或
5
个),以确保在出现故障时可以或许保持推举的多数性。
(2)配置文件
:在
KRaft
架构中,每个
Kafka
服务器都可以配置为仅作为
Broker
、仅作为
Controller
或同时作为
Broker
和
Controller
。这需要在配置文件(如
server.properties
)中设置相应的参数。
(3)天生集群UUID和格式化存储目次
:在部署
KRaft
集群时,需要为每个节点天生唯一的集群
UUID
,并格式化存储目次以确保它们与集群的
UUID
相匹配。
(4)启动和监控集群
:完成上述配置后,可以启动
Kafka
集群,并使用监控工具来实时监控集群的状态和性能。
总之,
Kafka
的
KRaft
集群管理架构计划通过内置的KRaft协议和Raft算法,实现了对集群元数据和状态信息的高效管理和同步,提高了系统的独立运行能力、可靠性和可用性,并简化了运维工作。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)
Powered by Discuz! X3.4