胡弦，视频号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 Broker被指定为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企服之家，中国第一个企服评测及商务社交产业平台。 |
