本文主要是关于Kafka的命令详解,每个命令都进行了非常详细的注释,帮助大家能更好的理解这些命令背后的含义,从底层去理解,如果大家喜欢,请多多点赞关注,欢迎评论!
为大家推荐几篇比较好的Kafka文章:
Kafka分布式集群部署实战:跨越理论,直击生产环境部署难题与解决方案,性能调优、监控与管理策略大揭秘,轻松上手分布式消息中间件-CSDN博客
Apache Kafka是一个开源的分布式消息系统,也是一个分布式流式计算平台。尽管它在流式计算方面有着强大功能,但在实际应用中,Kafka更多地被用作分布式消息队列。以下是对Kafka的详细解析:
进入Kafka目录下
bin/kafka-server-start.sh -daemon config/server.properties
bin/kafka-server-start.sh
:这是 Kafka 提供的启动 Kafka 服务器的脚本文件。它位于 Kafka 安装目录的 bin
子目录下。这个脚本负责启动 Kafka 服务器进程。
-daemon
:这个参数并不是 Kafka 官方文档中直接提到的标准参数。然而,在一些系统中,-daemon
参数可能用于指示脚本以守护进程(daemon)模式运行。守护进程是在后台运行的进程,它独立于启动它的终端或会话。如果 Kafka 脚本或系统环境以某种方式支持 -daemon
参数,那么使用此参数可能会使 Kafka 服务器在后台运行,并且不会阻塞启动它的终端或脚本。
config/server.properties
:这是 Kafka 服务器的配置文件路径。这个文件包含了 Kafka 服务器的各种配置参数,如监听端口、日志目录、ZooKeeper 连接信息等。
然而,需要注意的是,Kafka 官方通常推荐使用 nohup
、screen
、tmux
或系统服务管理工具(如 systemd
、upstart
、supervisord
等)来在后台运行 Kafka 服务器。这些工具提供了更可靠和灵活的方式来管理后台进程。
如果你在使用 -daemon
参数时遇到问题,或者你的 Kafka 安装版本不支持这个参数,你可以考虑使用以下替代方案之一来在后台启动 Kafka 服务器:
nohup
nohup bin/kafka-server-start.sh config/server.properties &
这将使 Kafka 服务器在后台运行,并且即使关闭终端或会话,它也会继续运行。
screen
或 tmux
这些工具允许你在单个终端会话中启动多个“窗口”或“会话”,并且即使你断开连接,这些会话也会继续运行。
bin/kafka-server-stop.sh stop
bin/
:这是 Kafka 安装目录中包含可执行脚本和程序的子目录。kafka-server-stop.sh
:这是 Kafka 提供的用于停止 Kafka 服务器的脚本文件。它的主要作用是向 Kafka 服务器进程发送一个停止信号,通常是通过查找 Kafka 服务器进程的 PID(进程ID)并发送一个 SIGTERM
或 SIGKILL
信号来实现的。stop
:这个参数在这个上下文中可能是不必要的,因为 kafka-server-stop.sh
脚本的主要目的就是为了停止 Kafka 服务器。然而,有些脚本可能支持额外的参数来提供额外的控制或行为,但这通常取决于 Kafka 的具体版本和安装环境。脚本会执行以下操作:
查找 Kafka 服务器进程:脚本会尝试定位 Kafka 服务器进程的 PID。这通常是通过查找与 Kafka 服务器相关联的日志文件、锁文件或使用进程列表命令(如 ps
)并匹配 Kafka 进程的名称或命令行参数来实现的。
发送停止信号:一旦找到 Kafka 服务器进程的 PID,脚本就会向该进程发送一个停止信号。默认情况下,这通常是 SIGTERM
信号,它允许 Kafka 服务器优雅地关闭,包括完成正在进行的请求、将日志数据刷新到磁盘等。然而,如果 Kafka 服务器没有响应 SIGTERM
信号,或者你需要立即停止它,脚本可能会发送 SIGKILL
信号。
等待进程退出(可选):有些版本的 kafka-server-stop.sh
脚本可能会等待 Kafka 服务器进程完全退出后才返回。这有助于确保 Kafka 服务器已经真正停止运行。
stop
参数在你的环境中不起作用,或者导致错误,尝试只运行 bin/kafka-server-stop.sh
而不带任何参数。kill
命令和 PID 来完成,但请谨慎操作,以免意外杀死其他重要进程。总之,bin/kafka-server-stop.sh stop
命令(或简化后的 bin/kafka-server-stop.sh
)是停止 Kafka 服务器的标准方式,但请注意 stop
参数可能不是必需的,具体取决于你的 Kafka 版本和安装环境。
bin/kafka-topics.sh --zookeeper hadoop102:2181 --create --replication-factor 3 --partitions 1 --topic first
bin/kafka-topics.sh
:
bin
子目录)下的一个脚本文件,用于管理 Kafka 主题。你可以使用它来创建、列出、描述、修改或删除主题。--zookeeper hadoop102:2181
:
hadoop102
这台机器上,监听的端口是 2181
。--create
:
kafka-topics.sh
脚本要执行的操作是创建一个新的主题。--replication-factor 3
:
--partitions 1
:
first
将只有一个分区。虽然只有一个分区限制了主题的并行处理能力,但它对于测试或低吞吐量场景可能是足够的。--topic first
:
first
。综上所述,这条命令的作用是在 Kafka 集群中创建一个名为 first
的新主题,该主题有 1 个分区,每个分区有 3 个副本,并且 Kafka 集群的元数据信息存储在 ZooKeeper 服务器 hadoop102:2181
上。
执行这条命令后,Kafka 集群将配置并启动所需的资源来支持这个新主题,包括在集群中分配分区和副本的存储位置。一旦主题创建成功,你就可以开始向它发送消息,并使用 Kafka 消费者从它读取消息了。
bin/kafka-topics.sh --zookeeper hadoop102:2181 --list
bin/kafka-topics.sh
:
bin
子目录)下的一个脚本文件,用于执行与 Kafka 主题相关的各种管理任务。你可以通过这个脚本来创建、列出、描述、修改或删除 Kafka 主题。--zookeeper hadoop102:2181
:
hadoop102
这台机器上,监听的端口是 2181
。通过连接到这个 ZooKeeper 实例,kafka-topics.sh
脚本能够获取 Kafka 集群的元数据信息。--list
:
kafka-topics.sh
脚本要执行的操作是列出 Kafka 集群中当前存在的所有主题。执行这个命令后,脚本将连接到指定的 ZooKeeper 服务器,查询并返回集群中所有主题的列表。综上所述,这条命令的作用是连接到 ZooKeeper 服务器 hadoop102:2181
,并列出 Kafka 集群中当前存在的所有主题。这对于查看集群中当前有哪些主题非常有用,尤其是在进行故障排查、资源规划或主题管理时。
bin/kafka-topics.sh --zookeeper hadoop102:2181 --delete --topic first
bin/kafka-topics.sh
:
bin
子目录)下的一个脚本文件,用于执行与 Kafka 主题相关的各种管理任务。--zookeeper hadoop102:2181
:
kafka-topics.sh
脚本能够获取 Kafka 集群的元数据信息,并执行相应的管理操作。--delete
:
kafka-topics.sh
脚本要执行的操作是删除一个主题。需要注意的是,Kafka 的默认配置(从 0.11.0.0 版本开始)是禁止通过 kafka-topics.sh
脚本删除主题的,因为这可能会导致数据丢失。如果你想要能够删除主题,你需要在 Kafka 服务器的配置文件中(通常是 server.properties
)设置 delete.topic.enable=true
。--topic first
:
first
。综上所述,这条命令的作用是连接到 ZooKeeper 服务器 hadoop102:2181
,并请求 Kafka 集群删除名为 first
的主题。但是,请记住以下几点:
delete.topic.enable=true
)。最后,需要注意的是,从 Kafka 2.4.0 版本开始,Kafka 引入了一个更安全的方式来删除主题,即使用 AdminClient API(通过 Kafka 命令行工具或编程方式)。这种方法提供了更多的控制和反馈,使得删除主题的过程更加可靠和透明。然而,kafka-topics.sh
脚本仍然是一种快速且方便的方式来删除主题(前提是已经启用了删除功能)。
6、发送消息
bin/kafka-console-producer.sh --broker list hadoop102:9092 --topic first
bin/kafka-console-producer.sh
:
bin
子目录)下的一个脚本文件,用于启动一个 Kafka 控制台生产者(console producer)。控制台生产者允许用户从命令行向 Kafka 主题发送消息。--broker-list hadoop102:9092
:
hadoop102
这台机器上的 Kafka broker,监听的端口是 9092
。需要注意的是,如果你有一个包含多个 broker 的 Kafka 集群,并且你想要提高生产者的容错性和负载均衡能力,你可以在这个参数中列出所有 broker 的地址和端口,用逗号分隔(例如:--broker-list hadoop102:9092,hadoop103:9092,hadoop104:9092
)。--topic first
:
first
。综上所述,这条命令的作用是启动一个 Kafka 控制台生产者,它连接到 Kafka 集群中位于 hadoop102:9092
的 broker,并向名为 first
的主题发送消息。用户可以在命令行中输入消息,每条消息按下回车键后都会被发送到 Kafka 主题中。这对于测试 Kafka 生产者、验证 Kafka 集群是否正常运行或进行简单的数据生产非常有用。
需要注意的是,这个命令会启动一个交互式会话,直到用户显式地终止它(例如,通过按下 Ctrl+C)。在会话期间,用户可以随时输入消息并发送到 Kafka 主题。
7、消费消息
bin/kafka-console-consumer.sh \ --zookeeper hadoop102:2181 --topic first
bin/kafka-console-consumer.sh
:这是 Kafka 安装目录(bin
子目录)下的一个脚本文件,用于启动一个 Kafka 控制台消费者(console consumer)。控制台消费者允许用户从命令行读取 Kafka 主题中的消息。
--zookeeper hadoop102:2181
:这个参数指定了 ZooKeeper 服务器的地址和端口。在较旧版本的 Kafka 中,消费者通过 ZooKeeper 来发现 Kafka broker 的信息。但是,随着 Kafka 的发展,这种方式已经被认为是不够高效和现代的,因为它增加了 ZooKeeper 的负载,并且不是 Kafka 消费者 API 的直接用法。
--topic first
:这个参数指定了消费者要读取消息的主题名称。在这个例子中,消费者将读取名为 first
的主题中的消息。
bin/kafka-console-consumer.sh \ --bootstrap-server hadoop102:9092 --topic first
bin/kafka-console-consumer.sh
:这是 Kafka 安装目录(bin
子目录)下的一个脚本文件,用于启动 Kafka 的控制台消费者程序。控制台消费者提供了一个简单的命令行界面,允许用户实时查看从 Kafka 主题中接收到的消息。
--bootstrap-server hadoop102:9092
:这个参数指定了 Kafka 集群中的一个或多个 broker(服务器)的地址和端口,用于建立初始连接。在这个例子中,它指向了 hadoop102
这台机器上的 Kafka broker,该 broker 监听的端口是 9092
。控制台消费者将使用这个地址来连接到 Kafka 集群,并从那里获取主题的信息和消息。如果 Kafka 集群中有多个 broker,可以在这个参数中列出它们,用逗号分隔,但通常只需要提供一个或多个可用于发现集群中其他 broker 的地址即可。
--topic first
:这个参数指定了消费者要读取消息的目标主题名称。在这个例子中,目标主题是 first
。控制台消费者将连接到 Kafka 集群,并订阅该主题,然后不断从该主题中读取消息,并将它们输出到控制台。
默认情况下,控制台消费者会读取主题中从最新消息开始的部分(即消费者启动后发送到主题的消息)。如果你想要从主题的起始位置开始读取消息,可以添加 --from-beginning
参数。
如果没有指定消费者组(通过 --group
参数),Kafka 会为控制台消费者自动分配一个唯一的消费者组 ID。在生产环境中,通常建议显式指定消费者组,以便能够控制和管理消费者实例的行为。
消费者将不断地从 Kafka 主题中读取消息,直到它被显式地终止(例如,通过按下 Ctrl+C)。
如果 Kafka 集群中有多个分区和多个副本,控制台消费者将只连接到它所能发现的分区领导者(leader),并从那里读取消息。Kafka 的内部机制确保了消息的可靠传递和容错性。
这条命令是在 Kafka 0.10.x 及更高版本中推荐使用的,因为它避免了直接通过 ZooKeeper 与 Kafka 集群进行交互,从而减少了 ZooKeeper 的负载,并提高了整体的性能和可靠性。
bin/kafka-console-consumer.sh \ --bootstrap-server hadoop102:9092 --from-beginning --topic first
bin/kafka-console-consumer.sh
:这是 Kafka 安装目录(bin
子目录)下的一个脚本文件,用于启动 Kafka 的控制台消费者程序。控制台消费者提供了一个简单的命令行界面,允许用户实时查看从 Kafka 主题中接收到的消息。
--bootstrap-server hadoop102:9092
:这个参数指定了 Kafka 集群中用于建立初始连接的 broker(服务器)的地址和端口。在这个例子中,它指向了 hadoop102
这台机器上的 Kafka broker,该 broker 监听的端口是 9092
。控制台消费者将使用这个地址来连接到 Kafka 集群,并从那里获取主题的信息和消息。
--from-beginning
:这个参数指示控制台消费者从主题的起始位置(即最早的消息)开始读取消息。默认情况下,如果不指定这个参数,消费者将从它连接时主题的当前偏移量(offset)开始读取消息,这通常是主题中最新的消息。使用 --from-beginning
参数可以确保消费者能够读取到主题中的所有历史消息。
--topic first
:这个参数指定了消费者要读取消息的目标主题名称。在这个例子中,目标是名为 first
的主题。控制台消费者将连接到 Kafka 集群,并订阅该主题,然后从该主题的起始位置开始不断读取消息,并将它们输出到控制台。
当使用 --from-beginning
参数时,如果主题中包含大量的历史消息,消费者可能需要一些时间才能追上最新的消息。这取决于消费者的处理能力、Kafka 集群的性能以及网络条件。
如果 Kafka 集群中有多个分区,控制台消费者将并行地从所有分区的起始位置开始读取消息。每个分区都会独立地维护其消息的顺序和偏移量。
这条命令是在 Kafka 0.10.x 及更高版本中推荐使用的,因为它避免了直接通过 ZooKeeper 与 Kafka 集群进行交互,从而减少了 ZooKeeper 的负载,并提高了整体的性能和可靠性。
在生产环境中,控制台消费者通常用于调试和监控目的,而不是作为长期运行的生产级消费者。对于生产级应用,建议使用 Kafka 客户端库(如 Kafka Java API)来编写自定义的消费者应用。
bin/kafka-topics.sh --zookeeper hadoop102:2181 --describe --topic first
bin/kafka-topics.sh
:这是 Kafka 安装目录(bin
子目录)下的一个脚本文件,用于管理和查询 Kafka 主题。通过这个脚本,用户可以创建、列出、修改或删除 Kafka 主题,以及查询主题的详细信息。
--zookeeper hadoop102:2181
:这个参数指定了 ZooKeeper 服务器的地址和端口。在 Kafka 0.10.x 之前的版本中,Kafka 客户端和工具(如 kafka-topics.sh
)经常需要通过 ZooKeeper 来与 Kafka 集群交互,因为 ZooKeeper 被用作 Kafka 集群的元数据存储和协调服务。在这个例子中,它指向了 hadoop102
这台机器上的 ZooKeeper 服务器,该服务器监听的端口是 2181
。
--describe
:这个参数告诉 kafka-topics.sh
脚本要执行的操作是描述(describe)一个或多个主题的详细信息。这包括主题的分区数、每个分区的副本因子、每个副本所在的 broker 的 ID、每个分区的 leader 副本和 ISR(In-Sync Replicas)列表等。
--topic first
:这个参数指定了要查询详细信息的主题名称。在这个例子中,要查询的主题是 first
。
执行这个命令后,你将会看到类似下面的输出(输出内容会根据实际的 Kafka 集群和主题配置而有所不同):
Topic:first PartitionCount:3 ReplicationFactor:2 Configs:
Topic: first Partition: 0 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: first Partition: 1 Leader: 2 Replicas: 2,3 Isr: 2,3
Topic: first Partition: 2 Leader: 3 Replicas: 3,1 Isr: 3,1
这个输出显示了 first
主题的详细信息,包括:
接下来,对于每个分区,输出还显示了:
--zookeeper
参数在较新版本的 Kafka 工具中可能不再是首选(因为 Kafka 客户端现在更倾向于直接与 Kafka broker 通信),但在某些管理和查询操作中,它仍然是有用的,特别是当你需要快速获取关于 Kafka 集群和主题的元数据时。bin/kafka-topics.sh --zookeeper hadoop102:2181 --alter --topic first --partitions 6
bin/kafka-topics.sh
:这是 Kafka 安装目录(bin
子目录)下的一个脚本文件,用于管理和查询 Kafka 主题。通过这个脚本,用户可以创建、列出、修改或删除 Kafka 主题。
--zookeeper hadoop102:2181
:这个参数指定了 ZooKeeper 服务器的地址和端口。在 Kafka 0.10.x 之前的版本中,Kafka 客户端和工具经常需要通过 ZooKeeper 来与 Kafka 集群交互,因为 ZooKeeper 被用作 Kafka 集群的元数据存储和协调服务。然而,从 Kafka 0.11.0.0 开始,Kafka 引入了对 Kafka AdminClient API 的支持,允许用户直接与 Kafka broker 交互以执行管理操作,而无需通过 ZooKeeper。不过,kafka-topics.sh
脚本仍然支持通过 ZooKeeper 进行操作,特别是在需要修改主题配置或元数据的场景中。在这个例子中,它指向了 hadoop102
这台机器上的 ZooKeeper 服务器,该服务器监听的端口是 2181
。
--alter
:这个参数告诉 kafka-topics.sh
脚本要执行的操作是修改(alter)一个已存在的主题。
--topic first
:这个参数指定了要修改的主题名称。在这个例子中,要修改的主题是 first
。
--partitions 6
:这个参数指定了要将主题的分区数修改为 6。请注意,增加主题的分区数是一个“扩展”操作,它不会删除现有的数据,而是将现有的数据分布到更多的分区中(在某些情况下,这可能需要重新平衡分区的数据)。然而,减少主题的分区数则是一个风险较高的操作,因为它可能会导致数据丢失(Kafka 不支持直接减少分区数)。
在执行这个命令之前,请确保 Kafka 集群中的 broker 能够处理额外的分区。这包括有足够的磁盘空间来存储新的分区数据,以及足够的处理能力来管理更多的分区。
增加分区数通常是为了提高主题的吞吐量或并行处理能力。然而,它并不会自动改善现有数据的读取性能,因为 Kafka 消费者通常需要根据分区来并行读取数据。
如果 Kafka 集群配置了自动主题创建(即 auto.create.topics.enable
设置为 true
),则当生产者向不存在的主题发送消息时,Kafka 会自动创建该主题,并使用默认的分区数和副本因子。但是,一旦主题被创建,就不能直接通过自动创建机制来修改其分区数。相反,需要使用 kafka-topics.sh
脚本或 Kafka AdminClient API 来手动修改。
随着 Kafka 的发展,官方可能会引入更高级的工具或 API 来管理 Kafka 主题和元数据。因此,建议查阅最新的 Kafka 文档以获取最准确的信息和最佳实践。