Kafka（Apache Kafka） 是一种分布式流数据平台，最初由LinkedIn开发，并于后来捐赠给Apache软件基金会，成为了一个Apache顶级项目。它被设计用于处理大规模、实时的数据流，并为构建高吞吐量、容错性强的数据流应用程序提供支持。Kafka的特点使得它在日志收集、实时处理、事件驱动架构、监控等领域得到广泛应用。

以下是Kafka的一些关键特点和概念：

1. 发布-订阅模型： Kafka采用发布-订阅模型。数据生产者将数据发布到称为“主题（Topics）”的逻辑通道中，而消费者可以订阅这些主题以读取数据。
2. 分布式架构： Kafka是一个分布式系统，允许横向扩展以应对大量数据。它将数据分布在多个服务器节点上，实现高吞吐量和高可用性。
3. 持久性： Kafka可以将数据持久化到磁盘上，确保即使在数据被消费后，仍然保留数据，以便进行后续的分析和处理。
4. 分区： 主题可以分为多个分区，每个分区是消息的有序序列。分区允许数据水平扩展和并行处理。
5. 复制： Kafka支持将分区的副本分布在不同的节点上，提供数据冗余和容错性。
6. 高性能： Kafka的设计优化使得它能够处理高吞吐量的数据流，适用于实时数据处理需求。
7. 流式处理： Kafka可用于构建流式处理应用程序，可以实时地处理和分析数据流。
8. 生态系统： Kafka的周边生态系统丰富，包括流处理框架（如Apache Flink、Spark Streaming）、数据存储系统（如Hadoop、Cassandra）等。

总的来说，Kafka在大数据、实时处理和数据流领域具有重要地位，其强大的分布式架构和丰富的功能使其成为许多企业处理实时数据的首选平台。

Kafka是一个非常灵活和功能强大的分布式流数据平台，适用于多种业务场景。以下是一些Kafka常见的用途和业务场景：

1. 日志和事件流处理： Kafka在日志收集和事件流处理方面表现出色。它可以收集分布在不同系统和应用程序中的日志和事件数据，供后续分析、监控和故障排除使用。
2. 实时数据分析： Kafka可用于构建实时数据分析系统，将数据从不同源传输到分析平台，使得企业能够实时了解业务状况，进行实时的数据挖掘和洞察。
3. 指标和监控： Kafka能够收集和传输系统指标和监控数据，用于监测应用程序和基础设施的性能，支持实时的告警和反应。
4. 事件驱动架构： Kafka的发布-订阅模型使得它非常适合实现事件驱动的架构。各个微服务或组件可以通过Kafka传递事件和消息，实现解耦和高度可扩展的系统。
5. 流式处理： Kafka可用于构建流式处理应用程序，实时地处理和分析数据流。流处理框架（如Flink、Spark Streaming）与Kafka结合，可以进行复杂的实时数据处理。
6. 数据管道和ETL： Kafka可以作为数据管道，将数据从源传输到目标，支持ETL（Extract, Transform, Load）过程。这对于数据仓库、数据湖等大数据方案非常有用。
7. 实时推送： Kafka可以用于实现实时推送服务，如新闻订阅、实时聊天等。数据更新后即时将信息传递给订阅者。
8. 物联网（IoT）数据处理： 对于物联网应用，Kafka可以接收和处理大量的设备数据，使得数据从边缘设备传输到后端分析和存储系统。
9. 数据解耦和削峰填谷： Kafka可以将数据生产者和消费者解耦，允许异步处理和降低系统之间的耦合性。同时，Kafka还可以平滑地处理数据流量的峰值和波动。

哪些行业都在用kafka：

• 实时处理支付和金融交易，例如在证券交易所、银行和保险中。
• 实时跟踪和监控汽车、卡车、车队和货运，例如物流和汽车行业。
• 持续捕获和分析来自物联网设备或其他设备（例如工厂和风电场）的传感器数据。
• 收集客户互动和订单并立即做出反应，例如零售、酒店和旅游业以及移动应用程序。
• 监测医院护理中的患者并预测病情变化，以确保在紧急情况下及时得到治疗。
• 连接、存储并提供公司不同部门生成的数据。
• 作为数据平台、事件驱动架构和微服务的基础。

• broker: kafka节点, 就是安装的每一个kafka服务

• producer: 生产者, 发消息的

• consumer: 消费者, 读消息的

• zookeeper: 信息中心, 记录kafka的各种信息的地方

• controller: 其中的一个broker, 作为leader身份来负责管理整个集群. 如果挂掉, 借助zk进行重新选主

4.1 topic & partition

• topic: 主题, 一个消息的通道, 收发消息总得知道消息往哪里投送
• partition: 分区, 每个主题可以有多个分区 分担数据的传递, 多条路并行, 提高吞吐量
• consumer group: 消费组, 消费者监听topic时可以指定group
  • 通常建议保持同一组内的消费者的数量等于或小于分区的数量, 因为每个分区只能被一个消费者组内的一个消费者消费
  • 如果消费者的数量大于分区的数量，一些消费者将会是空闲的，无法获得分区来消费，导致资源浪费.
  • 当然也可以保证 消费者数量 = 分区数量 + 1, 这样可以保证 当有消费者宕机后, kafka消费者组协调器会找出空闲的消费者并重新分配已失效消费者的分区并继续消费

4.2 replicas

• replicas: 副本, 每个分区可以设置多个副本, 副本之间数据一致. 相当于备份, 提高数据可靠性(如下图)
• replicas: leader & follower: 副本中有一个身份为leader, 其他均为follower. leader处理所有的读和写请求, follower只负责数据备份, 如果主分区挂了, follower会顶上来

副本分类:

• AR（Assigned Replicas） 是指为每个分区分配的副本集合。在Kafka中，每个分区可以有多个副本，其中一个副本被选举为leader，其他副本为follower。AR是指包括leader副本在内的所有副本的集合。

• ISR（In-Sync Replicas）： ISR是指与主副本保持同步的副本集合。在Kafka中，一个主题分区通常有多个副本，但只有与主副本保持同步的副本才能被认为是ISR中的成员。在正常情况下，ISR中的所有副本都已经同步了高水位之前的消息，因此可以确保消息的一致性和可靠性。

• OSR（Out-of-Sync Replicas）： OSR指的是已经落后于主副本的副本。这些副本的同步进度较慢，可能由于网络延迟或其他原因。当副本变得不再与主副本同步时，它将被移出ISR。这是为了确保ISR中的副本始终保持高水位之前消息的同步状态。

  这些概念在Kafka中用于管理副本的分配和同步，以确保数据的可靠性和一致性。

AR = ISR + OSR

• offset：偏移量(索引)，消息消费的具体位置，每个消费者都有自己的偏移量

• HW（High Watermark）： 高水位是一个标记，表示已被确认和提交的消息的位置。HW之前的所有消息都被认为是已经被处理并且已经提交的。在消费者的视角中，只有高水位之后的消息是尚未被处理的。高水位只记录在ISR（In-Sync Replicas）中，用于确保消息的一致性和可见性。在一组ISR中，每个Follower同步消息的速度可能不同，HW指向的始终是所有ISR中最慢的消息位置。

• LEO（Log End Offset）： 日志末尾偏移量是一个指示，表示当前分区的下一条消息的偏移量。LEO是分区中所有副本中最大的偏移量，包括ISR和OSR（Out-of-Sync Replicas）中的副本。LEO指示了分区中尚未被消费的消息的位置。

总结一下，HW是已被确认和提交的消息的位置，用于消息的一致性和可见性。LEO是分区中下一条消息的偏移量，用于指示尚未被消费的消息的位置。这两个偏移量在Kafka中起到了重要的作用，影响了消息的处理和消费。

那么这三者有什么关系呢?

比如在副本数等于3的情况下，消息发送到Leader A之后会更新LEO的值，Follower B和Follower C也会 实时拉取Leader A中的消息来更新自己，HW就表示A、B、C三者同时达到的日志位移，也就是A、B、 C三者中LEO最小的那个值。由于B、C拉取A消息之间延时问题，所以HW一般会小于LEO，即 LEO>=HW。

kafka每个主题可以有多个分区, 每个分区在它所在的broker上创建一个文件夹, 每个分区又分为多个段（Segment 相当于把海量消息拆分到了多个文件中, 防止消息文件过大导致检索速度缓慢）, 每个段两个文件 log & index, log文件里顺序存消息, index文件里存消息的索引 段的命名直接以当前段的第一条消息的offset为名

日志（Log）： Kafka使用日志来持久化存储消息，每个分区都有一个对应的日志。日志是一个有序的、不可变的消息序列。每当有新的消息到达，它们会被追加到分区的日志末尾，形成一个逐渐增长的日志段（Log Segment）。每个日志段都有一个固定的大小，一旦达到大小限制，就会被关闭并创建新的日志段。

日志的追加操作是高效的，因为它只需要将新的消息附加到日志段的末尾，不需要移动现有数据。由于日志是不可变的，一旦消息被写入，就不能更改或删除。这种特性使得Kafka的数据持久性和不变性得到了保证。

消息索引（Index）： 消息索引是一个用于加速消息查找的关键组件。每个日志段都有一个对应的消息索引，它存储了一些重要的消息偏移量和物理偏移量的映射关系。索引使得Kafka能够快速定位特定偏移量的消息，而不需要逐个扫描整个日志。

消息索引通常存储在内存中，它分为两部分：内存索引和磁盘索引。内存索引包含了一部分消息偏移量和其在日志中的物理位置的映射，它使得最常见的消息查找可以在内存中完成，非常快速。磁盘索引包含了完整的索引信息，它使得整个索引数据不需要全部加载到内存中，而是按需加载，节省了内存空间。

通过消息索引，Kafka可以迅速定位消息，以便进行消费、回溯和处理。这对于支持高吞吐量的数据处理和实时消费非常重要。

6.1 索引定位

Consumer获取offset = 6的Message

1. 通过请求的offset就能判断出消息在00000000000000000000的分段中
2. 通过00000000000000000000.index中找到offset = 6的Position值
3. 到00000000000000000000.log中直接找到字节偏移量为150的位置开始读取消息
4. 直到读取到下条消息的开始位置, 即当前消息读取完毕, 返回消息给Consumer

6.2 存储分段策略

1. 日志大小限制(默认策略 1GB)： Kafka的日志段有一个预先设定的大小，通常是以字节为单位的数值（例如1GB）。一旦一个日志段的大小达到了这个限制，它会被关闭，并创建一个新的日志段来接收新的消息。
2. 时间限制： 另一种分段策略是基于时间的。Kafka允许设置一个日志段的最大存活时间，即使这个日志段没有达到大小限制，如果超过了指定的时间，它也会被关闭。这有助于清理过期的数据，以防止过多的历史数据堆积。

6.3 日志删除策略

1. 基于日志段大小的删除： 当一个日志段的大小达到预设的阈值（segment.bytes参数配置的大小）时，这个日志段会被关闭并被认为是"不活跃的"。不活跃的日志段会在不影响正在进行的写入的情况下，被删除。这样，旧的消息将会被清除，释放磁盘空间。
2. 基于日志段保留时间的删除： 每个日志段都有一个保留时间限制，称为segment.ms参数。当一个日志段被关闭后，如果它的创建时间超过了这个保留时间，它将会被删除。这样可以确保不再需要的旧数据会被及时清理。
3. 基于消息保留时间的删除： 每个主题可以设置一个保留时间，称为retention.ms参数。如果一个主题被设置了保留时间，并且消息的时间戳早于这个保留时间，那么这些消息将会被删除。这个策略确保了主题中不再需要的消息会被自动清理。
4. 基于消息压缩的删除（Log Compaction）： 如果启用了消息压缩（通过cleanup.policy参数设置为compact），Kafka会保留每个键的最新消息，而旧的消息将被删除。这个策略保留了每个键的最新状态，适用于存储状态信息。
5. 删除策略的联合使用： 您可以同时使用多种删除策略，根据不同的主题和需求来管理存储。例如，某些主题可以采用基于时间的保留策略，而其他主题可以采用基于消息大小的策略。

在Kafka中，删除策略的最小单位是日志段（Log Segment）。当满足某个删除条件时，Kafka会删除整个不再需要的日志段，包括其中的消息数据和对应的索引数据。