Kafka的优化-如何提高读写效率

零，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

• num.network.threads=3 ， broker处理消息的最大线程数 ，一般不改

• num.io.threads=3, broker处理磁盘IO的线程数 ，建议配置线程数量为cpu核数2倍，最大不超过3倍

• log.retention.hours=72 ，设置消息保留时间，如保留三天，也可以更短

• 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