initLimit 表示用于在从节点与主节点之间建立初始化连接的时间上限。

syncLimit 表示允许从节点与主节点处于不同步状态的时间上限。

这两个值都是 tickTime 的倍数，tickTime 默认为 2000 毫秒，也就是 2 秒。

Server.ID=hostname:peerPort:leaderPort。

2.2 安装 Kafka Broker

启动 Kafka

Apache Kafka 可以使用 ZooKeeper 或 KRaft 启动。要开始使用任何一种配置，请遵循以下一节，但不要同时遵循这两节。

bin/kafka-server-start.sh config/server.properties.

在公司使用的版本是 2.13-3.3.1（Windows 环境），ZooKeeper 没有启动的情况下 Kafka 启动报错，看来默认还是使用 ZooKeeper 存放元数据的。不清楚是操作系统导致的这个问题？回去需要试一下 Linux 环境下的情况，好像用 kRaft 模式需要在配置文件做一些设置？？？

创建 Topic

./kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092

这里，--bootstrap-server 用的是 Kafka 内置的，--zookeeper 使用的是 zookeeper 存放元数据。

官方推荐如果 kafka 版本大于等于 2.2 使用 --bootstrap-server 替代 --zookeeper 。

目前使用的是 2.13版本（Linux 环境），使用 --zookeeper 参数报错，据查到的信息来看是高版本不支持 zookeeper 了。

显示 Topic

./kafka-topics.sh --describe --bootstrap-server localhost:9092 [--topic quickstart-events]

显示 Kafka Topic 列表：./kafka-topics --bootstrap-server localhost:9092 --list

写入事件到 Topic 

./kafka-console-producer.sh --topic quickstart-events  --bootstrap-server localhost:9092

读取事件

./kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092

2.3 broker 配置

2.1.1 常规设置

1. broker.id

默认值为 0，可以被设置为任意整数。这个值在集群中必须是唯一的。

2. port

默认监听 9092 端口。

3. zookeeper.connect

配置保存 broker 元数据的 Zookeeper 地址。

例如： localhost:2181/path。/path 是可选的路径，作为 Kafka 集群的 chroot 环境，默认为根路径。如果指定的 chroot 不存在，broker 启动时会创建。

4. log.dirs

存放日志片段的目录是通过 log.dirs 指定的，一组用分号分隔的本地文件系统路径。broker 根据“最少使用”原则，把同一个分区的日志片段放在同一个路径下。broker 看的是最少分区，而不是磁盘空间。

5. num.recovery.threads.per.data.dir

Kafka 会使用可配置的线程池处理日志片段。

　　1）正常启动，打开每个分区的日志片段；

　　2）崩溃后重启，检查和截短每个分区的日志片段；

　　3）正常关闭，关闭日志片段；

默认情况下，一个日志目录一个线程。

这里所配置的数字对应的是 log.dirs 指定的单个日志目录。

6. auto.create.topics.enable

默认情况下，在如下几种情形下会自动创建主题：

　　1）当一个生产者开始往主题写入消息时；

　　2）当一个消费者开始从主题读取消息时；

　　3）当任意一个客户端向主题发送元数据请求时。

2.3.2 主题的默认配置

1. num.partitions

指定新创建的主题包含多少个分区。

我们可以增加分区的个数，但不能减少。

如何选定分区数量：如果可以估算出主题的吞吐量和消费者吞吐量，那么可以：分区个数 = 主题吞吐量 / 消费者吞吐量。如果不知道这些信息，把分区大小限制在 25GB 以内可以获得比较理想的效果。

2. log.retention.ms

配置消息可以保存多久。默认使用：log.retention.hours=168，也就是一周。

可以配置的有：log.retention.hours，log.retention.minutes，log.retention.ms。

如果配置了多个，使用具有最小值的那个参数。

原理：通过检查日志片段文件的最后修改时间实现的，一般指的是日志片段的关闭时间，也就是最后一个消息的时间戳。

3. log.retention.bytes

通过保留的字节数判断消息是否过期。其值作用在每一个分区上。

假设有 1 个主题 8 个分区，配置为 1 GB，那么这个主题可以保留 8 GB。

如果同时配置了上面两个参数，那么任意一个满足就会删除消息。

4. log.segment.bytes

配置日志片段的大小上限。如果达到了，那么这个日志片段就会被关闭，一个新的日志片段会被打开，被关闭的日志片段开始等待过期。

5. log.segment.ms

配置日志片段关闭时间。

6. message.max.bytes

限制单个消息的大小，默认值是 1 MB。

如果消息超过了这个大小，不仅消息不会被接收，还会收到 broker 返回的错误信息。这里指的是压缩后的消息大小。

该值对性能有显著影响。

2.4 硬件的选择

2.4.1 磁盘吞吐量

生产者客户端的性能直接收到服务器端磁盘吞吐量的影响。

传统的机械硬盘（HDD）还是固态硬盘（SSD）。可以使用机械硬盘设置成磁盘阵列。

2.4.2 磁盘容量

需要多大的容量取决于需要保留的消息数量。

2.4.3 内存

除了磁盘性能，服务器端可用内存容量是影响客户端性能的主要因素。

内存影响消费者。

2.4.4 网络

网络吞吐量决定了能处理的最大数据流量。

影响因素：多个消费者、集群复制、镜像。

2.4.5 CPU

对计算能力要求相对较低，不是主要考虑因素，主要用于消息的压缩和解压。

2.5 云端的 Kafka

根据 Kafka 的性能优先级选择合适的实例。

可以从要保留数据的大小开始考虑，然后考虑生产者方面的性能，如果要低延迟就需要有固态硬盘的实例。

2.6 Kafka 集群

好处：

　　1）跨服务器进行负载均衡；

　　2）使用复制功能避免单点故障造成的数据丢失。

2.6.1 需要多少个 broker

考虑因素：

　　1）需要多少磁盘空间保留数据，以及单个 broker 有多少空间可用。

　　2）集群处理请求的能力。如果集群启用了复制功能，那么要把这个潜在的客户端考虑在内。因为磁盘吞吐量低和系统内存不足造成的性能问题，可以通过扩展多个 broker 解决。

2.6.2 broker 配置

只需要配置两个参数：

　　1）所有 broker 需要配置相同的 zookeeper.connect；

　　2）为每个 broker 配置唯一的 broker.id。

2.6.3 操作系统调优

2.7 生产环境的注意事项

2.7.1 GC 选项

G1 垃圾回收器的两个调整参数：

　　1）MaxGCPauseMillis： 指定垃圾回收默认的停顿时间。该值不是固定的。默认值是 200 ms。

　　2）InitiatingHeapOccupancyPercent：启动新一轮垃圾回收之前可以使用的堆内存百分比，默认为 45。包括了新生代和老年代。

Kafka 对堆内存的使用率非常高，容易产生垃圾对象，可以把值设的小一些。

2.7.2 数据中心布局

最好把 broker 安装在不同的机架上，至少不要让它们共享可能出现单点故障的基础设施，比如电源和网络。

2.7.3 共享 Zookeeper

使用 Zookeeper 保存 broker、主题和分区的元数据信息。对于 Zookeeper 集群来说，这些流量不多。

在实际中的很多部署环境中，会让多个 Kafka 集群共享一个 Zookeeper 集群，每个集群使用一个 chroot 路径。

建议使用新版的 Kafka 时让消费者把偏移量提交到 Kafka 服务器上，消除对 Zookeeper 的依赖。

多个 Kafka 集群共享一个 Zookeeper 集群，不建议再让别的应用共享 Zookeeper 集群。