kafka入门

定义

是一种高吞吐量的分布式发布订阅消息系统。由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。

目的

通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时消息。

特点

  1. 高吞吐量：可满足每秒百万级别的消息的生产和消费。
  2. 持久性：具备一套完整的消息的存储机制，可以确保消息数据的高效的安全的持久化。
  3. 分布式：既有扩展以及容错性。

相关术语

生产者（Producer)

消息生产者，负责把产生的消息发送到Broker（kafka服务器）。

消费者（Consumer）

消息消费者，从Broker（kafka服务器）读取消息并处理。

消费者群组（Consumer Group）

消费者群组，一个消费者群组可以包含一个或多个消费者，每个消费者属于一个特定的消费者群组，一条消息可以被多个不同的消费者群组消费，但是一个消费者群组中只能有一个消费者能够消费该消息，同一消费者组中的消费者不会重复消费消息。

主题（Topic）

消息主题，即消息的分类，kafka的数据保存在topic中，每个broker可以创建多个 topic ，一个kafka集群可以有多个topic。

kafka节点（Broker）

消息中间件处理节点，一个kafka节点就是一个broker，一个kafka集群有由多个broker组成，一个broker可以创建多个topic，一个broker可以容纳多个topic的多个 partition。

分区（Partition）

topic的分区，每个topic可以有多个分区，每个分区内部消息是有序的。

偏移量（Offset）
  1. 介绍：偏移量是消息在每个分区中的唯一标识符，用于标识消息在分区中的位置，是一个单调递增的64位整数，每个分区的偏移量从0开始，随着消息的写入线性增加。（不同分区的偏移量没有直接关系，偏移量只在分区内有意义）
  2. 作用：
  • 消息位置跟踪：消费者通过记录已消费消息的偏移量来跟踪消费进度。
当消费者读取消息后，会提交当前的偏移量（如offset=100）。
下次重启时，消费者会从上次提交的偏移量继续消费（从offset=101开始）。
  • 消息顺序保证
同一分区内，消息按偏移量顺序存储，消费者按顺序读取。
但不同分区之间的消息无法保证全局顺序（除非只用一个分区）
  • 消费重放：通过重置偏移量，消费者可以重新消费历史消息。
  • 消息保留策略：Kafka 根据偏移量和保留时间（如 7 天）决定何时删除旧消息。
  1. 偏移量管理方式：

消费者通过自动提交或手动提交偏移量来控制消费进度：

  • 自动提交：消费者定期自动提交当前偏移量（默认 5 秒）。
    • 优点：简单易用。
    • 缺点：可能导致重复消费（如提交后但处理未完成时重启）。
  • 手动提交：开发者在消息处理完成后手动提交偏移量。（有同步和异步两种方式手动提交）
    • 优点：精确控制消费进度，避免重复消费。
    • 缺点：需处理异常情况（如提交失败）。
  1. 偏移量重置策略：
  • earliest：从分区起始位置（最小偏移量）开始消费，即从分区最早的消息开始消费。
  • latest（默认）：从分区末尾（最新偏移量）开始消费，即只消费新到达的消息。
  • none：若没有已提交的偏移量，则抛出异常。
副本因子（replicationFactor）

指每个分区的副本数量。它决定了每一条消息会被复制到多少个不同的Broke节点上，从而实现数据冗余和高可用性。

  • replicationFactor = 1：每个分区只有 1 个副本（即 Leader 本身），没有冗余。如果该 Broker 故障，数据将不可用。
  • replicationFactor = 3：每个分区会有 3 个副本，分布在 3 个不同的 Broker 上。此时系统可容忍2 个 Broker 同时故障（只要至少 1 个副本存活，数据就不会丢失）。

replicationFactor越大，系统容错能力越强，但副本数量越多同样会增加网络传输和磁盘IO开销，并且可能导致选举延迟变成，建议生产环境设置为 3。

replicationFactor数量不能超过Broke数量，例如集群有 3 个 Broker，replicationFactor最大只能设为 3，否则会有副本无法分配。

副本机制

  1. 副本概念：副本就是对分区的备份。
  2. 副本机制概念：同一个分区下的所有副本保存有相同的消息序列，这些副本分散保存在不同的Broker上，从而能够对抗部分 Broker 宕机带来的数据不可用。
  3. 副本类型：
  • 首领副本（Leader）：每个分区都有一个Leader副本，生产者请求和消费者请求都会经过这个副本，生产者写操作和消费者的读操作都发生在Leader上，同时Leader负责把数据同步给Follow。
  • 跟随者副本（Follow）：首领以外的副本都是跟随者副本。它们的主要任务是接收Leader的同步数据，保持与Leader一致的状态。如果首领发生崩溃，那么其中的一个跟随者就会被提拔为新首领。

Kafka 默认副本 1 个，生产环境一般配置为 2 个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。

Kafka 中副本分为： Leader 和 Follower。 Kafka 生产者只会把数据发往 Leader，然后 Follower 找 Leader 进行同步数据。

ISR机制

  1. 概念：在 Kafka 的分区副本机制中，每个分区有一个 Leader 副本和多个 Follower 副本，而 ISR 就是由 Leader 副本和所有与 Leader 保持同步的 Follower 副本组成的集合。
  2. 作用：通过动态维护一个与Leader副本保持同步的Follower副本集合，确保在Leader发生故障的时候，系统可以从同步副本列表中快速选出新的Leader，避免数据丢失。实现高可用性和数据一致性。
  3. Kafka根据副本同步的情况，分成3个集合。
  • AR：被分配到某个分区的副本集合，Kafka 分区中的所有副本统称为 AR，AR包括ISR和OSR。
  • ISR：表示和Leader副本保持同步的Follower副本集合。 如果 Follower 长时间未向 Leader 发送通信请求或同步数据，则该 Follower 将被踢出 ISR。
    该时间阈值由 replica.lag.time.max.ms参数设定，默认 30s。 Leader 发生故障之后，就会从 ISR 中选举新的 Leader。
  • OSR：未能与Leader副本保持同步的副本（即不在ISR中的副本），例如由于网络延迟、宕机或者IO问题，Follow可能被移除ISR，进入OR。

副本同步机制介绍

  1. 介绍：Follow副本定期从Leader副本拉取数据并更新日志的过程。
  2. 副本同步的作用：确保副本之间的数据一致性。通过将消息从Leader副本同步到Follow副本，可以确保这些副本之间的数据保持一致。此外，副本同步还可以用于实现数据的高可用性。当Leadedr副本发生故障时，可以从Follow副本中选择一个作为新的Leader副本，从而避免服务中断。
  3. 副本同步的实现原理：
  • Follow副本定期向Leader副本发送拉取请求（FetchRequest），请求包括Follow副本已经同步的最大偏移量（maxOffset）。
  • Leader副本收到拉取请求后，根据Follow副本的最大偏移量返回对应的消息。
  • Follow副本收到Leader副本返回的消息后，将消息写入本地日志，并更新最大偏移量。

在副本同步过程中，Follow副本需要定期向Leader副本发送心跳，以维持与Leader副本的连接。如果Follow副本与Leader副本的连接中断，或者同步延迟超过一定阈值，Follow副本会被移出 ISR（In-Sync Replicas）。

生产者发送确认三种模式（ACK机制）

ACK机制概念：确认机制，指生产者在发送消息后，需要等待Broker的确认信号，以确保消息成功发送。这种机制的主要目的是保证消息的可靠性，防止因网络问题或Broker故障导致消息丢失。

Kafka 在生产者上有一个可选的参数 ack，该参数指定了必须要有多少个分区副本收到消息，生产者才会认为消息写入成功，配置值如下所示：

  1. acks=0
  • 含义：生产者发送消息后不需要等待任何确认，直接继续发送下一条消息。
  • 优缺点：消息发送吞吐量高，但可靠性低，生产者无法知道消息是否成功到达 Kafka 服务器，可能导致消息丢失。
  • 适用场景：日志数据采集。
  1. acks=1
  • 含义：生产者发送消息后，只要等待集群的首领节点（leader）收到消息，生产者就会得到确认，而不需要等待其它副本。
  • 优缺点：可靠性和吞吐量较高，但也存在消息丢失的可能性，例如Leader副本将消息同步给Follow副本时Leader发送故障。
  • 适用场景：实时监控数据的传输。
  1. acks=all 或 acks=-1
  • 含义：生产者发送消息后，需要等待所有ISR（In-Sync Replicas）副本都成功接收并确认消息后才会收到确认信号。
  • 优缺点：可靠性最高，但会增加延迟，降低吞吐量。
  • 适用场景：金融交易数据的传输。

Kafka生产者在发送消息后，如果设置了等待服务器的确认(通过acks参数配置)，会等待一定时间来收到来自服务器的确认(ack)。这个等待时间由timeout.ms参数控制，默认是10000毫秒（10秒)。如果在等待时间内没有收到服务器的确认，生产者可以选择重试发送或者处理发送失败的逻辑。这取决于生产者的配置。通常，生产者会根据配置的重试次数和重试间隔来进行重试，以确保消息最终被成功发送。

在Kafka 的生产者配置中，你可以找到以下与重试相关的配置项:

  • retries：定义了生产者在发送消息时的最大重试次数。
  • retry.backoff.ms：定义了两次重试之间的等待时间间隔。

优点

  1. 高吞吐量：支持每秒百万级消息处理。
  2. 低延迟：最低延迟只有几毫秒。
  3. 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。
  4. 容错性高：允许集群中节点失败，当集群中的某个节点失效时，生产者和消费者可以自动重定向到其他可用节点，确保消息的连续性。（若副本数量为n,则允许n-1个节点失败）。
  5. 可扩展性：可增加节点实现水平扩展。

缺点

  1. 顺序性：跨分区场景下无法保证消息的顺序性。
  2. 依赖Zookeeper：旧版本Kafka依赖Zookeeper进行集群管理和元数据存储。如果Zookeeper集群出现问题，可能会影响到Kafka的稳定性和可用性。
  3. 扩容复杂：当需要增加Kafka集群的容量时，可能需要重新分配分区和副本，这可能会导致数据迁移和停机时间。

适用场景

  1. 日志收集和分析。
  2. 分布式系统监控和告警：Kafka可以接收来自分布式系统的监控数据和告警信息，并进行实时处理和通知。
  3. 消息队列：削峰填谷，解耦生产者与消费者。
  4. 事件驱动架构：微服务间异步通信。
  5. 数据流处理：如用户行为分析、实时监控。

.net集成kafka源码地址

https://github.com/confluentinc/confluent-kafka-dotnet

流程图

posted @ 2025-06-10 23:49  相遇就是有缘  阅读(34)  评论(0)    收藏  举报