零,Kafka为什么快?
既然涉及到提高Kafka的读写效率,就要搞清楚Kafka的读写是如何设计的。
- 1,为了减少磁盘IO和网络IO,Kafka支持批量读写,而不是一条一条读写。
- 2,Kafka支持消息压缩,Producer端压缩,Broker保持,Consumer解压。
- 3,Kafka按Topic分类管理消息,Topic分布式存储(Partition)
- 4,Kafka数据存储没有内存缓存,只有操作系统页缓存+磁盘顺序读写
- 5,Kafka的持久化数据结构采用简单高效的队列,类似日志的追加写入
- 6,Kafka数据副本间同步采用零拷贝技术
- 7,Partition并没有把所有消息存储到一个文件中,而是采用分段存储,对每个分段文件建立稀疏索引,以更快的读取消息
一,producer
producer提高写入效率:
-
设置
acks=1
,表示leader写入即认为写入成功,但如果要保证消息写入可靠性的话,这个配置要慎重 -
**props.put("compression.type","lz4")**
,设置消息压缩格式,降低网络传输 -
buffer.memory:33554432 (32m)
,在Producer端用来存放尚未发送出去的Message的缓冲区大小。缓冲区满了之后可以选择阻塞发送或抛出异常,由block.on.buffer.full
的配置来决定。 -
linger.ms:0
,Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送,以此提高吞吐量,而linger.ms
则更进一步,这个参数为每次发送增加一些delay,以此来聚合更多的Message。 -
batch.size:16384
,如上图,Producer会尝试去把发往同一个Topic、Partition的多个Requests进行合并,batch.size指明了一次Batch合并后Requests总大小的上限。如果这个值设置的太小,可能会导致所有的Request都不进行Batch
二,broker
-
log.dirs配置多个磁盘存储不同分区,不要把配置一个磁盘多个目录作为多个分区的存储路径
-
num.network.threads=3 , broker处理消息的最大线程数 ,一般不改
-
num.io.threads=3, broker处理磁盘IO的线程数 ,建议配置线程数量为cpu核数2倍,最大不超过3倍
-
log.retention.hours=72 ,设置消息保留时间,如保留三天,也可以更短
-
log.segment.bytes=1073741824
,段文件配置1GB,有利于快速回收磁盘空间,重启kafka加载也会加快(如果文件过小,则文件数量比较多,kafka启动时是单线程扫描目录(log.dir)下所有数据文件 -
replica.lag.time.max.ms:10000,replica.lag.max.messages:4000
,用来控制副本在什么条件下从ISR队列移除 -
num.replica.fetchers:1
,在Replica上会启动若干Fetch线程把对应的数据同步到本地,而num.replica.fetchers这个参数是用来控制Fetch线程的数量。每个Partition启动的多个Fetcher,通过共享offset既保证了同一时间内Consumer和Partition之间的一对一关系,又允许我们通过增多Fetch线程来提高效率。 -
default.replication.factor:1,这个参数指新创建一个topic时,默认的Replica数量,Replica过少会影响数据的可用性,太多则会白白浪费存储资源,一般建议在3为宜
三,consumer
-
num.consumer.fetchers:1
,启动Consumer拉取数据的线程个数,适当增加可以提高并发度。 -
fetch.min.bytes:1
,每次Fetch Request至少要拿到多少字节的数据才可以返回, 在Fetch Request获取的数据至少达到fetch.min.bytes之前,允许等待的最大时长。对应上面说到的Purgatory中请求的超时时间:fetch.wait.max.ms:100