美文网首页程序员
Kafka集群参数配置(一)

Kafka集群参数配置(一)

作者: 我可能是个假开发 | 来源:发表于2023-01-17 20:33 被阅读0次

一、Broker 端参数

1.针对存储信息:

  • log.dirs:指定Broker 需要使用的若干个文件目录路径。没有默认值的,必须手动指定。
  • log.dir:表示单个路径,是补充上一个参数用的。

在线上生产环境中一定要为log.dirs配置多个路径,具体格式是一个 CSV 格式,也就是用逗号分隔的多个路径,比如/home/kafka1,/home/kafka2,/home/kafka3
最好保证这些目录挂载到不同的物理磁盘上。这样做有两个好处:

  • 提升读写性能:比起单块磁盘,多块物理磁盘同时读写数据有更高的吞吐量。
  • 能够实现故障转移:即 Failover(坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上,而且 Broker 还能正常工作)

2.针对ZooKeeper

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

  • zookeeper.connect:CSV 格式的参数,比如可以指定它的值为zk1:2181,zk2:2181,zk3:2181。2181 是 ZooKeeper 的默认端口。

让多个 Kafka 集群使用同一套 ZooKeeper 集群,那么这个参数需要使用chroot:
chroot 是 ZooKeeper 的概念,类似于别名。
如果有两套 Kafka 集群,假设分别叫它们 kafka1 和 kafka2,那么两套集群的zookeeper.connect参数可以这样指定:
zk1:2181,zk2:2181,zk3:2181/kafka1zk1:2181,zk2:2181,zk3:2181/kafka2
切记 chroot 只需要写一次,而且是加到最后的。

Broker 端参数也被称为静态参数:静态参数必须在 Kafka 的配置文件 server.properties 中进行设置的参数,不管新增、修改还是删除。同时,必须重启 Broker 进程才能令它们生效

3.Broker 连接相关

  • listeners:学名叫监听器,告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务。
  • advertised.listeners:和 listeners 相比多了个 advertised。Advertised 的含义表示宣称的、公布的,就是说这组监听器是 Broker 用于对外发布的。
  • host.name/port:列出这两个参数就是想说你把它们忘掉吧,不需要为它们指定值,毕竟是过期的参数。

二、Topic级别参数

1.auto.create.topics.enable

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

2.unclean.leader.election.enable

是否允许 Unclean Leader 选举。
关闭 Unclean Leader 选举的。何谓 Unclean? Kafka 有多个副本,每个分区都有多个副本来提供高可用。在这些副本中只能有一个副本对外提供服务,即所谓的 Leader 副本。这些副本中只有保存数据比较多的那些副本才有资格竞选,那些落后进度太多的副本没资格做这件事。假设那些保存数据比较多的副本都挂了怎么办?我们还要不要进行 Leader 选举了?此时这个参数就派上用场了。

  • 设置成 false,那么就坚持之前的原则,坚决不能让那些落后太多的副本竞选 Leader。这样做的后果是这个分区就不可用了,因为没有 Leader 了。
  • 设置成 true,那么 Kafka 允许你从那些“跑得慢”的副本中选一个出来当 Leader。这样做的后果是数据有可能就丢失了,因为这些副本保存的数据本来就不全,当了 Leader 之后它本人就变得膨胀了,认为自己的数据才是权威的。

3.auto.leader.rebalance.enable

是否允许定期进行 Leader 选举。

  • true :一段时间后 Leader A 就要被强行卸任换成 Leader B。
  • false:不允许定期进行 Leader 选举

建议在生产环境中把这个参数设置成 false。

三、数据留存相关参数:

1.log.retention.{hours|minutes|ms}

控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hours 最低。
虽然 ms 设置有最高的优先级,但是通常情况下我们还是设置 hours 级别的多一些,比如log.retention.hours=168表示默认保存 7 天的数据,自动删除 7 天前的数据。很多公司把 Kafka 当作存储来使用,那么这个值就要相应地调大。

2.log.retention.bytes

这是指定 Broker 为消息保存的总磁盘容量大小。
值默认是 -1,表明在这台 Broker 上保存多少数据都可以,至少在容量方面 Broker 绝对为你开绿灯,不会做任何阻拦。这个参数真正发挥作用的场景其实是在云上构建多租户的 Kafka 集群:设想你要做一个云上的 Kafka 服务,每个租户只能使用 100GB 的磁盘空间,为了避免有个“恶意”租户使用过多的磁盘空间,设置这个参数就显得至关重要了。

3.message.max.bytes

控制 Broker 能够接收的最大消息大小。
默认的 1000012 ,不到 1MB。实际场景中突破 1MB 的消息都是屡见不鲜的,因此在线上环境中设置一个比较大的值还是比较保险的做法。毕竟它只是一个标尺而已,仅仅衡量 Broker 能够处理的最大消息大小,即使设置大一点也不会耗费什么磁盘空间的。

极客时间《Kafka 核心技术与实战》学习笔记Day3 - http://gk.link/a/11UOV

相关文章

网友评论

    本文标题:Kafka集群参数配置(一)

    本文链接:https://www.haomeiwen.com/subject/rtqxhdtx.html