zoukankan      html  css  js  c++  java
  • kafka-broker重要配置分析

    配置项在/config/server.properties文件中,修改后需要重启该broker,基本配置如下:

    log.dirs

    kafka保存消息的目录,存放分区数据。一般不使用默认的,根据消息的数量,单独配置一个或多个目录逗号隔开;

    zookeeper.connect

    zk连接参数,zk1:2181,zk2:2181,zk3:2181/kafka,很多新手忘记结尾的 /kafka,当然这个也赖
    
    部署的人,chroot一会配一会儿不配的

    auto.create.topics.enable

    启用自动创建topic,默认为true,这个配置项重要性一般,纯看业务需要

    unclean.leader.election.enable

    决定不在同步副本集合(in-sync replicas, ISR)中的副本能否被选举为leader。默认true,这样的话没同步到消息的副本
    
    也有可能被选为leader,有可能丢数据,改为false为好

    delete.topic.enable

    properties文件中看了是没有的,需要自己配置为true,方便维护

    log.retention相关的

    一般来说,kafka中消息会一直增长,但是存储空间是有限的,因此消息会有留存的策略(过期策略)
    
    这个和刷磁盘类似,2个思路:文件大小或时间来决定哪些清除掉
    
    log.retention.bytes:定期删除超过这个设置值的日志文件,默认-1,不删除
    
    log.retention.ms/minutes/hours:三个配置项,被采用的优先级依次毫秒,分钟,小时的配置,默认是7天,优先基于消息中的时间戳判断
    
    log.retention.check.interval.ms:日志清除程序检查日志是否需要被删除的频率

    min.insync.replicas

    保证消息可靠(不丢失)的重要参数。与producer端的参数acks配合使用。只有在acks=all(或-1)时才有意义

    指定 "应答写入成功" 所需要的最低副本数。如果无法满足这个值,producer抛出NotEnoughReplicas或NotEnoughReplicasAfterAppend异常
    
    典型配置:topic设置replication.factor=3,min.insync.replicas=2,producer设置ack=all,推荐取值:[1,replication.factor)
    
    多辨析几句:acks=all,代表消息需要在所有的ISR(同步副本集合)中都同步完成后,broker才能告诉生产者,你的消息发送成功了
    
    ISR中有leader,有follower,但是这个集合中会出现"踢人"现象(踢人是比较少见的场景,根据xxx的理论,只要有可能发生,就当作一定会发生)
    
    min.insync.replicas=n这个参数就是来限制ISR中节点的数量的,如果发送消息时,ISR中节点数不够n,那么这个broker不能处理这批消息,
    
    需要直接向producer报错。还是老经验,可靠和效率不可得兼,需要根据业务和环境做平衡

    num.partitions

    创建topic时默认的分区数量
    
    顺带提一下,offsets.topic.num.partitions=50,这是__consumer_offsets这个topic的默认分区数,它的副本数是3

    log.cleanup.policy

    kafka的每个分区中都有日志文件,日志文件由日志段文件组成,消息是无界的,空间是有限的,因此需要定期对消息做清理操作
    
    策略有2种:delete和compact,默认delete,对需要删除的日志文件直接删除,compact是将日志文件进行压缩

    log.flush相关

    log.flush.interval.messages:日志分区中消息数达到多少时,刷新到磁盘
    
    log.flush.interval.ms:日志保存最长多少毫秒被刷新到磁盘,默认未设置,使用log.flush.scheduler.interval.ms
    
    log.flush.scheduler.interval.ms:日志刷到磁盘的频率

    带点私货:

    写到这里,想到es的document索引的过程,突然想总结一些中间件的共性的设计思路:

    一般"数据"会先写入缓存,有的是写入某种文件(比如日志文件),es叫translog,kafka,姑且叫log吧,kafka和es都是

    用segment文件来存日志数据,然后刷到磁盘,如果我是设计者,那肯定也会设置segment文件最大多大,设置每隔多久

    强制将文件里的数据刷到磁盘(刷盘频率),有按频率的,那一定也有按周期的,因为如果数据来得慢,segment写不满,

    总不能一直不刷入磁盘;同时如果数据来的很快,还没到刷盘时间,日志文件就满了,也得强制刷新到磁盘;

    segment文件不断增长,那么需要有一种策略,定期扫描文件,看看哪些需要删除或者压缩(es是合并概念)

  • 相关阅读:
    HDU 2176 取(m堆)石子游戏 (尼姆博奕)
    HDU 1846 Brave Game (巴什博弈)
    HDU-1025 Constructing Roads In JGShining's Kingdom
    FOJ有奖月赛-2015年11月 Problem B 函数求解
    FOJ有奖月赛-2015年11月 Problem A
    JXNU acm选拔赛 不安全字符串
    JXNU acm选拔赛 涛神的城堡
    JXNU acm选拔赛 涛涛的Party
    JXNU acm选拔赛 壮壮的数组
    JXNU acm选拔赛 最小的数
  • 原文地址:https://www.cnblogs.com/yb38156/p/14585369.html
Copyright © 2011-2022 走看看