【kafka】记录用-----------1

在这里插入图片描述

主题（topic）：消息的第一次分类
- 根据人为的划分条件将消息分成不同的主题
  - 主题的划分是人为的根据不同的任务情景去划分
    - 比如，我们有两个主题，一个是"订单"，另一个是"库存"。每个主题代表一个消息流。
  - 主题的名称作为主题的为一标识符，我们需要保证其唯一性
分区（partition）：消息的第二次分类
- 区域化同主题中的消息：分区管理同主题的消息
  - 不同主题下分区标识可以相同
  - 每个分区都有一个唯一的标识
分区偏移（partition offset）:消息的第三次分类
- 同一分区内的不同消息都有唯一的偏移
  - 消息的偏移值是唯一且按照顺序递增的。kafka分配消息时确定
- 不同分区内的消息的偏移可以相同

🫱🏽 kafka分区策略

默认分区策略（DefaultPartitioner）： 如果消息没有指定 key，或者指定的 key 为 null，那么默认分区策略会采用轮询（round-robin）的方式将消息均匀地分配到所有可用分区。
基于 key 的分区策略（PartitionByKey）： 如果消息指定了 key，那么基于 key 的分区策略会根据 key 的哈希值将消息分配到对应的分区。这确保具有相同 key 的消息总是被分配到同一个分区，以保证消息的顺序性。
自定义分区策略： 用户可以根据自己的需求实现自定义的分区策略。这可以通过实现 Kafka 提供的 Partitioner 接口来完成。

分区备份（replicas of partition）：分区的备份，用于防止数据丢失。
- 备份时机
  - 消息写入
  - 消费者拉取
  - 后台任务

🫱🏽 kafka后台同步策略

后台同步任务是 Kafka 内部自动管理的，不需要人为干预。Kafka 设计了一些后台任务来确保副本之间的同步和数据的一致性，以提高整个系统的可用性和可靠性。

这些后台同步任务包括：

Leader 的心跳检测： Kafka 集群中的每个分区都有一个领导者（Leader），领导者会定期发送心跳消息给追随者（Followers）。这有助于检测领导者的健康状态。
追随者的数据拉取： 追随者会定期从领导者拉取缺失的数据，以保持与领导者的同步。这有助于处理因追随者滞后或宕机而导致的数据不一致。
Leader 的日志清理： 领导者会定期清理旧的日志段，删除过时的消息。这确保了存储在磁盘上的数据不会无限增长，也有助于提高性能。

经纪人（Brokers）:负责维护发布数据的系统，每个代理可以管理一个或多个主题的分区。
- 同一主题下可能有1-n 经纪人
- 同一分区任意时刻只能由一个经纪人管理
- 经纪人的分配区域管理
  - 一个主题和N个代理中有N个分区，每个代理将有一个分区。
  - 一个主题中有N个分区并且多于N个代理(n + m)，则第一个N代理将具有一个分区，并且下一个M代理将不具有用于该特定主题的任何分区。
  - 一个主题中有N个分区并且小于N个代理(n-m)，每个代理将在它们之间具有一个或多个分区共享。由于代理之间的负载分布不相等，不推荐使用此方案

领导者（Leader）：负责处理该分区的读写请求

职责：

消息追加到分区的日志文件，这确保了分区的写入顺序
- 不同分区的消息顺序不做保证
- 同一分区下的消息顺序是根据消息的写入的先后顺序有序存储

消息的复制和同步：

消息异步地复制到追随者（Followers）

步骤	详细过程	举例（假设分区有3个追随者，需要2个确认）
初始状态：	一个分区有一个领导者和多个追随者。领导者和追随者的副本都在 ISR 中，表示它们与领导者同步。
生产者写入消息：	生产者产生一条新消息并发送给领导者。领导者接收到消息后，将消息追加到分区的日志文件。	生产者发送消息A，领导者将A追加到日志。
消息异步复制到追随者：	领导者开始异步地将写入的消息复制到追随者。追随者接收到领导者的复制请求，将消息追加到它们的日志文件中。	追随者1、追随者2接收A并将A追加到各自日志。
等待 ISR 中的确认：	尽管消息复制是异步进行的，领导者必须等待 ISR 中的一定数量的追随者确认已成功复制。	等待追随者1、追随者2确认。两者是异步的。
	如果 ISR 中的足够数量的追随者确认成功复制，领导者将响应给生产者，表示消息已成功写入。	追随者1、追随者2确认，领导者响应。
消息的持久性和有序性：	由于消息已成功写入 ISR 中的足够数量的追随者，可以确保消息的持久性。	消息A被持久化，即使领导者宕机，ISR 中的副本可以被选为新的领导者，从而保证消息的持久性。
	由于等待 ISR 中的追随者确认，保证了消息的有序性。领导者会按照消息写入的顺序等待确认，以确保整个分区的消息顺序性。	领导者需要等待一定数量的追随者确认后才能继续处理下一条消息。这确保了消息在分区内的有序存储。

追随者的管理
- 心跳机制：检测追随者状态（在线、宕机、滞后）
  - 在线（心跳表现 | ISR中）
    - 追随者定期发送心跳消息，表示自己在线
    - 如果追随者的心跳正常，领导者将其包含在 ISR 中，表示它是同步的。
  - 宕机（心跳表现 | ISR中）
    - 领导者在一定时间内没有受到心跳信息，无法确认追随者的在线状态
    - 领导者可能将宕机的追随者移出 ISR，等待其他追随者的确认。
  - 滞后（心跳表现 | ISR中）
    - 追随者仍定期发送心跳消息，但在处理消息上存在滞后。
    - 领导者可能将滞后太多的追随者移出 ISR，以确保 ISR 中的副本是相对同步的。
    滞后主要指的是追随者在处理消息时相对于领导者的位置较远，即它的日志文件中的消息相对较旧。这是通过追随者的日志文件中的偏移量（offset）来衡量的。
读操作的响应
- 领导者负责处理来自消费者的读取请求。
  - 消费者可以从领导者或者任意一个追随者拉取消息。领导者负责返回正确的消息，确保读取操作的正确性。
故障转移
- 如果领导者宕机或者发生故障，Kafka 集群会自动进行领导者选举。新的领导者将被选举出来，确保分区的可用性。这是通过使用 ZooKeeper 进行协调的。
日志清理
- 领导者定期进行日志清理，删除过时的日志段，以释放磁盘空间。这有助于保持存储的合理大小