【kafka实践】03｜kafka最重要的配置

叁戒

已于 2023-11-14 10:09:20 修改

阅读量60

点赞数

分类专栏： kafka学习与实践文章标签： kafka 分布式

于 2023-11-12 16:44:02 首次发布

本文链接：https://blog.csdn.net/u012203062/article/details/134362217

版权

kafka学习与实践专栏收录该内容

12 篇文章 1 订阅

订阅专栏

Broker 端参数

log.dirs：这是非常重要的参数，指定了 Broker 需要使用的若干个文件目录路径。要知道这个参数是没有默认值的，这说明什么？这说明它必须由你亲自指定。
log.dir：注意这是 dir，结尾没有s，说明它只能表示单个路径，它是补充上一个参数用的。
listeners：学名叫监听器，其实就是告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务。
advertised.listeners：和 listeners 相比多了个 advertised。Advertised 的含义表示宣称的、公布的，就是说这组监听器是 Broker 用于对外发布的。
host.name/port：列出这两个参数就是想说你把它们忘掉吧，压根不要为它们指定值，毕竟都是过期的参数了。
log.retention.{hours|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hours 最低。
log.retention.bytes：这是指定 Broker 为消息保存的总磁盘容量大小。
message.max.bytes：控制 Broker 能够接收的最大消息大小。默认的 1000012 太少了，还不到 1MB，可以根据情况调大。

如果设置了log.dirs，就不要设置log.dir。而且更重要的是，在线上生产环境中一定要为log.dirs配置多个路径，具体格式是一个 CSV 格式，也就是用逗号分隔的多个路径，比如/home/kafka1,/home/kafka2,/home/kafka3这样，如果有条件的话可以将这些目录挂载到不同的物理磁盘上，这样做有两个好处：

提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。
能够实现故障转移：即 Failover。这是 Kafka 1.1 版本新引入的强大功能

监听器的概念，从构成上来说，它是若干个逗号分隔的三元组，每个三元组的格式为<协议名称，主机名，端口号>。这里的协议名称可能是标准的名字，比如 PLAINTEXT 表示明文传输、SSL 表示使用 SSL 或 TLS 加密传输等；也可能是你自己定义的协议名字，比如CONTROLLER: //localhost:9092。

一旦你自己定义了协议名称，你必须还要指定listener.security.protocol.map参数告诉这个协议底层使用了哪种安全协议，比如指定listener.security.protocol.map=CONTROLLER:PLAINTEXT表示CONTROLLER这个自定义协议底层使用明文不加密传输数据。

ZooKeeper 相关的设置

ZooKeeper 是一个分布式协调框架，负责协调管理并保存 Kafka 集群的所有元数据信息，比如集群都有哪些 Broker 在运行、创建了哪些 Topic，每个 Topic 都有多少分区以及这些分区的 Leader 副本都在哪些机器上等信息。

zookeeper.connect：zk1:2181,zk2:2181,zk3:2181，指定zk集群地址

Topic 管理

auto.create.topics.enable：是否允许自动创建 Topic。
unclean.leader.election.enable：是否允许 Unclean Leader 选举。
auto.leader.rebalance.enable：是否允许定期进行 Leader 选举。
retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。
retention.bytes：规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的 Kafka 集群中会有用武之地。当前默认值是 -1，表示可以无限使用磁盘空间。

auto.create.topics.enable参数我建议最好设置成 false，即不允许自动创建 Topic。在我们的线上环境里面有很多名字稀奇古怪的 Topic，我想大概都是因为该参数被设置成了 true 的缘故。

第二个参数unclean.leader.election.enable是关闭 Unclean Leader 选举的。每个分区都有多个副本来提供高可用。在这些副本中只能有一个副本对外提供服务，即 Leader 副本。如果Leader副本挂了，只有保存数据比较多的那些副本才有资格竞选，那些落后进度太多的副本不能。所以这个参数的设置需要根据业务酌情处理。

auto.leader.rebalance.enable的影响貌似没什么人提，但其实对生产环境影响非常大。设置它的值为 true 表示允许 Kafka 定期地对一些 Topic 分区进行 Leader 重选举，当然这个重选举不是无脑进行的，它要满足一定的条件才会发生。严格来说它与上一个参数中 Leader 选举的最大不同在于，它不是选 Leader，而是换 Leader！比如 Leader A 一直表现得很好，但若auto.leader.rebalance.enable=true，那么有可能一段时间后 Leader A 就要被强行卸任换成 Leader B