Kafka入门实战教程（8）：常用的shell工具脚本

1 Kafka提供的命令行脚本

Kafka默认提供了多个命令行脚本，用于实现各种各样的功能和运维管理。从2.2版本开始，提供了多达30+个Shell脚本。

今天我们来看一些其中比较实用的Shell脚本。

2 生产消费测试脚本

这恐怕是我们最常用到的工具脚本了，没有之一。

生产消息

生产消息使用kafka-console-producer脚本，典型命令如下：

kafka-console-producer.sh --broker-list kafka1:9091,kafka2:9092,kafka3:9093 --topic testtopic --request-required-acks -1 --producer-property compression.type=lz4>

这里指定了producer参数acks为-1，同时开启LZ4压缩算法，这个脚本可以很方便地使用控制台来向Kafka的指定主题发送消息。

消费消息

如果想要快速地消费某个主题中的数据来验证消息是否存在，我们可以使用kafka-console-consumer脚本来实现，典型命令如下：

kafka-console-consumer.sh --bootstrap-server kafka1:9091,kafka2:9092,kafka3:9093 --topic testtopic --group test-group --from-beginning --consumer-property enable.auto.commit=false

这里指定了group id，还指定了from-beginning表名从头开始消费，最后禁用了自动提交位移。

3 性能测试脚本

想要对producer或consumer进行一下简单的压力测试，这组脚本值得关注。

生产者压测

对生产者进行压测使用kafka-producer-perf-test脚本。

首先，创建一个测试topic，设置为3个分区3个副本：

kafka-topics.sh --create --zookeeper zookeeper:2181/kafka --replication-factor 3 --partitions 3 --topic test

然后，对生产者进行压力测试：

kafka-producer-perf-test.sh --topic test --num-records 1000000 --throughput 1 --record-size 512 --producer-props bootstrap.servers=kafka1:9091,kafka2:9092,kakfa3:9093 acks=-1 linger.ms=0 compression.type=lz4

这里我们向测试主题发送了100万条消息，每个消息大小为512B，同时也指定了压缩算法为LZ4，acks为-1，linger.ms=0。

它的输出信息打印了producer的吞吐量（MB/s）、消息发送时延以及各种分位数下的演示。

2175479 records sent, 435095.8 records/sec (424.90 MB/sec), 131.1 ms avg latency, 681.0 ms max latency.
4190124 records sent, 838024.8 records/sec (818.38 MB/sec), 4.4 ms avg latency, 73.0 ms max latency.
10000000 records sent, 737463.126844 records/sec (720.18 MB/sec), 31.81 ms avg latency, 681.00 ms max latency, 4 ms 50th, 126 ms 95th, 604 ms 99th, 672 ms 99.9th.

这里，我们可以重点关注99th分位，它代表的是在producer压测中，有99%的消息的延时都在604ms以内。是不是和我们熟知的TP99概念差不多啊，这个数据也可以作为SLA。

消费者压测

对消费者进行压测使用kafka-consumer-perf-test脚本，典型命令如下：

kafka-consumer-perf-test.sh --broker-list kafka1:9091,kafka2:9092,kakfa3:9093 --messages 10000000 --topic test
start.time, end.time, data.consumed.in.MB, MB.sec, data.consumed.in.nMsg, nMsg.sec, rebalance.time.ms, fetch.time.ms, fetch.MB.sec, fetch.nMsg.sec
2019-06-26 15:24:18:138, 2019-06-26 15:24:23:805, 9765.6202, 1723.2434, 10000000, 1764602.0822, 16, 5651, 1728.1225, 1769598.3012

它的输出信息中虽然也有consumer的吞吐量比如上例中的1723MB/s，但令人遗憾的是，它没有计算不同分位数下的分布情况。