首页  

Kafka1.1.0 Broker配置     所属分类 kafka 浏览量 121
kafka1.1.0
server.properties

broker.id  集群唯一,数字类型,不能为负数。
min.insync.replicas  ISR个数,数据可靠性,配合Producer端 acks 参数
如果可靠性要求较高,建议设置为>=2的值,大于broker节点个数的一半
日志刷盘策略 数据保存在segement文件中(包括用于提高查询效率的index文件)
两种同步刷盘策略 基于时间间隔 基于累计消息条数
基于时间间隔:每隔X毫秒,执行一次文件的fsync操作
基于累计消息条数:每X条消息后,同步执行一次fsync操作。

num.partitions 每个Topic的partition个数,默认1 
日志保留策略 
设定kafka保存消息(数据文件)的时长,也限定consumer允许数据回溯的最大时间。
查出时间阈值的日志文件,可以“压缩备份”,也可以删除。

分组协调


## 开启JMX监控,默认端口5760  
export JMX_PORT=${JMX_PORT:-5760}  
## 基于jolokia + HTTP方式输出监控数据 
## export KAFKA_OPTS="$KAFKA_OPTS -javaagent:/opt/jolokia/jolokia-jvm-1.5-agent.jar"  

Jolokia is remote JMX with JSON over HTTP


kafka broker与client兼容关系描述
https://cwiki.apache.org/confluence/display/KAFKA/Compatibility+Matrix

0.9以上版本的client和broker,低版本client可以访问高版本的broker,
但是高版本的client访问低版本的broker时可能存在兼容性问题。
    
kafka consumer group的几种状态

1)Empty 此group中没有任何消费者在线(曾经提交过offset),可能是新建的group。当一个 Empty的group过期之后,其状态会迁移为 Dead 。
2)PrepareingRebalance 准备进行rebalance,通常是此group中有消费者加入或者离开时(探测周期)触发,这意味着topic/partition在组内多个消费者之间重新分配。
3)AwaitingSync 等待Group Leader重新分配topic/partitions
4)Stable 正常状态
5)Dead:Group内已经没有任何消费者(members),且其offset记录等meta信息即将被删除。
    
    

# 集群唯一 整数 非负数 
broker.id=0  
auto.create.topics.enable=true  
#允许客户端直接删除 
delete.topic.enable=true  
auto.leader.rebalance.enable=true  
# 单条消息最大尺寸,10M  
message.max.bytes=10000120  
replica.fetch.max.bytes=10485760  
# ISR,当Producer Ack模式为“all”时必须等待ISR列表中replicas全部写入成功  
# 如果replicas为3,可设置为2 + ACK=all 确保消息可靠性。  
min.insync.replicas=2  
  
# 默认replication个数,broker=3,replication=2  
default.replication.factor=2  
############################# Socket Server Settings #############################  
listeners=PLAINTEXT://192.168.0.10:9092  
  
# 接收客户端请求的IO线程数 
num.network.threads=3  
  
# 处理请求包括磁盘IO的线程数
num.io.threads=8  
  
# SO_SNDBUF  
socket.send.buffer.bytes=102400  
# SO_RCVBUF  
socket.receive.buffer.bytes=102400  
  
# 单次请求,Server允许接收的最大数据量,避免OOM。默认值为100M(104857600)  
socket.request.max.bytes=104857600  
  
# 等待处理的请求个数,超过阈值将会阻塞网络IO线程(类似backlog)  
queued.max.requests=500  
  
# 客户端等待broker响应最大等待时间(包括重试),Client可配置。默认30000秒。  
request.timeout.ms=15000  
  
# 单个IP允许建立的连接数 默认无限制
max.connections.per.ip=256  
  
############################# Log Basics #############################  
# 底层日志文件保存目录,多个磁盘路径则以逗号分割 
log.dirs=/data/kafka  
   
num.partitions=1  
  
num.recovery.threads.per.data.dir=1  
  
############################# Internal Topic Settings  #############################  
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state"  
# kafka内部状态数据将保存在特定的topic中,  
# offsets 保存在 __consumer_offsets   
# 每个producer的事务,保存在 __transaction_state 
# 对于内部topic,其replicas个数,建议为“大多数派”,且最多不要超过3。  
# broker<3,replicas=1;  
# brokers = 3,replicas=2;  
# broker>=5,replicas=3;  
# 线上配置,broker=3;事务功能暂时关闭  
offsets.topic.replication.factor=2  
transaction.state.log.replication.factor=1  
transaction.state.log.min.isr=1  
  
############################# Log Flush Policy #############################  
  
# 日志刷盘策略, 吞吐量优先 vs 数据可靠性优先  
# 吞吐量优先 replicaiton=1  
  
#  两个参数满足其一,即可Flush  
# 吞吐量优先,默认为关闭(Long最大值)  
log.flush.interval.messages=10000  
  
# 可靠性 + 延迟优先,每隔1秒刷盘,通用高优策略。  
log.flush.interval.ms=1000  
  
############################# Log Retention Policy #############################  
  
# 日志保留策略, 保留时间长 存量数据大小 ,超出阈值的日志将会被清理  
log.cleanup.policy=delete  
log.cleaner.enable=true  
# 保留多久则会被cleanup,默认值12小时 
log.cleaner.delete.retention.ms=43200000  
  
# 日志保留 7 天  
log.retention.hours=168  
## 350G  
log.retention.bytes=375809638400  
  
# 底层为LSM树,每个逻辑topic、partition都会有多个segments文件构成,每个segments大小,默认为1G。  
# 建议保持默认  
log.segment.bytes=1073741824  
  
# 检测周期,5分钟  
log.retention.check.interval.ms=300000  
  
############################# Zookeeper #############################  
# 可以包含chroot, host:ip/kafka  
zookeeper.connect=192.168.0.10:2181,192.168.0.11:2181,192.168.0.12:2181/kafka  
zookeeper.connection.timeout.ms=6000  
  
  
############################# Group Coordinator Settings #############################  
# 分组协调 (broker端)  
# rebalance 通常适用 单组 + 多个消费者 场景,此值适用于 消费者入组后,首次relance之前等待的时长  
# 消费者启动可能逐个进行,等待足够多的consumers入组后进行rebalance 
group.initial.rebalance.delay.ms=3000  
group.max.session.timeout.ms=300000  
group.min.session.timeout.ms=6000

上一篇     下一篇
kafka listeners 和 advertised.listeners

寒冬里说经济周期

kafka consumer均衡算法

kafka运维常用命令

程序员的誓言 

zookeeper使用场景