在Kafka

2.8之后引入了基于Raft协议的KRaft模式支持取消对Zookeeper的依赖。

支持两种启动方式

进入Kafka层级太深或者是目录名字太长导致无法正确启动zookeeperLinux下与此类似进入bin后执行对应的sh文件即可

start_ZK.bat

../../config/zookeeper.propertiesstart_Kafka.bat

../../config/server.propertiesstop_Kafka.bat

../../config/server.propertiesKafka

with

vAB7_ADZTc6vsKrBLI1qmA上面指令生成的集群id

./kafka-storage.sh

../config/kraft/server.properties3.启动服务

../config/kraft/server.properties2.kafka基本的操作和管理

列出所有主题

../config/consumer.propertieskafka终止命令

3.Kafka

配置文件放在Kafka中主要是server.properties文件

3.1常规配置

在单机时无需修改但在集群下部署时往往需要修改。

它是个每一个broker在集群中的唯一表示要求是正数。

当该服务器的IP地址发生改变时broker.id没有变化则不会影响consumers的消息情况

listeners

不同的协议(如plaintext,trace,ssl、不同的IP和端口)),hostname如果设置为0.0.0.0则绑定所有的网卡地址如果hostname为空则绑定默认的网卡。

如果没有配置则默认为java.net.InetAddress.getCanonicalHostName()。

如PLAINTEXT://myhost:9092,TRACE://:9091或

zookeeper.connect

zookeeper集群的地址可以是多个多个之间用逗号分割。

一组hostname:port/path列表,hostname是zk的机器名或IP、port是zk的端口、/path是可选zk的路径如果不指定默认使用根路径

log.dirs

Kafka把所有的消息都保存在磁盘上存放这些数据的目录通过log.dirs指定。

可以使用多路径使用逗号分隔。

如果是多路径Kafka会根据“最少使用”原则把同一个分区的日志片段保存到同一路径下。

会往拥有最少数据分区的路径新增分区。

num.recovery.threads.per.data.dir

每数据的线程数比如本参数设置为8而log.dirs设置为了三个路径则总共会启动24个线程。

是否允许自动创建主题。

如果设为true那么produce生产者往主题写消息consume消费者从主题读消息或者fetch

metadata任意客户端向主题发送元数据请求时一个不存在的主题时就会自动创建。

缺省为true。

删除主题配置默认未开启

。

这个参数一般要评估比如每秒钟要写入和读取1000M数据如果现在每个消费者每秒钟可以处理50MB的数据那么需要20个分区这样就可以让20个消费者同时读取这些分区从而达到设计目标。

一般经验把分区大小限制在25G之内比较理想

log.retention.hours

日志保存时间默认为7天168小时。

超过这个时间会清理数据。

bytes和minutes无论哪个先达到都会触发。

与此类似还有log.retention.minutes和log.retention.ms都设置的话优先使用具有最小值的那个。

提示时间保留数据是通过检查磁盘上日志片段文件的最后修改时间来实现的。

也就是最后修改时间是指日志片段的关闭时间也就是文件里最后一个消息的时间戳

log.retention.bytes

分区数*log.retention.bytes。

-1没有大小限制。

log.retention.bytes和log.retention.minutes任意一个达到要求都会执行删除。

(注意如果是log.retention.bytes先达到了则是删除多出来的部分数据)一般不推荐使用最大文件删除策略而是推荐使用文件过期删除策略。

log.segment.bytes

分区的日志存放在某个目录下诸多文件中这些文件将分区的日志切分成一段一段的我们称为日志片段。

这个属性就是每个文件的最大尺寸当尺寸达到这个数值时就会关闭当前文件并创建新文件。

被关闭的文件就开始等待过期。

默认为1G。

如果一个主题每天只接受100MB的消息那么根据默认设置需要10天才能填满一个文件。

而且因为日志片段在关闭之前消息是不会过期的所以如果log.retention.hours保持默认值的话那么这个日志片段需要17天才过期。

因为关闭日志片段需要10天等待过期又需要7天。

log.segment.ms

作用和log.segment.bytes类似只不过判断依据是时间。

同样的两个参数以先到的为准。

这个参数默认是不开启的。

message.max.bytes

表示一个服务器能够接收处理的消息的最大字节数注意这个值producer和consumer必须设置一致且不要大于fetch.message.max.bytes属性的值(消费者能读取的最大消息,这个值应该大于或等于message.max.bytes)。

该值默认是1000000字节大概900KB~1MB。

如果启动压缩判断压缩后的值。

这个值的大小对性能影响很大值越大网络和IO的时间越长还会增加磁盘写入的大小。

Kafka设计的初衷是迅速处理短小的消息一般10K大小的消息吞吐性能最好LinkedIn的kafka性能测试

为Kafka选择合适的硬件更像是一门艺术就跟它的名字一样我们分别从磁盘、内存、网络和CPU上来分析确定了这些关注点就可以在预算范围之内选择最优的硬件配置。

磁盘吞吐量/磁盘容量

每秒的读写次数会影响生产者的性能。

因为生产者的消息必须被提交到服务器保存大多数的客户端都会一直等待直到至少有一个服务器确认消息已经成功提交为止。

也就是说磁盘写入速度越快生成消息的延迟就越低。

SSD固态贵单个速度快HDD机械偏移可以多买几个设置多个目录加快速度具体情况具体分析

磁盘容量的大小则主要看需要保存的消息数量。

如果每天收到1TB的数据并保留7天那么磁盘就需要7TB的数据。

Kafka本身并不需要太大内存内存则主要是影响消费者性能。

在大多数业务情况下消费者消费的数据一般会从内存页面缓存从系统内存中分中获取这比在磁盘上读取肯定要快的多。

一般来说运行Kafka的JVM不需要太多的内存剩余的系统内存可以作为页面缓存或者用来缓存正在使用的日志片段所以我们一般Kafka不会同其他的重要应用系统部署在一台服务器上因为他们需要共享页面缓存这个会降低Kafka消费者的性能。

网络吞吐量决定了Kafka能够处理的最大数据流量。

它和磁盘是制约Kafka拓展规模的主要因素。

对于生产者、消费者写入数据和读取数据都要瓜分网络流量。

同时做集群复制也非常消耗网络。

CPU

Kafka对cpu的要求不高主要是用在对消息解压和压缩上。

所以cpu的性能不是在使用Kafka的首要考虑因素。

我们要为Kafka选择合适的硬件时优先考虑存储包括存储的大小然后考虑生产者的性能也就是磁盘的吞吐量选好存储以后再来选择CPU和内存就容易得多。

网络的选择要根据业务上的情况来定也是非常重要的一环。