一.基础概念
队列Queue
一种特殊的线性表(数据元素首尾相接)，特殊之处在于只允许在首部删除元素和在尾部追加元素。入队，出队
消息队列MQ
保存消息的队列，消息的传输过程中的容器；主要提供生产，消费接口供外部调用做数据的存储和获取
常用消息中间件比较
| 特性/中间件 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
| 单机吞吐量 | 相对较低（万级） | 相对较低（万级），性能在消息大量堆积时下降 | 高（十万级） | 非常高（接近百万级） |
| 时延性 | 通常较高，受线程模型影响 | 低延迟，适合实时应用 | 低延迟，优化了存储和网络传输 | 优化了磁盘I/O和网络传输。 但是异步和批处理的设计可能会带来一定延迟 |
| 可靠性 | 较低概率丢失数据 | 高，支持事务和持久化 | 高，支持持久化和同步复制 | 高，多副本和分区机制 |
| 扩展性 | 支持，但需要复杂的配置 | 支持，易于扩展 | 支持，易于扩展，适合大规模部署 | 支持，自动分区和副本，易于水平扩展 |
| 社区支持 | 较低 | 一般 | 阿里巴巴维护，在中国特别活跃 | 活跃，Apache顶级项目 |
| 功能特色 | 支持多种消息协议 | 支持灵活的路由配置 | 功能全面，支持事务、延迟消息等 | 专注于高吞吐量和日志处理 |
| 适用场景 | 企业级应用，需要多种消息协议支持 | 企业级应用，需要高并发和灵活路由 | 金融交易、订单处理等高可靠性和顺序性要求的场景 | 日志收集、实时分析等大规模数据流处理场景 |
kafka相关概念
Topic：
主题，Kafka处理消息的不同队列
Broker：
消息代理，Kafka集群中的一个kafka服务节点称为一个broker，存储消息数据。
Partition：
分区，Topic物理上的分组，一个topic在broker中被分为1个或多个partition，分区数量在创建topic的时候被指定
Replication：
数据副本，可以为保存在kafka中的数据指定副本数，以提高数据冗余性，防止数据丢失
PS：同一个分区的repliation分布在不同的Broker上，因此副本数不能高于集群中Broker节点数，否则会报错
segment:
分区（Partition）内部的一个关键概念，用于管理存储和文件系统交互。每个分区由多个Segment组成，而每个Segment则由两个关键文件组成：
- 数据文件（.log）：存储了实际的消息数据。它是分段的，每个Segment的数据文件都是分区中消息的连续物理存储区域。
- 索引文件（.index）：存储了数据文件中消息的索引信息，包括消息的偏移量（offset）、消息在数据文件中的位置（position）以及消息的大小（MessageSize）。用于加速消息的查找和检索。
Message：
消息，是通信的基本单位，每个消息都属于一个partition。Kafka将消息按照topic和partition进行组织，并将它们存储在一个或多个segment文件中。
二.底层设计
1. 三层消息架构
第一层是主题层，每个主题可以配置 M 个分区。
第二层是分区层，每个分区可以配置 N 个副本， N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，仅提供数据冗余之用。
第三层是副本层，分区副本中包含若干条消息，每条消息的位移从 0 开始，依次递增。
PS：客户端程序只能与分区的领导者副本进行交互（包括生产与消费）
2 高可用原理
1 ）备份机制（Replication）：
把相同的数据拷贝到多台机器上，而这些相同的数据拷贝在 Kafka 中被称为副本（Replica）。每个分区副本的数量是可以配置的，这些副本保存着相同的数据，但却有不同的角色和作用。
Kafka 定义了两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。
领导者副本（Leader Replica）:对外提供服务，这里的对外指的是与客户端程序进行交互；
追随者副本（Follower Replica）:不能与外界进行交互，仅用于数据备份。原有领导者宕机时，追随者可自动升级为领导者。
在其他系统中追随者副本可以对外提供服务，比如 MySQL 的从库是可以处理读操作的；但是在 Kafka 中追随者副本不会对外提供服务。
副本的工作机制：
- 生产者总是向领导者副本写消息；
- 消费者总是从领导者副本读消息。
- 追随者副本，它只做一件事：向领导者副本发送拉取请求，促使领导者把最新的消息发给它，这样它能保持与领导者的同步。
2）ISR机制
先来看几个概念
- AR（Assigned Repllicas）一个partition的所有副本（就是replica，不区分leader或follower）
- ISR（In-Sync Replicas）能够和 leader 保持同步的 follower + leader本身 组成的集合。
- OSR（Out-Sync Relipcas）不能和 leader 保持同步的 follower 集合
- 公式：AR = ISR + OSR
Kafka对外声称是完全同步，但是承诺是对AR中的所有replica完全同步了吗？
并没有。Kafka只保证对ISR集合中的所有副本保证完全同步。
ISR的机制保证了，处于ISR内部的follower都是可以和leader进行同步的，但一旦出现故障或延迟，就会被踢出ISR。
ISR 的核心就是：动态调整
而最坏的情况下，ISR中只剩leader自己。
3） broker 分属在不同的机器上：
虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上。kafka自动从broker集群中选出一个作为controller，这个controller会监控挂掉的broker，并为建立在上面的领导者副本重新选主。
如果集群中某一台机器宕机，运行的 Broker 进程挂掉了，原本分布其上的多个副本有两种情况：
- 是追随者副本，由于本来不对外提供服务，不影响可用性；
- 是领导者副本，则通过选主机制，分布在其他Broker的追随者有1个升级为领导者，继续对外提供服务。
3 Scalability – 伸缩性
利用副本机制保证数据的持久化或消息不丢失，利用分片机制提供了伸缩性。
当领导者副本积累了太多的数据以至于单台 Broker 机器都无法容纳了，分区（Partitioning）的重要性就更加凸显了。
日常的分片、分区域等提法，比如 MongoDB 和 Elasticsearch 中的 Sharding、HBase 中的 Region，都是相同的原理，Partitioning 是Kafka采用的名称。
Kafka 中的分区机制指的是将每个主题划分成多个分区（Partition），每个分区是一组有序的消息日志。
生产者生产的每条消息只会被发送到一个分区中，例如向一个双分区的主题发送一条消息，这条消息要么在分区 0 中，要么在分区 1 中。
生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征。分区位移总是从 0 开始，假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、2、…、9。
分区策略是决定生产者将消息发送到哪个分区的算法。Kafka 为我们提供了默认的分区策略，同时它也支持自定义分区策略。官方提供的分区策略有：
1) 轮询策略也称 Round-robin 策略，即顺序分配。
2) 随机策略也称 Randomness 策略。所谓随机就是我们随意地将消息放置到任意一个分区上
3) 按消息键保序策略，Kafka 允许为每条消息定义消息键，简称为 Key，可以保证同一个 Key 的所有消息都进入到相同的分区里面。
4 持久化
Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。
因为只能追加写入，故避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段。
如果不停地向一个日志写入消息，最终也会耗尽所有的磁盘空间，因此 Kafka 必然要定期地删除消息以回收磁盘。怎么删除呢？
简单来说就是通过日志段（Log Segment）机制。
- 在 Kafka 底层，一个日志又近一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来。
- Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。
5 消费者组与重平衡
消费者组，指的是多个消费者实例共同组成一个group来消费一组主题。这组主题中的每个分区都只会被组内的一个消费者实例消费，其他消费者实例不能消费它。当然同一个主题可以被多个不同的消费者组消费。
为什么要引入消费者组呢？主要是为了提升消费者端的吞吐量。多个消费者实例同时消费，加速整个消费端的吞吐量（TPS）。
重平衡（Rebalance），指的是分区的消费所有权从一个消费者实例转移到另一个实例。消费者组里面的所有消费者实例不仅“瓜分”订阅主题的数据，而且当组内某个实例宕机了，Kafka 能够自动检测到，然后把该实例负责的分区转移给其他正常的实例。
再平衡触发条件
- 消费者组内成员变更，如新增消费者，消费者下线。
- 主题的分区数发生变更，kafka支持动态增加主题的分区，当增加主题的分区时会触发重平衡。
- 订阅的主题发生变化。当消费者组使用正则表达式订阅主题时，这时kafka的主题发生变化时，就会触发重平衡流程。
6.高性能设计
kafka高吞吐量、低延迟处理，高性能得益于如下设计：
- 顺序I/O与磁盘预读：Kafka通过顺序写入（Sequential Writes）来优化磁盘I/O性能。生产者将消息追加到日志文件的末尾，而消费者从文件的开始处顺序读取，这样可以减少磁盘寻道时间并提高磁盘的吞吐量。同时，Kafka充分利用了操作系统的预读机制，利用页缓存（Page Cache）来缓存热点数据，这样可以提高读写性能。
- 零拷贝：在Linux系统中，Kafka使用sendfile命令来减少数据拷贝次数。传统的数据传输过程中，数据需要从硬盘读取到内核中的页缓存，再从内核中读取到用户空间，最后写入到socket缓冲区。而使用sendfile命令可以跳过用户空间的数据拷贝步骤，直接将数据从内核空间发送到网络，减少了数据拷贝的开销。
传统的传输过程
sendfile方式
- 分区与分布式处理：Kafka将数据划分为多个分区，每个分区对应一个磁盘文件，这使得数据可以并行处理，提高了吞吐量。同时，Kafka的分布式架构允许在多个节点上部署，从而实现了水平扩展，进一步提高了处理能力。
- 生产者异步发送与批量处理：Kafka的生产者支持异步发送消息，这意味着生产者可以在发送消息的同时继续处理其他任务，提高了系统的并发性能。此外，生产者还可以将多条消息批量发送，减少了网络传输的延迟和开销，进一步提高了吞吐量。
- 消费者拉取模式与微批处理：Kafka的消费者采用拉取模式获取消息，这使得消费者可以根据自己的处理能力来拉取适量的消息进行处理。同时，Kafka支持微批处理技术，将一定时间内收集到的消息进行批量处理，降低了处理每条消息的延迟，提高了整体吞吐量。
- 压缩：Kafka支持消息压缩，可以减少网络传输的数据量，从而提高网络带宽的利用率。
- 索引文件：Kafka为每个日志分区维护一个索引文件，该文件存储了消息的偏移量和消息在日志文件中的位置。这样可以快速定位消息，提高消费者的读取效率。
- 优化的网络栈：Kafka使用了优化的网络栈，如使用非阻塞I/O和直接内存访问，减少了网络延迟和提高了数据传输效率。
三.部署方式
官方部署文档： Apache Kafka
2.8版本之前使用zookeeper
Zookeeper 在 kafka 中的具体作用
1）Broker注册
Broker是分布式部署并且相互之间相互独立，但是需要有一个注册中心对整个集群的Broker进行管理，此时就使用了Zookeeper。在Zookeeper上会有一个专门用来记录Broker服务器列表的节点：/brokers/ids
每个Broker在启动时，都会在Zookeeper上进行注册，即到/brokers/ids下创建属于自己的节点，如/brokers/ids/[0…N]。
Kafka使用了全局唯一的数字来指代每个Broker服务器，不同的Broker必须使用不同的Broker ID进行注册，创建完节点后，每个Broker就会将自己的IP地址和端口信息记录到该节点中去。其中，Broker创建的节点类型是临时节点，一旦Broker宕机，则对应的临时节点也会被自动删除。
2）Topic注册
在kafka中，用户可以自定义多个topic，每个topic又被划分为多个分区，每个分区存储在一个独立的broker上。这些分区信息及与Broker的对应关系都是由Zookeeper进行维护。
在zookeeper中，建立专门的节点来记录这些信息，其节点路径为/brokers/topics/{topic_name}。并且topic创建的节点类型也是临时节点
3）消费者负载均衡
Kafka中的消费者需要进行负载均衡来实现多个消费者合理地从对应的Broker服务器上接收消息，每个消费者分组包含若干消费者，每条消息都只会发送给分组中的一个消费者，不同的消费者分组消费自己特定的Topic下面的消息，互不干扰。
每个消费者都需要关注所属消费者分组中其他消费者服务器的变化情况，即对/consumers/[group_id]/ids节点注册子节点变化的Watcher监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。还对Broker服务器变化注册监听。消费者需要对/broker/ids/[0-N]中的节点进行监听，如果发现Broker服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。
4）记录分区与消费者的关系
消费者组 Consumer group 下有多个 Consumer（消费者）。在Kafka中，规定了每个消息分区 只能被同组的一个消费者进行消费，因此，需要在 Zookeeper 上记录 消息分区 与 Consumer 之间的关系，每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID 写入到 Zookeeper 对应消息分区的临时节点上，例如：
/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]
其中，[broker_id-partition_id]就是一个 消息分区 的标识，节点内容就是该消息分区上消费者的Consumer ID。
5）记录消息消费的进度Offset
在消费者对指定消息分区进行消息消费的过程中，需要定时地将分区消息的消费进度Offset记录到Zookeeper上，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为:
/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]
节点内容就是Offset的值。
6）消费者注册
当新的消费者组注册到zookeeper中时，zookeeper会创建专用的节点来保存相关信息，其节点路径为 /consumers/{group_id}，其节点下有三个子节点，分别为[ids, owners, offsets]。
- ids节点：记录该消费组中当前正在消费的消费者；
- owners节点：记录该消费组消费的topic信息；
- offsets节点：记录每个topic的每个分区的offset；
当前企搜采用的是该模式，2.4.0版本，每个主题是3分区2副本的配置。
zookeeper 本身的问题
Zookeeper集群中也存在所谓的Leader节点和从节点，Leader节点负责写，Leader与从节点可用接受读请求，但在Zookeeper内部节点在选举时整个Zookeeper无法对外提供服务。另外，有些情况例如Zookeeper节点发生full GC，此时对服务的可用性影响也很大。
Zookeeper节点如果频繁发生Full GC(Stop The World)，此时与客户端的会话将超时，无法响应客户端的心跳请求，与会话相关联的临时节点将被删除，注意，此时是所有的临时节点被删除，Zookeeper依赖的事件通知机制将失效，整个集群的选举服务将失效。
2.8版本之后去除zookeeper，使用raft协议
站在高可用性的角度，Kafka集群的可用性不仅取决于自身，还受到了外部组件的制约，从长久来看，显然都不是一个优雅的方案。
Raft协议的两个重要组成部分：Leader选举、日志复制，而日志复制为多个副本提供数据强一致性，并且一个显著的特点是Raft节点是去中心化的架构，不依赖外部的组件，而是作为一个协议簇嵌入到应用中的，即与应用本身是融合为一体的。
raft选举的leader提供了上述zookeeper的功能。
四.使用场景
1.异步处理
企搜中当调用push接口推入海量数据后，系统用kafka保存了数据，可以迅速返回完成接口的调用。
其他知识生产模块消费kafka中的数据，以异步的方式完成后续比较复杂以及耗时的过程。
通过异步的方式，可以大幅提升数据接入的QPS。
2.流量削峰
在大型促销活动中，如“双十一”或“黑色星期五”，用户访问量会在短时间内激增，可能导致后端服务过载甚至宕机。
Kafka可以作为流量削峰的缓冲区。用户请求首先被写入Kafka，然后后端服务按照自身处理能力从Kafka中拉取请求进行处理。这种方式可以平滑处理流量高峰，避免系统因短时间内的大量请求而过载。
3.服务解耦
在企搜的全文生产环节，data-access、gaia-flow、index（或qaplat-data-server)之间有数据的传递。
当前采用kafka做中间数据的传递，上游生产、下游消费，各个服务之间完全解耦，不依赖彼此的状态及可用性（A服务异常不影响B服务）。在开发、部署及运维阶段都带来了便利。
五.特殊场景
这里再介绍2个常见的使用场景实现方式，在某些场合下有特定的价值。
1.消息零丢失
Kafka的消息数据大体上来说，在生产、存储、消费的3个环节，都可能存在丢失的情况。分析及避免措施如下：
- 生产数据丢失
生产操作不成功，出现异常——生产端处理返回值或者捕获异常，若不成功则重试（设置一个较大的重试次数）；
leader尚未完成与follower的数据同步就宕机，新的leader缺失数据——确保副本数量大于1（min.insync.replicas>=1），确保至少有一个follower在通信；生产端ack设为all或者>=2，表示有follower同步完才认为成功；
- 存储数据丢失
单节点broker模式宕机——确保消息保存到磁盘后（而不是page cache）再返回确认信息；避免单副本模式。
- 消费数据丢失
消费者提交offeset后还没来得及处理就宕机——关闭自动提交offset改为手动提交（at least once以及主键保证）
Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证。
丢失消息的case1：
目前 Kafka Producer 是异步发送消息的，也就是说如果你调用的producer.send(msg) 这个 API，那么它通常会立即返回，但此时不能认为消息发送已成功完成。
- 网络抖动，导致消息压根就没有发送到 Broker 端；
- 消息本身不合格导致 Broker 拒绝接收（比如消息太大了，超过了 Broker 的承受能力）等。
Producer 如果想知道详细是否发送成功，不要使用 producer.send(msg)，而要考虑使用 producer.send(msg, callback)。
以上这种场景造成的消息发送失败，责任是在producer端。
丢失消息的case2:
Consumer 端丢失数据主要体现在 Consumer 端要消费的消息不见了。Consumer 程序有个“位移”的概念，表示的是这个 Consumer 当前消费到的 Topic 分区的位置。
若消费消息和更新位移的顺序搞错，则可以会丢失消息，处理办法很简单：维持先消费消息，再更新位
丢失消息的case3:
Consumer 程序从 Kafka 获取到消息后开启了多个线程异步处理消息，而 Consumer 程序自动地向前更新位移。假如其中某个线程运行失败了，它负责的消息没有被成功处理，但位移已经被更新了，因此这条消息对于 Consumer 而言实际上是丢失了。
如果是多线程异步处理消费消息，Consumer 程序不要开启自动提交位移，而是要应用程序手动提交位移
2.顺序消费
kafka同一个topic是无法保证数据的顺序性的，但是同一个partition中的数据是有顺序的。下面分析消息失序的原因，并给出顺序消费的保证措施。
生产端异步发送导致失序：采用同步生产消息的方式，保证消息进入partition就是有序的；
有序消息进入不同的partition，被不同的实例消费到，造成失序：Kafka提供了接口供用户实现自定义的partition，用户可以为每个消息指定一个partitionKey，相同的key会保证进入同一个partition，确保只会被一个实例消费到
有序消息被同一个实例以多线程方式消费，线程之间无法控制先后造成失序：单实例内部不能多线程并行处理消息，只采用单线程
PS：当消费者组中的多个消费者实例启动并开始消费时，Kafka会使用一种叫做“分区分配算法”的机制来决定每个消费者实例应该消费哪些分区。
这个算法确保了消费者组内的每个分区只被一个消费者线程处理，可以避免消息的重复消费和数据的不一致性
六.使用方式
1.工程中使用
关键配置信息：
生产者
- bootstrap.servers
- 含义：Kafka集群的地址列表，格式为host1:port1,host2:port2,...。
- 典型值：localhost:9092 或 kafka-broker1:9092,kafka-broker2:9092
- key.serializer
- 含义：键的序列化类。
- 典型值：org.apache.kafka.common.serialization.StringSerializer
- value.serializer
- 含义：值的序列化类。
- 典型值：org.apache.kafka.common.serialization.StringSerializer 或 org.apache.kafka.common.serialization.ByteArraySerializer
- acks
- 含义：指定必须有多少个分区副本接收到消息才认为写入是成功的。all表示所有副本，1表示至少一个副本，0表示不等待任何副本的确认。
- 典型值：1
- retries
- 含义：发送失败时重试的次数。
- 典型值：0 或 3
- batch.size
- 含义：生产者将尝试将多个记录批量发送到同一个请求中。这可以帮助提高吞吐量，但可能会增加延迟。
- 典型值：16384
- linger.ms
- 含义：生产者将在发送请求之前等待更多记录添加到同一批次的时间。
- 典型值：1
- buffer.memory
- 含义：生产者用于缓存等待发送到服务器的记录的总字节。
- 典型值：33554432（32MB）
消费者
- bootstrap.servers
- 含义：与生产者相同，指定Kafka集群的地址列表。
- 典型值：与生产者相同。
- group.id
- 含义：消费者组ID。同一组内的消费者将共享消费记录。
- 典型值：my-consumer-group
- key.deserializer
- 含义：键的反序列化类。
- 典型值：org.apache.kafka.common.serialization.StringDeserializer
- value.deserializer
- 含义：值的反序列化类。
- 典型值：与key.deserializer相同或org.apache.kafka.common.serialization.ByteArrayDeserializer
- auto.offset.reset
- 含义：当各分区没有初始偏移量或当前偏移量在日志中不存在时（例如，在消费者长时间未消费，生产者继续生产消息导致消费者落后太多时），该配置指定了消费者应从何处开始读取。可选值有earliest（从头开始），latest（从最新消息开始），none（如果没有初始偏移量就抛出异常）。
- 典型值：earliest 或 latest
- enable.auto.commit
- 含义：如果为true，则消费者偏移量将在后台自动提交。
- 典型值：true
- auto.commit.interval.ms
- 含义：自动提交偏移量的频率（以毫秒为单位）。
- 典型值：1000
- max.poll.records
- 含义：消费者在一次轮询（poll）中获取的最大记录数。
- 典型值：500
- max.poll.interval.ms
- 含义：消费者两次轮询调用之间的最大延迟（以毫秒为单位）。如果在这个时间内没有调用poll()，消费者将被视为失败并从组中移除。
- 典型值：30
java生产：
// 构建生产端
Producer<String, String> producer = new KafkaProducer<>(properties);
// 生产消息，并且带回调函数
producer.send(new ProducerRecord<String, String>(topic, key, data), new Callback() {
public void onCompletion(RecordMetadata metadata, Exception exception) {
if (exception != null) {
exception.printStackTrace();
return;
}
log.info("key: {}, produce msg completed", key);
}
});
// 关闭生产端
producer.close();
java消费：
@KafkaListener(id = "source", topicPattern = "source_.*", groupId = "source", containerFactory =
"kafkaSourceBatchContainerFactory")
public void listen(List<ConsumerRecord<?, ?>> list, Acknowledgment ack) {
List<String> messages = new ArrayList<>();
for (ConsumerRecord<?, ?> record : list) {
Optional<?> kafkaMessage = Optional.ofNullable(record.value());
// 获取消息
kafkaMessage.ifPresent(o -> messages.add(o.toString()));
}
if (messages.size() > 0) {
// 处理消息
try {
this.consumer(messages);
} catch (Exception e) {
log.error(e.getMessage(), e);
}
// 确认位移
ack.acknowledge();
}
}
id：监听器指定一个唯一的标识符
groupId：参数指定Kafka消费者组的ID，表示一组消费者共同处理消息
topicPattern：参数指定一个正则表达式模式，以匹配要监听的多个主题。这使得可以通过模式来匹配一组相关的主题
containerFactory：创建监听器容器的工厂类
2.命令行使用
需要切换到kafka 安装目录 bin 目录下
注：企搜项目中，切入pod后，命令前加上unset JMX_PORT;排除掉JMX监控
e.g unset JMX_PORT;kafka-topics.sh --list --zookeeper kafka-zookeeper
Topic 相关的命令
1）帮助命令：
kafka-topics.sh --help
2) 查询topic列表
kafka-topics.sh --list --zookeeper kafka-zookeeper
3）查询topic详情
kafka-topics.sh --describe --zookeeper kafka-zookeeper --topic mpkss_flow_2483_901_process_text
注意：若不指定topc则输出所有的topic 信息
4） 创建topic
bin/kafka-topics.sh -zookeeper localhost:2181--create --partitions 5--replication-factor 1 --topic test_kafka_topic
5）增加topic的partition数
bin/kafka-topics.sh --zookeeper localhost:2181--alter --topic test_kafka_topic--partitions 5
6）删除topic
bin/kafka-topics.sh --delete --zookeeper localhost:2181--topic test_kafka_topic
消息相关的命令
1）生产者发生消息
bin/kafka-console-producer.sh --broker-list localhost:9092--topic test_kafka_topic
2）消费消息(从头开始)
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092--from-beginning--topic test_kafka_topic
3）消费消息(从尾开始）
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092--topic test_kafka_topic --offset latest
4）消费消息(从尾开始指定分区）
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092--topic test_kafka_topic --offset latest--partition 0
5）消费消息(指定分区指定偏移量）
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092--topic test_kafka_topic --partition 0--offset 100
6）指定个数
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092--topic test_kafka_topic --offset latest--partition 0--max-messages 1
消费者组group
1）指定group
指定分组从头开始消费消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test -grouptest_group --from-beginning
2）消费者group列表
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list
3）查看group详情
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --grouptest_group --describe
4）删除group
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --grouptest_group --delete
其他命令
1）启动
bin/kafka-server-start.sh config/server.properties
后台常驻方式，带上参数 -daemon，如：bin/kafka-server-start.sh -daemon config/server.properties
指定 JMX port 端口启动，指定 jmx，可以方便监控 Kafka 集群
JMX_PORT=9991/usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties
2）停止
bin/kafka-server-stop.sh
3）平衡leader
bin/kafka-preferred-replica-election.sh --bootstrap-server localhost:9092
扫一扫
12万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
