Kafka跑起来之后日常打交道最多的不是写代码而是一堆命令行脚本。很多同学在集群碰到问题第一反应是翻日志、抓堆栈其实大部分时候用自带的命令行工具就能把问题定位个七七八八。这篇作为Kafka系列第三篇专门把kafka命令操作这部分掰开揉碎从topic管理到消费组排查、从生产消费测试到动态配置把常用命令和背后的原理一次讲透。1. 命令行工具箱总览一台Kafka服务器上有哪些家底Kafka的脚本都在安装目录的bin目录下如果是用源码包或者二进制包解压的就是kafka_2.13-3.7.0/bin这一层。用ls bin看一眼你能发现十几个sh脚本名字都很直白基本是kafka-功能-动作.sh的命名规律。我平时用得最多的有这几种脚本用途典型场景kafka-topics.shtopic的增删改查建topic、扩分区、看分区状态kafka-console-producer.sh命令行生产数据测试连通性、灌测试数据kafka-console-consumer.sh命令行消费数据验证消息内容、调试offsetkafka-consumer-groups.sh消费组管理查积压、重置offset、删消费组kafka-configs.sh动态配置管理改topic保留时间、改broker参数kafka-reassign-partitions.sh分区重分配扩缩容节点、平衡磁盘负载kafka-dump-log.sh查看segment日志文件排查消息是否落盘、查看消息内容kafka-log-dirs.sh查看broker磁盘目录情况查副本在磁盘上的分布kafka-broker-api-versions.sh查看broker支持的API版本跨版本兼容性排查这里有一个很重要的背景知识新版Kafka2.x后期开始逐步过渡3.x已经全面实施里所有客户端相关命令都统一用--bootstrap-server来连接集群替代了老版本的--zookeeper参数。为什么因为老命令走ZooKeeper连接本质上是绕过Kafka自身的元数据接口去操作链路多了一层不说而且在KIP-500去掉ZooKeeper架构的目标下这种连接方式迟早要废弃。所以你现在看到的官方文档、各种告警日志里都会推荐用bootstrap-server方式。如果你在网上搜到老教程还在用--zookeeper localhost:2181除非你是维护一个很老的Kafka版本否则建议直接切换到新写法。另外一个容易混淆的点是--broker-list和--bootstrap-server。早期kafka-console-producer和消费者工具支持--broker-list指定broker列表新版本也兼容但官方一直在推动统一到--bootstrap-server。两者在功能上等价但broker-list思路更像连接某一个具体brokerbootstrap-server则是一组启动引导地址客户端会先连上任意一个broker再通过它拿到整个集群的元数据。实操里我遇到过用broker-list连一个已经挂掉的broker导致生产端报Connection refused的情况换成bootstrap-server传多个地址就好很多。所以建议一律用--bootstrap-server。2. Topic管理实操手册创建、查看、修改、删除Topic是Kafka最基础的数据组织单元。围绕topic的操作绝大多数都集中在kafka-topics.sh这个脚本上。它的子命令不多但每个参数都有讲究。2.1 创建Topic分区数和副本数怎么定创建topic的标准命令长这样kafka-topics.sh \ --bootstrap-server kafka01:9092,kafka02:9092,kafka03:9092 \ --create \ --topic my-topic \ --partitions 3 \ --replication-factor 2 \ --config retention.ms86400000三个必填参数--topic、--partitions、--replication-factor。新手最纠结的是分区数和副本数到底填多少。先说说分区数它决定了topic的最大并行度。一个分区在同一时刻只能被一个消费者线程消费所以如果你想让一个消费组用3个消费者并行处理那topic至少要有3个分区。分区数太少加再多消费者也是闲置分区数太多每个分区的文件句柄、内存buffer都有额外开销而且leader切换、副本同步的广播成本也跟着涨。我自己的经验型估算公式是峰值吞吐量除以单分区吞吐能力。假如单分区实测能扛住50MB/s的写入业务峰值需要300MB/s那6个分区基本够用再留点冗余可以做到8个。单分区吞吐怎么测最直接的办法就是用本篇文章后面的生产者命令去灌数据观察平均延迟和吞吐多试几组batch.size、linger.ms配置。如果业务吞吐模型不明朗宁可在初建时少给一点分区因为分区数后期可以改大只能增大不能减小反之就麻烦了。副本数就简单多了它决定了数据冗余的份数。replication-factor填几就表示leader和follower加起来一共几份副本。比如填3就是1个leader加2个follower。副本数越多容灾能力越强但每个副本都要同步leader的数据网络和磁盘开销也会成倍增长。最关键的限制是副本数不能大于集群里的broker数量。如果集群只有3台机器replication-factor填4命令会直接报Replication factor: 4 larger than available brokers: 3。生产环境我个人推荐关键业务至少副本数2能3最好单副本只适合测试环境。--config参数用来设置topic级别的动态配置比如这里设置保留时间retention.ms86400000就是消息保留24小时。它覆盖broker上的同项默认配置只对这个topic生效。常见能用--config设置的还有max.message.bytes单条消息大小上限、segment.bytes日志分段大小、cleanup.policy删除或压缩策略。如果创建时没配后面用kafka-configs.sh也能补不冲突。2.2 查看Topiclist和describe的区别看集群有哪些topic直接kafka-topics.sh --bootstrap-server kafka01:9092 --list这个输出的就是一行一个topic名称没什么花头。真正干活的是describerkafka-topics.sh --bootstrap-server kafka01:9092 --describe --topic my-topic输出示例Topic: my-topic Partition: 0 Leader: 1 Replicas: 1,2 Isr: 1,2 Topic: my-topic Partition: 1 Leader: 2 Replicas: 2,3 Isr: 2,3 Topic: my-topic Partition: 2 Leader: 3 Replicas: 3,1 Isr: 3,1这一列列字段是定位问题的主力工具。Partition不用说是分区编号Leader是指当前这个分区的主副本所在的broker idReplicas是该分区所有副本分布的broker集合Isr全称In Sync Replicas指当前和leader保持同步状态的副本集合。我用一个生活化类比来解释Replicas相当于一个班级的正式名单Isr是今天正常来上课的学生名单。Leader是班长数据写入只找班长班长挂了或者失联了就从Isr名单里选一个新班长。所以正常情况下Replicas和Isr是相等的当某个broker磁盘出问题、网络抖动或者GC卡死它的副本跟不上leader的写入它就会从Isr中移除。此时Isr数量小于Replicas说明集群存在副本同步隐患这是我巡检时优先关注的指标。如果describe后面不加--topic会把所有topic的分区元数据全列出来。topic数量多的时候刷屏很严重我一般很少那么干但偶尔排查分区leader是否分布均匀时会用它把输出重定向到文件再用awk统计每个broker上做了多少个leader。顺带提一句describe信息里看不到消息条数和消息大小如果想看写入量可以用kafka-log-dirs.sh或者走监控面板命令行层面没有直接的消息总数命令这是很多新人的认知误区。2.3 修改Topic扩展分区和变更配置的坑最常见的修改操作是扩分区kafka-topics.sh --bootstrap-server kafka01:9092 --alter --topic my-topic --partitions 6注意两点。第一这个操作只能增加不能减少。为什么因为消息按照key的哈希被分配到某个分区分区数变了以后如果减少分区老的key到分区的映射关系直接错乱你没法保证旧数据所在的partition还在哈希范围内。Kafka官方干脆就禁止了减少分区。所以在建topic时分区数一定要往大里想。第二扩分区后已有的消息还在老分区里新消息才会往新增分区里写如果消息带key那么老key的映射规则会变化这可能导致同一key的消息被打散到新老分区对顺序性有要求的业务需要提前评估。改topic配置有两条路。一条是创建时用--config另一条就是alter加--configkafka-topics.sh --bootstrap-server kafka01:9092 --alter --topic my-topic --config retention.ms172800000这个命令会把retention.ms从原本的24小时改成48小时。如果想删除某个topic级配置、让它重新继承broker默认值用--delete-config retention.ms。顺便说一个排查教训之前某个topic消息堆积在磁盘上删不掉怎么设置cleanup.policy都不生效最后发现是因为另一个team用alter命令设了segment.ms和segment.bytes导致segment文件太大了日志清理器要等segment滚动之后才可能触发清除。这类配置组合问题盯着单个参数看是看不出来的。删除topic就一条命令kafka-topics.sh --bootstrap-server kafka01:9092 --delete --topic my-topic但前提条件有两个broker端delete.topic.enabletrueKafka 3.x默认就是true并且集群处于正常状态。删除后topic不会立刻消失它先在控制台日志里标记为待删除等元数据传播到所有broker后才真正清理数据文件。如果删除命令报错或者删除状态卡住检查一下kafka-logs目录下对应topic的文件是否还在有时候需要重启broker才能彻底清掉。2.4 一个容易踩的坑命令同时传--zookeeper和--bootstrap-server新版Kafka的kafka-topics.sh有两种连接模式--bootstrap-server和--zookeeper可以分开用但绝对不要同时传两个。我自己见过最拧巴的报错是有人传了--bootstrap-server localhost:9092 --zookeeper localhost:2181 --create --topic test结果直接抛More than one of --bootstrap-server or --zookeeper can be specified。旧脚本的代码逻辑里这两个参数互斥传了就是非法参数。类似地很多老版本的参数比如--replica-assignment在新版本里虽然还在但官方已经标记deprecated能用简单方式搞定的事没必要用冷门姿势。3. 生产消费测试用命令行验证数据链路写完topic之后下一步一定要做一次生产消费验证。命令行消息工具就是干这个的虽然看着简单但它是排查Kafka连通性问题最快的手段。3.1 kafka-console-producer.sh给Kafka灌数据基础命令kafka-console-producer.sh \ --bootstrap-server kafka01:9092 \ --topic my-topic \ --property parse.keytrue \ --property key.separator::不带--property时它每读一行就当作一条value消息不带key发送适合快速验证链路。带了parse.keytrue和key.separator::后每行的格式是key::value比如输入user1::hello它会把user1作为消息key、hello作为value。这个在测试相同key路由到同一分区的场景下很有用。发送端还有一个重要参数是--producer-property可以在命令行直接设置生产者配置比如kafka-console-producer.sh \ --bootstrap-server kafka01:9092 \ --topic my-topic \ --producer-property acksall \ --producer-property linger.ms50解释一下为什么这几个参数值得关注。acksall表示生产者要等所有ISR副本都确认写入才返回成功这是最强的一致性保证但也带来更高的延迟。我做连通性测试时通常会开acksall因为只要能成功写进去就说明broker和副本同步链路都是通的。linger.ms是消息在本地攒批等待的时间适当调大能让吞吐量明显变高比如从默认的0调到10~50batch中消息更多网络效率更高。这工具的本质就是一个没做业务包装的KafkaProducer你在代码里能配置哪些producer参数它大多都能通过--producer-property透传。3.2 kafka-console-consumer.sh验证数据有没有进去消费端常用命令kafka-console-consumer.sh \ --bootstrap-server kafka01:9092 \ --topic my-topic \ --from-beginning \ --group test-group \ --property print.keytrue \ --property print.partitiontrue \ --max-messages 10这里有一堆细节值得说。--from-beginning的意思是如果当前消费组还没有提交过offset就从该分区最早的消息开始消费。这属于无中生有逻辑——它决定的是初始消费位置而不是每次都从头读。如果你用同一个消费组名反复跑这个命令第二次运行时group已经提交了offset就不会再从头读了。想强制重新从头读需要用到后面小节说的重置offset命令。--max-messages 10也很实用消费10条后自动退出适合快速验证topic里有没有数据。如果不加它会一直挂着等待新消息看起来就像卡死了一样实际是在轮询拿消息。--property print.partitiontrue会在输出里带出分区号验证带key的消息是否一直进同一个分区时非常好用输出长这样[user1my-topic-0] hello [user1my-topic-0] world看到分区号始终是0等于直接验证了key哈希路由逻辑。还有一个老生常谈的问题消费工具连不上broker时最常见的报错是Connection refused或者TimeoutException第一反应就是去看--bootstrap-server的地址和端口能不能telnet通。很多时候不是Kafka进程挂了而是安全组规则、防火墙iptables封了9092端口或者服务器只监听了127.0.0.1没有监听对外网卡。用ss -lntp | grep 9092看一下监听地址大概率能秒定位。3.3 security协议和SASL认证怎么办如果集群开启了认证命令行工具要额外传认证相关参数kafka-console-producer.sh \ --bootstrap-server kafka01:9092 \ --topic secured-topic \ --producer-property security.protocolSASL_PLAINTEXT \ --producer-property sasl.mechanismPLAIN \ --producer-property sasl.jaas.configorg.apache.kafka.common.security.plain.PlainLoginModule required username\myuser\ password\mypass\;没有认证参数的集群这么传反而是报错源头。见过太多人拿着生产环境的命令模板直接去测试环境跑结果测试环境没开SASL命令直接报Invalid security protocol之类的问题。出现认证相关报错时先用--bootstrap-server localhost:9092 --topic foo --list这种最朴素的命令排除安全配置干扰再追加认证参数一层层排查。4. 消费组与Offset管理积压排查和重置位移生产环境里Kafka命令用得最多的场景除了建topic就是看消费组积压、重置消费位置。这两件事全都落在kafka-consumer-groups.sh身上。4.1 查看消费组列表和消费明细kafka-consumer-groups.sh --bootstrap-server kafka01:9092 --list输出一行一个消费组名。如果加了--state参数还可以按状态过滤。要查某个消费组的详细消费进度kafka-consumer-groups.sh \ --bootstrap-server kafka01:9092 \ --describe \ --group test-group这个命令的输出是我日常巡检的照妖镜。每个分区一行核心字段如下GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID test-group my-topic 0 1000 1200 200 consumer-1 /192.168.1.10 consumer-1几个字段含义CURRENT-OFFSET是这个消费组当前消费到的位置LOG-END-OFFSET是分区最新的消息位移也就是最新消息的offset1可以理解为最新写到的位置LAG是两者之差表示还有多少条消息没消费掉。LAG为0说明消费跟上了生产LAG持续增长说明消费速度跟不上写入速度或者消费者实例太少。这里有个新手容易误读的点CURRENT-OFFSET不一定代表单条消息的消息序号它代表的是下一条要消费的消息的offset。如果CURRENT-OFFSET1000说明offset 0到999都已经被消费并提交了。所以LAG的计算公式是LOG-END-OFFSET - CURRENT-OFFSET减去的是CURRENT-OFFSET不是CURRENT-OFFSET1这一点搞反了会差出1条。之前排查一个消费组LAG一直显示1业务同事以为是积压了一条消息其实那只是正常提交的偏移边界不算消息积压。4.2 消费组状态解释describe输出最后还有一列STATE有时是单独一行GROUP STATE字段消费组有四种状态Empty没有任何活跃消费者Stable消费者都正常正在稳定消费PreparingRebalance / CompletingRebalance正在触发rebalance有消费者加入或离开Dead消费组已经超时或者被删除这些状态对排查很有用。比如消费组一直处于PreparingRebalance却不进入Stable说明消费者在无限循环加入退出最常见的诱发原因是消费者session.timeout.ms设置太短或者消费者的处理逻辑太慢导致心跳超时。如果查看状态是Empty又发现LAG很大说明没有消费者在消费这个组的数据业务侧要查自己的消费进程是不是挂了。4.3 重置Offset把消费位置拉回去或跳过去重置offset是一个高风险但高价值的操作。典型场景消费逻辑写错了消费了一批脏数据需要把消费位置重置到某个时间点重新消费或者消费组堆积太多干脆跳过前面的消息从最新开始消费。重置命令格式kafka-consumer-groups.sh \ --bootstrap-server kafka01:9092 \ --group test-group \ --topic my-topic \ --reset-offsets \ --to-earliest \ --execute--reset-offsets后面的策略可以选很多种策略参数含义--to-earliest重置到最早可用offset--to-latest重置到最新offset跳过所有老消息--to-offset 1000重置到指定offset值--shift-by -100当前提交位置往前移100条负数往前走--to-datetime 2024-01-01T00:00:00.000重置到某个时间点之后的第一条消息这里最容易出错的是重置操作分两步先带--dry-run预览再带--execute真正执行。如果你不加--execute和不加--dry-run命令会报错要求二选一。我习惯是先跑一遍dry-run看清楚每个分区的offset会落到哪个值确认后再execute免得一个手滑把生产消费位重置到beginning导致大面积重放。决定重置能否成功有一个硬性前提目标消费组必须是inactive状态也就是当前没有活跃消费者实例连接。如果消费组是Stable或者PreparingRebalance重置会直接报错提示不能执行。所以在重置之前要么停掉对应的消费者应用要么先确认消费组状态是Empty否则白忙活。去掉--topic限制可以重置这个消费组订阅的所有topic也可以加多个--topic做批量操作。但统计一下就知道重置offset是按topicpartition来执行的每个分区单独算目标位置所以如果你订阅的topic分区特别多输出会很长建议加上--execute后在屏幕上直接核对关键分区的结果。4.4 删除消费组等下消费组状态是Dead或者Empty时可以删掉kafka-consumer-groups.sh --bootstrap-server kafka01:9092 --delete --group test-group删除的前提是消费组没有活跃成员。如果报错The group is not empty之类的检查是不是还有消费者在跑。删除后该消费组之前提交的offset元数据也会一起清掉下次用同一个组名启动消费者时会从auto.offset.reset策略决定的位置开始消费默认latest。顺带分享一个实战场景线上某个消费组不再使用了但它的offset元数据一直占用着coordinator内存手动删除消费组前我一般会先describe看一下最后消费位置做个备份再删。虽然事后可以通过重置offset还原但需要知道最后位置是多少才有依据先备份总是稳妥的。5. 配置管理与运维进阶技巧日常运维除了topic和消费组还有一个很容易被忽略但非常好用的工具kafka-configs.sh。它专门管理动态配置可以在不重启broker的情况下动态改各种参数。5.1 kafka-configs.sh动态配置的增删查查看某个topic的动态配置kafka-configs.sh --bootstrap-server kafka01:9092 --entity-type topics --entity-name my-topic --describe输出类似Dynamic configs for topic my-topic are: retention.ms172800000这里有个概念需要明确动态配置和静态配置是两回事。静态配置写在server.properties里改完要重启broker生效动态配置是通过命令直接写入ZooKeeper或者KRaft元数据里的不需要重启。动态配置优先级高于静态配置也就是说同一个参数如果动态配置设置了值静态配置的同名值就不起作用了。这既是便利也是陷阱——某次我们排查一个topic消息保留时间异常发现server.properties里明明写的7天但topic就是2天就被删最后定位是有人用kafka-configs.sh把retention.ms动态改成了172800000动态配置覆盖了静态配置排查了半天才找到根源。除了topic还能管理broker级别的动态配置kafka-configs.sh --bootstrap-server kafka01:9092 --entity-type brokers --entity-name 1 --describe比如动态调整某个broker的leader.replication.throttled.rate做限速迁移或者调整num.io.threads都属于这类。用--alter --add-config keyvalue,key2value2可以添加多个配置用--alter --delete-config key删除某个配置。5.2 常见Topic级动态配置我整理一个常用的配置速查表配置项作用使用场景retention.ms消息保留时间毫秒缩短或延长数据保留周期retention.bytes分区保留的最大字节数限制磁盘占用量max.message.bytes单条消息的最大字节数传输大消息时不落盘被拒segment.bytes日志段文件滚动大小调整日志分段粒度cleanup.policydelete / compact切换删除和压缩策略min.insync.replicas最少同步副本数配合acksall保证写入可用强调一下min.insync.replicas。它表示当生产者设置acksall时至少要有多少个ISR副本确认写入才成功。如果ISR数量低于这个值生产请求会报NotEnoughReplicasException。很多高可用场景会把这个值设为2保证写入时至少有两份数据落盘但代价是如果只剩1个broker可用写入就直接失败而不是降级。业务能接受少一个broker就停写才能设2否则默认1就好。5.3 kafka-dump-log.sh直接看日志段文件有时候要排查某条消息到底有没有写进Kafka有没有落盘最直接的办法是打开segment文件查看。Kafka的消息不是存在数据库里而是分片写在磁盘上的日志文件里每个分区一个目录目录下是.log和.index文件。用下面命令可以解析某个日志段文件kafka-dump-log.sh --files /data/kafka-logs/my-topic-0/00000000000000000000.log输出会列出每条消息的offset、timestamp、key、value长度等信息。生产环境排查消息为什么丢时这招比任何日志都好用——你可以直接确认这条消息确实已经持久化到某个分区的日志文件里。附带说一句.log文件别看后缀和日志一样它是二进制格式直接cat是乱码必须用这个命令解析。5.4 kafka-reassign-partitions.sh手动搬分区当集群扩容新broker、或者发现某台broker磁盘使用率异常高时可以用分区重分配把一些分区迁到别的broker上。第一步先生成一个重分配计划kafka-reassign-partitions.sh \ --bootstrap-server kafka01:9092 \ --generate \ --topics-to-move-json-file topics.json \ --broker-list 1,2,3topics.json格式{topics:[{topic:my-topic}],version:1}generate命令会输出一个建议的迁移方案JSON但不直接执行。第二步确认方案后把这个JSON存成reassignment.json然后执行kafka-reassign-partitions.sh \ --bootstrap-server kafka01:9092 \ --execute \ --reassignment-json-file reassignment.json第三步是监控进度kafka-reassign-partitions.sh \ --bootstrap-server kafka01:9092 \ --verify \ --reassignment-json-file reassignment.jsonverify输出显示全部分区完成迁移才算结束。分区重分配过程中副本同步会占用带宽如果业务对延迟敏感建议配合--throttle参数限速比如--throttle 50000000限制迁移速度为50MB/s避免影响正常业务流量。6. 常见问题排查实录命令行踩坑汇总命令行用久了踩过的坑都能拍一部连续剧。我按概率高低整理一份问题速查表都是真实碰到过的场景。现象可能原因排查/解决路径创建topic报Replication factor larger than available brokers副本数大于在线broker数检查集群broker是否全部启动确认在线broker数量调小replication-factordelete topic后长时间不消失delete.topic.enablefalse改broker配置为true并重启或手动删除磁盘目录但需谨慎运行Kafka命令报Connection refusedbootstrap-server地址写错或端口不通telnet测端口ss -lntp确认监听地址运行命令报Broker may not be availablebroker元数据还没同步等几十秒重试或检查broker日志是否有启动异常重置offset后消费没有从头开始消费组状态非Empty重置未生效确认没有活跃消费者实例describe查state控制台消费者只看到新消息没看到历史消息group已经提交过offsetfrom-beginning不生效换新group名或重置offset到earliest消费者LAG一直增长但不为0消费者处理慢或消费者实例数小于分区数增加消费者实例检查消费者CPU、GC、下游存储耗时消费者显示Stable但LAG不下降单条消息处理耗时过长用jstack看消费者线程或压低消费并发时观察describe看不到leader信息broker正在重分配或leader选举中等选举完成再describe检查broker.log里是否有leader相关异常再来一条非常常见的控制台消费者工具退出后再用同group重跑不会从头消费。很多人以为命令退出了group就没了offset就没了其实offset提交是持久化的。Kafka的设计就是group的进度不能因为消费者退出就丢否则每次重启应用都要全量重放这在生产是不可接受的。所以测试环境里想反复从头消费别用同一个group名换个随机名最省心。另一个高频问题命令行中文乱码或者特殊符号发送错误。这通常是因为客户端的默认序列化器对中文字符集处理跟终端编码不一致。命令行工具本质上走的是StringSerializer依赖JVM默认字符集在Linux下通常是UTF-8一般没问题但如果你在Windows的cmd里跑默认GBK就会乱码。解决方式就是统一把终端编码改成UTF-8或者用--property显式指定编码相关配置但命令行层面没有直接的编码参数所以更推荐改终端环境变量。最后是安全类报错SASL authentication failed或者Invalid credentials。看到这类报错先确认bootstrap-server地址是否连对了集群连错环境是最常见的再确认认证用户名密码是否正确最后确认服务器端允许的sasl.mechanism和你传的是否一致。没开认证的环境传了认证参数或者反过来都会得到莫名其妙的报错。一些实操体会我在实际维护Kafka集群的过程中最大的感受是命令行工具不只是能用就行的小工具它是排查问题的第一道眼睛。很多人遇到线上消息积压、数据不一致第一反应就是翻代码、翻日志但往往用kafka-consumer-groups.sh describe看一眼LAG和消费状态问题原因就浮出水面了。所以建议把常用命令整理成自己的速查笔记没事就敲两遍熟能生巧。最后再分享一个压箱底的小技巧Kafka所有命令行脚本都支持--help参数比如kafka-topics.sh --help会列出该工具支持的全部参数说明。记不住参数的时候别去翻网页直接帮忙敲--help官方说明永远是最准确的。另外Kafka 3.x的脚本对参数校验非常严格某个参数拼错了它不会自动忽略而是直接报错退出所以看到报错信息别慌仔细读一读提示很多时候就是你传了一个两个互斥参数或者漏传了必填项。这一篇主要把命令行操作过了一遍下一篇可以聊聊Kafka服务端的核心配置项调优把server.properties里那些参数一个一个讲透。
