Kafka原理与架构

  1. kafka概述

  1. 什么是 Kafka？

Kafka是一个由Apache软件基金会开发的开源分布式事件流平台，最初由LinkedIn公司开发并于2011年开源。它本质上是一个高吞吐量的分布式发布-订阅消息系统(Message Queue)。

  1. Kafka特性

  • 高吞吐量：每秒可处理数十万条消息；
  • 低延迟：消息处理延迟通常在毫秒级；
  • 容错性：通过多副本（Replica）机制实现数据备份和容错，确保数据不丢失；
  • 可扩展性：通过增加 Broker 节点和分区数量来扩展集群处理能力；

  1. Kafka 的典型应用场景

消息系统： Kafka 和传统的消息系统（也称作消息中间件）都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
存储系统： Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于 Kafka 的消息持久化功能和多副本机制，我们可以把 Kafka 作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置为“永久”或启用主题的日志压缩功能即可。
流式处理平台： Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。

  1. Kafka 架构与核心原理

  1. 典型架构

image

1）Producer ：消息生产者，就是向 kafka broker 发消息的客户端；
2）Consumer ：消息消费者，向 kafka broker 取消息的客户端；
3）Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）Broker ：一个kafka 服务实例就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个topic。
5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；
6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；
7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。
8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。
9）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个follower 会成为新的 leader。

  1. 核心组件

  1. Broker

Kafka Broker是Apache Kafka分布式消息系统的核心服务组件，负责消息的存储、管理和分发。每个Broker都是一个独立的Kafka服务器实例，多个Broker共同组成Kafka集群，提供高可用和高吞吐量的消息服务。
消息存储与管理
Broker接收来自生产者的消息，为消息设置偏移量(offset)，并将消息持久化存储到磁盘。采用顺序写入和零拷贝技术，确保高性能的消息处理能力，单个Broker可轻松处理数千个分区和每秒10万级的消息量。
分区领导机制
在Kafka集群中，每个分区都有一个Broker充当Leader角色，负责处理该分区的所有读写请求。其他Broker作为Followers，被动复制Leader的数据，实现数据的冗余备份和故障转移。
副本同步与ISR
Kafka通过ISR(In-Sync Replica)机制维护与Leader保持同步的副本列表。当Leader发生故障时，系统会从ISR中选择新的Leader，确保服务的连续性和数据的一致性。
集群组成
Kafka集群由多个Broker构成，每个Broker都有唯一的broker.id标识。集群中会自动选举一个Broker作为控制器，负责分区分配、Broker监控等管理工作。
分区副本分配
每个分区可以配置多个副本，这些副本分布在不同的Broker上。副本分配策略确保数据在集群中的分布式存储，提高系统的容错能力。

  1. Producer

Kafka Producer是Apache Kafka架构中的核心组件之一，负责将消息（或记录）发布到Kafka集群的指定主题中。作为数据管道的入口，Producer承担着将业务系统产生的实时数据流可靠、高效地传输到Kafka系统的关键任务。
Producer的主要工作流程包括消息构造、序列化、分区选择、批次发送等关键步骤。首先需要创建ProducerRecord对象，指定目标主题和消息内容，然后通过send()方法异步发送消息。在消息发送过程中，数据会经过序列化器转换为字节数组，接着由分区器确定消息应该发送到主题的哪个分区。
消息分区策略
Producer支持灵活的分区选择机制。如果显式指定了分区号，消息将直接发送到该分区；否则分区器会根据消息的Key值通过哈希算法计算目标分区。这种设计既保证了相同Key的消息总是路由到同一分区，又提供了负载均衡的能力。
可靠性保障机制
为确保消息的可靠传递，Producer提供了可配置的确认机制（acks参数）。生产者可以选择等待Leader副本确认、所有ISR副本确认等不同级别的可靠性保证。同时内置了重试机制，在网络异常或Broker故障时能够自动重新发送消息。
高性能优化特性
Producer采用批次发送和缓冲池技术来提升吞吐量。消息不会立即发送，而是积累到一定大小或时间后批量传输，这种设计显著减少了网络开销并提高了系统整体性能。

  1. Consumer

Kafka Consumer是Apache Kafka架构中负责从Kafka集群读取和处理消息的核心组件。作为数据管道的出口，Consumer通过订阅特定的主题来获取消息，并将这些消息传递给应用程序进行进一步处理。
消费者与消费者群组
在Kafka中，消费者通常以消费者群组(Consumer Group)的形式组织。每个群组包含一个或多个消费者实例，共同消费一个或多个主题的消息。Kafka通过分区分配机制，确保同一个分区在同一时刻只能被同一个消费者群组中的一个消费者读取。
分区再均衡机制
当消费者群组发生变化时（如消费者加入或离开），会触发分区再均衡(Rebalance)。
偏移量管理
消费者使用偏移量(Offset)来追踪在每个分区中已读取的位置。偏移量信息存储在特殊的__consumer_offsets主题中。
提交方式：
  • 自动提交：定期自动提交偏移量，可能导致重复消费
  • 手动提交：开发者控制提交时机，分为同步提交和异步提交。
消费模式
Kafka Consumer支持两种基本消费模式：
  • 队列模式：同一群组的消费者竞争消费消息
  • 发布-订阅模式：不同群组的消费者都能收到所有消息

  1. Topic & Partition

Kafka Topic是消息的逻辑分类单元，用于组织和分类消息流。在Kafka架构中，Topic充当消息的逻辑容器，所有消息的生产和消费都围绕Topic进行。
Topic作为数据流的逻辑分类，可以理解为消息的类别或频道。例如在电商平台中，可能有"orders"、"payments"和"inventory"等多个Topic，每个Topic承载特定类型的事件流。这种设计使得Kafka能够支持发布-订阅模式，允许多个生产者和消费者独立操作，增强了系统的灵活性和解耦性。
分区机制与并行处理
每个Topic可以被划分为多个分区(Partition)，这些分区是Topic的物理分片，分布在不同Broker上。分区机制不仅实现了数据的分布式存储，还通过并行处理大幅提升了吞吐量。分区数决定了Topic的并行处理能力，在创建Topic时指定，后续可动态增加但不可减少。
每个Partition在物理上被划分为多个Segment文件，新消息总是写入当前活跃的Segment，当文件达到配置大小（默认1GB）时，创建新的Segment。
每个Segment包含：
  • log文件：存储实际消息数据
  • index文件：采用稀疏索引，加速消息查找
  • timeindex文件：根据时间戳查找对应的消息偏移量，主要用于按时间范围检索消息的场景。
Segment文件按offset命名，如00000000000000000000.log，通过offset先在index文件中二分查找定位大致位置，再到log文件中精确查找具体消息。
数据可靠性与副本机制
为了保证数据的可靠性，每个分区可以设置为多个副本(replica)，通常会设置两副本或三副本。副本只有设置在不同的机器上才能发挥作用，副本数必须小于集群的Broker数。每个分区都是一个顺序的、不可变的消息队列，并且可以持续添加消息。

  1. ZooKeeper

ZooKeeper在Kafka架构中扮演着分布式协调服务的核心角色，为Kafka集群提供关键的元数据管理和协调功能。
元数据集中管理
ZooKeeper作为Kafka的"配置中心"，集中存储和管理集群的所有元数据信息，包括Broker节点注册、Topic配置、分区状态等。所有Broker在启动时都会向ZooKeeper进行注册，形成一个完整的集群拓扑结构。
Controller选举机制
Kafka集群通过ZooKeeper实现Controller的选举。当集群启动或当前Controller失效时，Broker们会通过ZooKeeper的选举功能竞争成为新的Controller，负责分区Leader选举、副本重新分配等关键任务。
Broker节点管理
ZooKeeper维护着集群中所有Broker的实时状态，包括节点的上下线情况、负载信息等，为负载均衡提供数据支持。
Topic与分区协调
Topic的创建、删除以及分区的分配方案都通过ZooKeeper进行协调和持久化，确保集群配置的一致性。
ZooKeeper的局限性
尽管ZooKeeper在早期版本的Kafka中发挥了重要作用，但也存在一些局限性。双重系统架构导致了操作复杂性和资源浪费，元数据的外部存储限制了Kafka的可扩展性。
KRaft模式替代
为了解决这些问题，Kafka社区提出了KIP-500计划，引入KRaft模式（Kafka Raft Metadata）来取代ZooKeeper，将元数据管理完全内置于Kafka自身。

  1. Controller 选举与 Broker 协调

Controller选举机制
  1. 选举触发条件
    1. 集群启动：所有Broker尝试在ZooKeeper中创建/controller临时节点（ZooKeeper模式）或通过Raft协议竞争（KRaft模式）。
    2. Controller故障：原Controller宕机或与协调服务失联时，触发重新选举。
  2. 选举过程
    1. ZooKeeper模式：首个成功创建/controller节点的Broker成为Controller，其他Broker监听该节点变化。
    2. KRaft模式：基于内部Raft协议选举，元数据存储在__metadata主题中，无需依赖ZooKeeper。
    3. 任期机制：每次选举后任期号（Epoch）递增，避免脑裂问题。
  3. Controller职责
    1. 管理分区Leader选举（优先从ISR中选择）和副本状态同步。
    2. 处理Broker增减、Topic创建/删除等元数据变更。
Broker协调机制
  1. 元数据同步
    1. Controller将集群元数据（如分区分配、Broker列表）同步至所有Broker。
    2. Broker启动时向Controller注册，并拉取最新元数据。
  2. 故障恢复
    1. Broker宕机：Controller检测到后，触发受影响分区的Leader重选举（从ISR中选择新Leader）。
    2. 网络分区：通过任期号校验请求有效性，仅接受当前Controller的指令。
  3. 消费者组协调
    1. 消费者组协调器（GroupCoordinator）由__consumer_offsets分区的Leader Broker担任，管理消费者Rebalance和Offset提交。

  1. 发布-订阅模型 vs 消息队列模型

基本概念差异
  1. 消息队列模型(点对点/P2P)
    1. 采用队列(Queue)作为消息容器，遵循FIFO原则，消息被消费后即从队列删除
    2. 生产者发送消息到特定队列，只有一个消费者能接收处理该消息
    3. 典型应用：任务分发、一对一通信场景
  2. 发布订阅模型(Pub/Sub)
    1. 采用主题(Topic)作为消息容器，消息可被多个订阅者并发获取
    2. 生产者发布消息到主题，所有订阅该主题的消费者都会收到消息副本
    3. Kafka的核心模型，支持消费者组(Consumer Group)实现负载均衡
Kafka的混合特性
  1. 发布订阅基础 Kafka本质上采用发布订阅模型，通过主题机制实现消息广播
  2. 队列模式兼容
    1. 当消费者组内只有一个消费者时，行为类似队列模型
    2. 通过消费者组机制实现"竞争消费"，同一消息在同一消费者组内只被消费一次

  1. 数据持久化与高性能写入

Kafka通过以下方式实现数据持久化：
  1. 日志结构存储：采用追加写入(append-only)方式将消息顺序写入磁盘，避免随机写入带来的性能损耗。有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。
  2. 保留策略：支持按时间或大小配置消息保留策略，平衡存储成本与数据可用性
      基础保留策略
      （1）时间维度
      通过log.retention.ms（毫秒级）或log.retention.hours设置消息保留时长，超时后自动删除旧消息。例如保留7天数据：log.retention.ms=604800000
      （2）空间维度
      通过log.retention.bytes限制单个分区的最大存储空间（字节），达到阈值后删除旧消息。例如限制1GB：log.retention.bytes=1073741824
      清理策略选择
      （1）删除策略（Delete）
      基于时间或大小删除旧消息，需设置log.cleanup.policy=delete，适用于仅需保留近期数据的场景（如日志类Topic）。
      （2）压缩策略（Compact）
      保留每个键的最新值，删除旧版本，需设置log.cleanup.policy=compact并启用清理线程。适用于需保留键最新状态的场景（如数据库变更日志）
      （3）混合策略
      同时启用delete和compact，先压缩保留键最新值，再按时间/大小删除冗余数据。
      比如当同时设置7天和10GB保留条件时，若第5天消息达到10GB，Kafka会立即触发清理，优先满足空间阈值。
Kafka实现高吞吐量的关键技术包括：
  1. 顺序磁盘访问
    1. 利用机械硬盘顺序读写性能优势(比随机读写快10-100倍)
    2. 消息追加写入方式完全匹配磁盘物理结构特性
  2. 零拷贝技术
    1. 使用Linux的sendfile系统调用，减少数据在用户空间和内核空间之间的复制
    2. 传统方式需要4次数据拷贝，零拷贝仅需1次
  3. 批量处理优化
    1. 生产者批量发送消息，减少网络I/O次数
    2. 消费者批量拉取消息，提高处理效率
  4. 内存映射(MMAP)
    1. 将磁盘文件映射到内存，减少系统调用开销
    2. 结合PageCache提升读写性能

  1. ISR（In-Sync Replicas）与高可用性

Kafka的ISR（In-Sync Replicas）机制是其实现高可用性的核心设计之一。Leader 维护了一个动态的 in-sync replica set (ISR)，意为和 leader 保持同步的 follower 集合。当 ISR 中的 follower 完成数据的同步之后， 就会给 leader 发送 ack。如果 follower长时间未向leader同步数据，则该follower将被踢出ISR。
ISR机制的核心作用：
  1. 数据一致性保障
    1. ISR是同步副本集合，只有与Leader保持同步的Follower副本才会被纳入ISR列表。
    2. 生产者可通过acks=all配置要求所有ISR副本确认写入，确保数据不丢失。
  2. 高可用性实现
    1. Leader故障时，Kafka优先从ISR中选举新Leader，避免数据不一致。
    2. 若ISR中副本数不足（如低于min.insync.replicas），Topic会进入只读状态，防止数据丢失。
  3. 判断标准
    1. replica.lag.time.max.ms：Follower同步超时阈值（默认10秒）。如果leader发现flower超过10秒没有向它发起fech请求，那么leader就把它从ISR中移除。
  4. 数据可见性
Kafka中的LEO（Log End Offset）和HW（High Watermark）是保障数据一致性和消费者可见性的核心机制。
LEO：指的是每个副本最大的 offset；
HW：指的是消费者能见到的最大的offset,ISR队列中最小的LEO。
  1. 故障处理
（1）follower 故障
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。
等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。
（2）leader 故障
leader 发生故障之后，会从ISR中选出一个新的leader之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。
（3）ISR空置的特殊情况
当ISR集合中没有可用的Follower时，系统提供两种恢复选项：
1）等待ISR恢复（默认推荐）
  • 控制器会等待原ISR中的副本重新上线
  • 确保数据一致性，但恢复时间不确定
  • 适用于对数据准确性要求高的场景
2）从OSR中选举（需手动开启）
  • 通过设置unclean.leader.election.enable=true启用
  • 从不同步的副本集（OSR）中选择新Leader
  • 恢复速度快，但可能丢失已提交的数据

  1. 分区（Partition）与副本（Replica）机制

Kafka的分区（Partition）与副本（Replica）机制是其实现高吞吐、高可用和负载均衡的核心设计，具体原理如下：
分区（Partition）机制
  1. 数据分片
    1. 每个Topic被划分为多个分区，消息按分区存储，实现数据的水平拆分。
    2. 分区内消息有序（通过偏移量Offset保证），但分区间无序。
    3. 生产者通过指定分区键（Key）或轮询策略决定消息写入哪个分区。
  2. 负载均衡
    1. 分区分布在不同的Broker上，允许并行读写，提升吞吐量。
    2. 消费者组内每个消费者实例独占消费一个或多个分区，实现消费端的负载均衡。
  3. 分区策略
    1. 指明 partition 的情况下，直接将指明的值直接作为 partiton 值；
    2. 没有指明 partition 值但有 key 的情况下，将key的hash值与topic的partition数进行取余得到 partition 值；
    3. 既没有 partition 值又没有key值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与 topic 可用的 partition 总数取余得到 partition值，也就是常说的 round-robin 算法。
副本（Replica）机制
  1. 高可用保障
    1. 每个分区有多个副本（Replica），包含一个Leader和多个Follower。
    2. Leader处理所有读写请求，Follower异步同步Leader数据。
    3. 若Leader失效，通过ISR（In-Sync Replicas）列表选举新Leader。
  2. 数据冗余与一致性
    1. 副本分布在不同的Broker上，避免单点故障。
    2. 生产者可配置acks参数控制数据一致性级别（如acks=all需所有ISR副本确认）。
  3. ack应答机制
对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等 ISR 中的 follower 全部接收成功。Kafka 为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。
acks 参数配置：
  • 0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据；
  • 1：Kafka默认设置；producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前 leader 故障，那么将会丢失数据
  • -1（all）：producer等待broker的ack，partition的leader和follower=全部落盘成功后才返回 ack。但是如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复。
启用幂等生产者：设置 enable.idempotence=true解决数据重复的问题。
唯一标识：每个生产者实例初始化时被分配唯一的Producer ID (PID)，每条消息附带单调递增的Sequence Number (SN)；
服务端去重：Broker会比对PID和SN，自动丢弃重复的消息。
数据可靠性保证
为保证 producer 发送的数据，能可靠的发送到指定的topic，topic的每个 partition 收到producer发送的数据后，都需要向 producer 发送ack（acknowledgement确认收到），如果producer未收到ack，就会重新发送数据。
设想以下情景：
leader 收到数据，所有 follower 都开始同步数据，但有一个 follower，因为某种故障，迟迟不能与 leader 进行同步，那 leader 就要一直等下去，直到它完成同步，才能发送 ack。这个问题怎么解决呢？

  1. 消费者组（Consumer Group）与并行消费

消费者组（Consumer Group）
  1. 定义与作用
    1. 消费者组是Kafka中一组消费者的逻辑容器，用于协同消费Topic的分区数据。
    2. 每个消费者组内的消费者共享订阅的Topic，但每个分区只能被组内一个消费者消费，避免重复处理。
    3. 主要功能：
      • 负载均衡：分区消息在组内消费者间分配，提升并行处理能力。
      • 水平扩展：通过增加消费者数量分担负载，适应高吞吐场景。
  2. 动态管理
    1. 消费者加入/退时触发分区再平衡（Rebalance），重新分配分区以保持负载均衡。
    2. 默认通过ZooKeeper（或KRaft模式）协调消费者与分区的映射关系。
并行消费机制
  1. 分区与并行性
    1. 每个Topic可划分为多个分区，每个分区独立存储消息序列（按offset顺序）。
    2. 消费者组内每个消费者负责消费一个或多个分区，实现并行处理。
    3. 示例：若Topic有3个分区，消费者组有3个消费者，则每个消费者独占一个分区。
  2. 性能优化
    1. 分区数决定最大并行度：消费者数量≤分区数时，可充分利用资源。
    2. 消费者组间互不影响：不同组可独立消费同一Topic，实现多业务逻辑并行
分区分配策略
  1. RangeAssignor（范围分配）
默认策略：按消费者名称字典序排序，将连续分区范围分配给消费者
分配规则：分区数/消费者数取整，余数分配给前几个消费者。例如3分区2消费者时，消费者0分配2个分区，消费者1分配1个分区
特点：可能导致分配不均，但实现简单
  1. RoundRobinAssignor（轮询分配）
分配规则：按分区和消费者字典序轮询分配，保证各消费者分区数最多相差1
特点：分配最均衡，但重平衡时分区变动较大
RangeAssignor和RoundRobinAssignor策略比较：
Case 1: topic有5个分区，consumer 2个
策略
分配结果
Range
c1: 0,1,2 c2: 3,4
RoundRobin
c1: 0,2,4
c2: 1,3
Case 2: 4个topic，分别是5个（A0-A4）、1个(B0)、1个(C0)、1个(D0)分区；consumer 还是2个
策略
分配结果
Range
c1: A0,A1,A2,B0,C0,D0 c2: A3,A4
RoundRobin
c1: A0,A2,A4,C0
c2: A1,A3,B0,D0
  1. StickyAssignor（粘性分配）
设计目标：保证分配均衡的同时，尽量保持与上次分配结果一致
特点：减少重平衡时的分区移动，适合频繁重平衡场景

  1. 架构演进

暂时无法在唯科之家2.0文档外展示此内容
如何提高性能？
暂时无法在唯科之家2.0文档外展示此内容
增加partition，实现数据分片：
  1. 提高性能：通过将数据分散存储，可以并行地处理数据请求，从而加快数据的读取和写入速度。例如，在一个分布式数据库中，不同的分片可以同时响应查询，减少了总体的响应时间。
  2. 增强可扩展性：当数据量不断增长时，可以方便地添加更多的分片来扩展存储容量，而无需对整个系统进行大规模的重构。
  3. 避免单点性能瓶颈：数据分片可以使数据的存储和访问负载更加均衡地分布在多个节点上，避免单个节点成为性能瓶颈。
暂时无法在唯科之家2.0文档外展示此内容
高可用
暂时无法在唯科之家2.0文档外展示此内容

  1. Kafka开发使用

  1. 生产者客户端开发

      配置生产者客户端参数及创建相应的生产者实例。 构建待发送的消息。 发送消息。 关闭生产者实例。
      必要的参数配置
      bootstrap.servers：该参数用来指定生产者客户端连接 Kafka 集群所需的 broker 地址清单，具体的内容格式为 host1:port1,host2:port2，可以设置一个或多个地址，中间以逗号隔开，此参数的默认值为“”。
      key.serializer 和 value.serializer：broker 端接收的消息必须以字节数组（byte[]）的形式存在，发往 broker 之前需要将消息中对应的 key 和 value 做相应的序列化操作来转换成字节数组。key.serializer 和 value.serializer 这两个参数分别用来指定 key 和 value 序列化操作的序列化器，这两个参数无默认值。

  1. 消费者客户端开发

必要的参数配置
bootstrap.servers：该参数的释义和生产者客户端 Kafka Producer 中的相同，用来指定连接 Kafka 集群所需的 broker 地址清单，具体内容形式为 host1:port1,host2:post，可以设置一个或多个地址，中间用逗号隔开。
group.id：消费者隶属的消费组的名称。
key.deserializer 和 value.deserializer：这两个参数分别用来指定消息中 key 和 value 所需反序列化操作的反序列化器，这两个参数无默认值。

  1. 命令行操作

1）查看当前服务器中的所有 topic
kafka-topics –zookeeper hadoop01:2181 --list
2）创建 topic
kafka-topics --zookeeperhadoop01:2181 --create --replication-factor 3 --partitions 1 --topic first
选项说明：
--topic 定义 topic 名
--replication-factor  定义副本数
--partitions  定义分区数
3）删除 topic
kafka-topics --zookeeperhadoop01:2181 --delete --topic first
需要 server.properties中设置 delete.topic.enable=true 否则只是标记删除。

4）发送消息
kafka-console-producer --broker-list hadoop01:9092 --topic first

5）消费消息
从zookeeper读取offset：kafka-console-consumer --zookeeper hadoop01:2181 --topic first  
kafka-console-consumer --bootstrap-server hadoop01:9092 --topic first
kafka-console-consumer --bootstrap-server hadoop01:9092 --from-beginning --topic first
--from-beginning：会把主题中以往所有的数据都读取出来。

6）查看某个 Topic 的详情
kafka-topics.sh --zookeeper hadoop01:2181 --describe --topic first
7）修改分区数
kafka-topics --zookeeper hadoop01:2181 --alter --topic first --partitions 6
 

  1. Kafka安全与权限

  1. kafka安全

（1）kafka client（producers and consumers）与 kafka server（broker）之间
（2）broker与broker之间
（3）broker与zookeeper之间

  1. kafka安全认证

（1）SSL SSL全称是 Secure Sockets Layer，它是一种间于传输层（比如TCP/IP）和应用层（比如HTTP）的协议。它通过"握手协议"和"传输协议"来解决传输安全的问题。
（2）SASL SASL是一种用来扩充C/S模式验证能力的机制认证机制, 全称Simple Authentication and Security Layer。

  1. Kafka ACL权限控制

kafka附带一个可插拔的ACL（Access Control List 访问控制列表），它使用zookeeper来存储。通过在server.properties中设置authorizer.class.name来启用：
ACL格式：
添加ACL
删除ACL
增加producer权限
kafka操作 kafka资源
 

  1. Kafka 在数据服务的使用

cti/uds/ivr
 

 

posted @ 2025-12-14 15:36  黑夜之鹰  阅读(1)  评论(0)    收藏  举报