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