Kafka高性能相关
1 高性能原因
1.1 高效使用磁盘
（1）顺序写磁盘，顺序写磁盘性能高于随机写内存
（2）Append Only 数据不更新，无记录级的数据删除（只会整个segment删除）
（3）充分利用Page Cache，I/O Scheduler将连续的小块写组装成大块的物理写从而提高性能，将一些写操作重新按顺序排好，从而减少磁盘头的移动时间
（4）充分利用所有空闲内存(非JVM内存)，应用层cache也会有对应的page cache与之对应，直接使用page cache可增大可用cache，如使用heap内的cache，会增加GC负担
（5）读操作可直接在page cache内进行。如果进程重启，JVM内的cache会失效，但page cache仍然可用
（6）可通过参数强制flush
（7）支持多Directory
1.2 零拷贝
传统模式下数据从文件传输到网络需要4次数据拷贝，4次上下文切换和2次系统调用。通过NIO的transferTo/transferFrom调用操作系统的sendfile实现零拷贝。总共2次内核数据拷贝，2次上下文切换和1次系统调用，消除了CPU数据拷贝
1.3 批处理和压缩
（1）Producer和Consumer均支持批量处理数据，从而减少了网络传输的开销
（2）Producer可将数据压缩后发送给broker，从而减少网络传输代价。目前支持Snappy，Gzip和LZ4压缩
1.4 Partitio
（1）通过Partition实现了并行处理和水平扩展
（2）Partition是Kafka（包括kafka Stream）并行处理的最小单位
（3）不同Partition可处于不同的Broker，充分利用多机资源
（4）同一Broker上的不同Partition可置于不同的Directory，如果节点上有多个Disk Drive，可将不同的Drive对应的Directory，从而是Kafka充分利用Disk Drive的磁盘优势
1.5 ISR
（1）ISR实现了可用性和一致性的动态平衡
（2）ISR可容忍更多的节点失败。Majority Quorum如果要容忍f个节点失败，至少需要2f+1个节点 ISR如果要容忍f个节点失败，至少需要f+1个节点
（3）如何处理Replica Crach，Leader crash后，ISR中的任何replica皆可竞选称为Leader，如果所有replica都crash，可选择让第一个recover的replica或者第一个在ISR中的replica称为leader
2 kafka性能影响因子
（1）producer ：producer和吞吐量成正比
（2）consumer：consumer数据量在没有达到partition个数之前，和消费的吞吐量成正比。
（3）partition：分区格式和生成的吞吐量，在一定范围内，先增长，当达到某一个值之后区域稳定，在上下浮动。
（4）message-size：随着message size的增大，生产者对应的每秒生成的记录数在成下降趋势，区里的数据体积成上升趋势。
（5）replication：副本越大，自然需要同步数据的量就越多，自然kafka的生成的吞吐量就越低。
2.1 kafka脚本查看kafka集群性能
（1）kafka-producer-perf-test.sh：查看kafka生产者的性能。
bin/kafka-producer-perf-test.sh --topic perftest \
--num-records 100000 \ #测试生成多少条记录
--throughput 10000 \ #生产这的吞吐量，约等于messages/sec
--record-size 10 \ #每条消息的大小
--producer.config config/producer.properties（2）kafka-consumer-perf-test.sh：查看kafka消费者的性能。
bin/kafka-consumer-perf-test.sh --topic perftest \
--broker-list bigdata01:9092,bigdata02:9092,bigdata03:9092 \
--messages 100000 #总共要读取多少条记录结果参数
start.time=2019-08-06 02:31:23:738 --->开始时间
end.time=2019-08-06 02:31:24:735 --->结束时间
data.consumed.in.MB=0.9534 --->总共消费的数据体积
MB.sec=0.9562 --->每秒钟消费数据体积
data.consumed.in.nMsg=100000 --->总共消费的数据记录数
nMsg.sec=100300.9027 --->每秒钟消费记录数
rebalance.time.ms=47 --->进行rebalance的时间
fetch.time.ms=950 --->抓取这10w条数据总共花费多长时间
fetch.MB.sec=1.0035 --->每秒钟抓取数据体积
fetch.nMsg.sec=105263.1579 --->每秒钟抓取数据记录数
