kafka配置详解 之 broker配置
说明:
参考书籍 <kafka权威指南>
有些参数在新版本中可能有变动
如果配置无效,请百度对应版本是否支持该参数
1. 常规配置
broker.id
broker的唯一标识符
要在集群中唯一
整数, 默认为0
建议将其设置成和机器名关联的整数, 如机器名: host1.example.com, 则broker.id设置成1是很好的实践
port
kafka监听端口, 默认9092
如果使用1024以下的端口,需要使用root权限启动kafka[不建议这么做]
zookeeper.connect
保存broker元数据的zookeeper地址
格式: hostname:port/path, 多个值用"冒号"隔开?
/path是可选的zookeeper路径, 默认根路径, 指定后会自动创建
注意: 这个参数存疑! 0.9版本的kafka不再依赖zookeeper, 这个参数应该已经失效了
log.dirs
kafka消息的本地存储路径
多个路径用逗号隔开
同一个分区的日志在同一个路径下
新增分区的时候, broker会选择网拥有最少数目分区的路径下新增分区
num.recovery.threads.per.data.dir
"每个目录分配的线程数", 默认1个
以下三种场景下启动这些线程
- 服务器正常启动, 用于打开每个分区的日志片段
- 服务器奔溃后重启, 用于检查和截短每个分区的日志片段
- 服务器正常关闭, 用于关闭日志片段
只在服务启动和关闭时用到, 完全可以大量配置! 提升加载速度
案例:设置8 ,那么3个目录会启动8*3=24个线程
auto.create.topics.enable
是否自动创建主题
默认以下三种场景自动创建
- 生产者往主题写入消息
- 消费者从主题读取消息
- 客户端向主题发送元数据请求
如果手动创建主题, 可以将其设置为false
2. 主题的默认配置
特别说明
之前的kafka版本支持主题覆盖服务器的默认配置(是指客户端配置覆盖服务器?).
后来不支持了, 要修改需要通过管理工具
num.partitons
指定新创建的主题包含几个分区
kafka集群通过分区个数对主题进行横向扩展
主题消息越多,最好配置更多的分区, 以便进行负载分散
log.retention.ms
数据保留期限
默认168小时(7天)
log.retention.minutes
和上面一样的效果, 配置多个的时候, kafka会优先选择最小值的那个
log.retention.byte
分区能保留的最大消息量
主题能保留 = log.retention.byte * 分区数
log.segment.bytes
主题分为多个分区, 每个分区又分为多个日志片段: segment
默认1G
日志片段大小达到该值时, 就关闭片段,等待过期
这个值越小, 越频繁关闭和分配新文件. 从而降低磁盘写入的整体性能
如果主题消息不大, 这个设置非常考究:
比如:
主题每天生产100M日志, 默认1G的日志片段的话, 10天才会塞满一个片段
日志保留7天的话, 该片段会在17天后才删除(必须等日志片段关闭,并且日志片段最后一个消息过期,才触发过期)
在使用时间戳获取偏移量时, 日志片段越小, 偏移量越精确
原理: 输入时间戳查询, 会查到该时间戳所属日志片段, 然后返回该片段开头的偏移量. 自然判断越小越接近
log.segment.ms
日志片段关闭的时间限制
默认不设置
message.max.bytes
限制单个消息的大小
默认1M (1000 000)
这个值对性能影响很大
值越大, 负责处理网络连接和请求的线程就需要花更多的时间处理这些请求
它还会增加磁盘写入块的大小, 从而影响IO吞吐量
这个值要和消费者配置协调
消费者设置的 fewtch.message.max.bytes如果比这个值小, 那么消费者遇到大消息无法消费, 会导致消费者阻塞
集群broker的replica.fetch.max.bytes也遵循这个原则
replica.fetch.max.bytes
broker可复制的消息的最大字节数
默认为1M
这个值应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去, 频繁重发导致网卡爆满, 或消息丢失
