Kafka集群生产环境架设笔记

最新推荐文章于 2024-11-18 19:12:21 发布

bydc2009

最新推荐文章于 2024-11-18 19:12:21 发布

阅读量160

点赞数

文章标签：大数据网络 java

原文链接：http://blog.51cto.com/huanghai/2429971

版权

Kafka官方说明不是台详细，但网上也有很多参考，现还是将自己在CentOS7.6上架设生产环境的笔记记录下。同时由于Kafka的版本也在不断的升级，有些参数也许有变化，这里也将持续更新，如有错误还望指出。

调优

网络及swappiness

# vi /etc/sysctl.d/99-kafka.conf

# swap
vm.swappiness = 1
# dirty page
vm.dirty_background_ratio = 5
vm.dirty_ratio = 70
# tcp socket
net.core.rmem_default = 4194304
net.core.wmem_default = 4194304
# tcp socket
net.ipv4_tcp_rmem = 4096 65536 4194304
net.ipv4_tcp_wmem = 4096 65536 4194304
# other network
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_max_syn_backlog = 5120
net.core.netdev_max_backlog = 100000

修改系统最大文件和进程打开数

之前配置好kafka后，运行一段时间会报打开的文件太多，日志中具体发现如下记录

...
Caused by: java.io.IOException: Too many open files
...

通过命令可以查看当前系统中对最大文件打开数的设置，默认是1024，运行命令为'ulimit -a'（root用户）

修改系统环境变量

临时修改

# ulimit -n 65535
# ulimit -u 65535

永久修改

/etc/security/limits.conf文件中添加如下

# vim /etc/security/limits.conf
...
# Add following items at end
*         -      nofile    65535
*         -      nproc    65535

/etc/pam.d/su文件中添加如下

#vim /etc/pam.d/login

...
session    required    pam_limit.so

修改完成中重启生效，对于/etc/security/limits.conf文件的详细说明请见我的另外一篇笔记https://blog.51cto.com/huanghai/2437446

topic管理

通过kafka自带工具实现topic的管理，主要依靠kafka-topic.sh工具实现

列出主题

> kafka-topics.sh --bootstrap-server <kafka_host1>:9092,<kafka_host2>:9092,... --list

删除主题

> kafka-topics.sh --bootstrap-server <kafka_host1>:9092,<kafka_host2>:9092,... --delete --topic <topic_name>

说明：
1.如果Kafka服务配置了delete.topic.enable=true，直接通过命令行删除，未能删除Topic则可以通过zookeeper-client来进行删除。以下是单独使用zookeeper的二进制程序包的说明，并且已经进入bin目录。

# 进入zookeeper命令行客户端
> zkCli.sh -server <zkhost1:2181>[,<zkhost:2181>,...]
# 执行删除topic的操作
] deleteall /brokers/topics/<topic_name>

2.如果Kafka服务未配置delete.topic.enable=false，直接通过delete命令删除topic，删除时只会将topic标记为“marked for deletion”，然后通过zookeeper-client进行删除是不会删除topic的data.log数据目录的，需要将相应的broker服务器上的log目录下相应的topic目录删除。

参数replica.fetch.max.bytes说明

设置了多个副本的kafka集群，存在副本间的同步问题，会有replica因为不能同步成功而掉线，最终topic的可用isr只剩下一个。查看log4j.properties(log4j.logger.kafka默认TRACE)，有如下：

TRACE Did not finish writing, registering for write again on connection /192.168.1.238:46389 (kafka.network.Processor)

这条日志表明broker一直在发送数据，然后失败重试。kafka的配置文件中，replica.fetch.max.bytes默认值是1048576(1MiB)，在短消息的应用场景下是没有问题的，但是我们的消息长度比较大，经常有大于1MiB的消息，虽然在topic中定义了max.message.bytes=52428700，即50MiB，但是对于broker，replica.fetch.max.bytes是不会随着topic的max.message.bytes变大而自动更新的，这样就导致一个问题，一旦消息的长度大于1M，而配置文件中没有定义 replica.fetch.max.bytes，就会导致replica之间数据同步失败。因此，我自己是将配置中max.message.bytes赋给replica.fetch.max.bytes。
另外，在apache上相关的issue也有类似的讨论， https://issues.apache.org/jira/browse/KAFKA-1756