架构师修炼之道

知识日新月异,唯有保持同步迭代,才能适应变化的未来!

0%

Kafka配置推荐及最佳实践

配置推荐

重要配置项说明

  1. zookeeper.connect:必配参数,建议在kafka集群的每台机器都配置所有zk。
  2. broker.id:必配参数。集群节点的标示符,不得重复,取值范围0~n。
  3. log.dirs:不要使用默认的“/tmp/kafka-logs”
  4. advertised.host.name(默认为“host.name”):注册到zk供用户使用的主机名,内网环境通常无需配置,而IaaS一般需要配置为公网地址。
  5. advertised.port:注册到zk供用户使用的服务端口,通常在IaaS环境需要额外配置。
  6. num.partitions(默认是1):创建topic时的默认partition数量
  7. default.replication.factor:自动创建topic的默认副本数量,官方建议修改为2。
  8. min.insync.replicasISR:提交生成者请求的最小副本数
  9. unclean.leader.election.enable(默认允许):是否允许不具备ISR资格的replicas被选举为leader,作为不得已的措施,甚至不惜牺牲部分数据。
  10. controlled.shutdown.enable:在kafka收到stop命令或者异常终止时,允许自动同步数据,建议开启。

客户端配置

  • 生产方面要考虑:
    • ack、压缩、同步生产 vs 异步生产、批处理大小(异步生产)
    • Consumer方面要考虑:获取消息的大小

动态调整配置

大部分kafka配置是写死在properties文件里的。然而,许多关于topic的参数可以使用kafka-topic.sh工具来进行动态调配,常见可以调整的参数如下:

  1. unclean.leader.election.enable:不严格的leader选举,有助于集群健壮,但是存在数据丢失风险。
  2. min.insync.replicas:如果同步状态的副本小于该值,服务器将不再接受request.required.acks为-1或all的写入请求。
  3. max.message.bytes:单条消息的最大长度。如果修改了该值,那么replica.fetch.max.bytes和消费者的fetch.message.max.bytes也要跟着修改。
  4. cleanup.policy:生命周期终结数据的处理,默认删除
  5. flush.messages:强制刷新写入的最大缓存消息数
  6. flust.ms:强制刷新写入的最大等待时长

还有一些参数也可以动态调整,请参考官方文档。

最佳实践

Java方面

建议使用JDK 1.8的最新发布版本,使用G1收集器(当前的默认值),LinkedIn的调整看起来像这样:

-Xmx6g -Xms6g -XX:MetaspaceSize=96m 
-XX:+UseG1GC-XX:MaxGCPauseMillis=20 
-XX:InitiatingHeapOccupancyPercent=35 
-XX:G1HeapRegionSize=16MXX:MinMetaspaceFreeRatio=50 
-XX:MaxMetaspaceFreeRatio=80

硬件和操作系统

LinkedIn正在使用带有24GB内存的四核英特尔至强处理器,8x7200转的SATA硬盘,还是建议调整一下:

  1. 内存:建议使用64G内存的机器
  2. CPU:尽量选择更多核,将会获得多核带来的更好的并发处理性能
  3. 磁盘:RAID是优先推荐的,SSD可以考虑
  4. 网络:最好是万兆网络,千兆也可
  5. 文件系统:ext4是最佳选择
  6. 操作系统:任何Unix系统上运行良好,并且已经在Linux和Solaris上进行了测试

操作系统级别的调整

不太需要太多的操作系统级别的调整,有几个重要的操作系统级别的配置:

  1. 文件描述符数量调整
  • Kafka为日志段和打开的连接使用文件描述符。如果broker承载多个分区,则考虑
  • broker至少需要(number_of_partitions)*(partition_size / segment_size)来跟踪
  • broker所做的连接数量以外的所有日志段。推荐至少100000个
  1. 最大套接字缓冲区大小:可以增加以实现数据中心之间的高性能数据传输
  2. pagecache:尽量分配与大多数日志的激活日志段大小一致
  3. 禁用swap

仔细设计broker的数量

  • 一般建议单broker上的分区数<2000;分区大小,不要超过25GB
  • 另外还要考虑消息数据流量和处理速度

仔细设计partition的数量

  • 至少和最大的消费者组中consumer的数量一致
  • 分区不要太大,小于25GB
  • 要考虑未来业务的扩容