linux kafka常用命令

启动：bin/zookeeper-server-start.sh config/zookeeper.properties

创建topic：

    kafka版本 < 2.2：bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

    kafka版本 >= 2.2：bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test

查看已有topic：> bin/kafka-topics.sh --list --zookeeper localhost:2181

发送消息：bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

查看收到到的消息：bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning

消费消息：

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test  （表示从 latest 位移位置开始消费该主题的所有分区消息，即仅消费正在写入的消息）

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic test（从指定主题中有效的起始位移位置开始消费所有分区的消息）

kafka集群情况下，一般一个服务对应一个副本。

设置多个副本数：bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic test

设置分区：./bin/kafka-topics.sh --alter --zookeeper localhost:2181 --topic test --partitions 8

查看每个集群副本：> bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group groupid

 ####详细说明

LogEndOffset 下一条将要被加入到日志的消息的位移

CurrentOffset 当前消费的位移

LAG 消息堆积量

消息堆积量：消息中间件服务端中所留存的消息与消费掉的消息之间的差值即为消息堆积量也称之为消费滞后量

处理 rebalance 问题，先搞清楚 kafaka 消费者配置的四个参数：

session.timeout.ms 设置了超时时间
heartbeat.interval.ms 心跳时间间隔
max.poll.interval.ms 每次消费的处理时间
max.poll.records 每次消费的消息数
session.timeout.ms 表示 consumer 向 broker 发送心跳的超时时间。例如 session.timeout.ms = 180000 表示在最长 180 秒内 broker 没收到 consumer 的心跳，那么 broker 就认为该 consumer 死亡了，会启动 rebalance。

heartbeat.interval.ms 表示 consumer 每次向 broker 发送心跳的时间间隔。heartbeat.interval.ms = 60000 表示 consumer 每 60 秒向 broker 发送一次心跳。一般来说，session.timeout.ms 的值是 heartbeat.interval.ms 值的 3 倍以上。

max.poll.interval.ms 表示 consumer 每两次 poll 消息的时间间隔。简单地说，其实就是 consumer 每次消费消息的时长。如果消息处理的逻辑很重，那么市场就要相应延长。否则如果时间到了 consumer 还么消费完，broker 会默认认为 consumer 死了，发起 rebalance。

max.poll.records 表示每次消费的时候，获取多少条消息。获取的消息条数越多，需要处理的时间越长。所以每次拉取的消息数不能太多，需要保证在 max.poll.interval.ms 设置的时间内能消费完，否则会发生 rebalance。

简单来说，会导致崩溃的几个点是：

消费者心跳超时，导致 rebalance。
消费者处理时间过长，导致 rebalance。