点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （已更完）
Kafka （正在更新…）
章节内容
上节我们完成的内容：
生产消费结构
Kafka 基本概念介绍
Kafka 消费模式
Kafka 核心API 介绍
Kafka 优势
Kafka 基本架构
核心概念
Kafka 的架构设计使其成为一个高吞吐量、低延迟、分布式的数据流处理平台。通过理解这些核心概念，可以更好地设计和实现基于 Kafka 的数据处理解决方案。Kafka 的分区、复制和消费模型提供了强大的扩展能力和可靠性，使得它在实时数据流处理、日志聚合、事件溯源等场景中得到了广泛的应用。
基本工作流程
Kafka 的基本工作流程如下：
生产者将消息发送到指定的主题，生产者可以指定消息的键，以决定消息进入哪个分区。
Broker接收消息并存储到对应的分区。Kafka 会根据分区策略将消息分布到不同的分区中。
消费者订阅主题，并从相应的分区中读取消息。消费者可以独立管理读取的偏移量，以保证消息处理的可靠性。
Producer
生产者创建消息。
该角色将消息发布到Kafka的Topic中，Broker接收到生产者的消息之后，Broker将消息追加到当前的 segment 文件中。
一般情况下，一个消息会被发布到一个特定的主题上：
默认情况下通过轮询把消息均衡的发布到主题的所有分区上
在某些情况下，生产者会把消息直接写到指定的分区，这通常是通过消息键和分区器来实现的，分区器为键的一个散列值，并将其映射到指定的分区上。这样可以保证同一个键的消息会被写到同一个分区上。
生产者也可以使用自定义分区器，根据不同的业务规则将消息映射到分区。
生产者是负责将数据发送到 Kafka 的组件。生产者可以是任何产生数据的应用程序，如日志记录系统、传感器、数据库变更日志等。Kafka 生产者以发布-订阅模式工作，将消息发送到一个或多个 Kafka 主题。
关键特性如下：
异步发送： 生产者可以以异步方式发送消息，允许继续处理其他任务而无需等待消息的发送结果。
分区策略： 生产者可以通过设置消息的键（Key）来控制消息的分区，这对于保证同一键的消息顺序处理非常重要。
确认机制（Acknowledgment）： 生产者可以设置不同的消息确认机制，如等待所有分区副本收到消息（acks=all）或只等待领导者副本确认（acks=1），以平衡性能和可靠性。
Consumer
消费者读取消息
消费者订阅一个或者多个主题，并按照消息生成顺序读取它们
消费者通过检查消息偏移量来区分已经读过的消息，偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在ZooKeeper或Kafka上。
消费者是消费组的一部分，群组保证每个分区只能被同一个消费者使用。
如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新消费。
消费者是从 Kafka 主题中读取消息的组件。消费者通常被组织在消费者组中，以便多个消费者可以协同处理来自同一主题的消息。每个消费者组内的消费者分摊处理不同的分区，从而提高了系统的吞吐量和可扩展性。
关键特性如下：
消费者组： 每个消费者组内的消费者从主题的不同分区中读取消息。同一分区的消息不会被同一消费者组内的多个消费者处理，但可以被-不同的消费者组处理。
手动或自动提交偏移量： 消费者可以手动或自动提交消息的偏移量（Offset），以确保在故障恢复时能够从正确的位置重新开始读取。
Broker
一个独立的Kafka服务器称为Broker
如果某Topic有N个Partition，集群有N个Broker，每个Broker存储该Topic的一个Partition
如果某Topic有N个Partition，集群有（N+M）个Broker，那么其中有N个Broker存储该Topic的一个Partition
如果某Topic有N个Partition，集群中Broker数目少于N个，那么一个Broker存储该Topic的一个或多个Partition。在实际的生产环境中，尽量避免这种情况的发生，这种情况很容易导致Kafka集群数据不平衡。
Broker 是 Kafka 集群中的一个实例，它负责接收生产者发送的消息，将其存储到磁盘，并为消费者提供数据。一个 Kafka 集群通常由多个 Broker 组成，每个 Broker 负责管理一部分分区。
关键特性如下：
分布式架构： 多个 Broker 共同工作以实现数据的存储和处理。Kafka 集群通过分区和复制来实现数据的高可用性和可靠性。
Leader 和 Follower： 每个分区都有一个领导者（Leader）和多个跟随者（Follower）。生产者和消费者都与分区的领导者进行交互，而跟随者负责复制数据，以提供冗余。
Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
物理上不同的Topic的消息分开存储
主题就好比数据库的表，尤其是分库分表之后的逻辑表。
主题是 Kafka 中用于存储和分类消息的逻辑通道。每个主题可以有多个分区，消息在分区内是有序的，但在不同的分区之间可能是无序的。
关键特性如下：
多订阅者支持： 多个消费者组可以同时订阅同一个主题，并且每个组都可以独立处理主题中的消息。
数据保留策略： 主题中的数据可以基于时间或大小来配置保留策略，Kafka 会自动删除旧的数据，以释放存储空间。
Partition
主题可以被分为若干个分区，一个分区就是一个提交日志
消息以追加的方式写入分区，然后以先入先出的顺序读取
无法在整个主题范围内保证消息的有序，但可以保证消息在单个分区内的顺序
Kafka通过分区来实现数据冗余和伸缩性
在需要严格保证消息的顺序的场景下，需要将Partition数目设置为1
分区是主题的物理分片，每个分区在磁盘上存储一部分消息。分区允许 Kafka 将数据分散在集群中的多个 Broker 上，从而实现横向扩展。
关键特性如下：
顺序性保证： 在一个分区内，消息是有序的。这对于需要按顺序处理数据的应用场景非常重要。
并行处理： 不同分区的消息可以被不同的消费者并行处理，从而提高吞吐量。
Replicas
Kafka使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本，那些副本被保存在Broker上，每个Broker可以保存成百上千属于不同主题和分区的副本。
副本有以下的两种类型：
首领副本：每个分区都有一个首领副本，为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。
跟随者副本：首领以外的副本都是跟随副本，跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那里复制消息，保持与首领一致的状态。如果首领发生奔溃，其中一个跟随者就会被提升为新首领。
Offset
生产者
消息写入的时候，每一个分区都有一个Offset，这个Offset就是生产者的Offset，同时也是这个分区的最新最大的Offset。
有些时候没有指定某一个分区的Offset，这个工作Kafka帮我们完成。
偏移量是 Kafka 中每条消息在分区内的唯一标识符。消费者通过维护偏移量来跟踪它们已经读取的消息位置。
关键特性如下：
持久化： 偏移量可以由 Kafka 自动管理，也可以由消费者手动提交到 Kafka，确保在故障恢复时能够从正确的位置继续处理。
按需读取： 消费者可以随时指定从某个偏移量开始读取数据，从而支持数据的回溯性处理。
消费者
这是某个分区的Offset情况，生产者写入的Offset是最新最大值12，当ConsumerA进行消费时，从0开始消费，一直消费到9，消费者的Offset就记录9，ConsumerB就记录在11。
等下一次消费的时候，他们可以选择从上一次消费的位置消费，也可以从头开始消费。
副本相关
副本类型
Kafka通过副本来保证高可用，副本分为：首领副本（Leader）和追随者副本（Follower）。
Leader 副本：每个分区都有一个 Leader 副本。Leader 副本负责处理所有对该分区的读写请求。也就是说，当生产者（Producer）发送消息到 Kafka 时，这些消息首先被写入 Leader 副本；当消费者（Consumer）从 Kafka 读取消息时，它们从 Leader 副本中获取数据。
Follower 副本：除了 Leader 副本外，分区还可以有一个或多个 Follower 副本。Follower 副本不处理读写请求，而是被动地从 Leader 副本复制数据，保持与 Leader 的数据一致性。如果 Leader 副本所在的 Broker 出现故障，Kafka 会从剩下的 Follower 副本中选择一个新的 Leader，继续处理请求。
工作机制
同步复制：Follower 副本会以同步的方式从 Leader 副本中拉取数据，确保所有副本数据一致。当数据被写入 Leader 副本时，Kafka 会等待至少一个 Follower 副本成功复制数据后，才确认写入操作完成。
副本分配：Kafka 在创建主题（Topic）时，可以配置分区的副本数量（replication factor）。副本分配策略会尽可能将副本分布在不同的 Broker 上，以减少单点故障的风险。
副本优势
高可用性：由于 Kafka 允许每个分区有多个副本，即使某个 Broker 失效，只要其他 Broker 上有有效的副本，Kafka 仍能继续提供服务。
容错性：Kafka 的副本机制能够有效防止数据丢失。在 Broker 失效时，可以快速切换 Leader 副本，确保数据的持续可用性。
副本管理
ISR（In-Sync Replica）集合：这是一个关键的概念，指当前与 Leader 副本保持同步的所有副本的集合。如果某个 Follower 副本在特定时间内未能跟上 Leader 的步伐，它将被暂时从 ISR 集合中移除。
Leader 选举：当现有的 Leader 副本失效时，Kafka 会从 ISR 集合中选择一个新的 Leader，确保服务的连续性。
