最新微网站建设价格,yfcms企业网站建设,Wordpress实现中英文,贵阳网站开发Kafka高性能相关
1 高性能原因
1.1 高效使用磁盘
#xff08;1#xff09;顺序写磁盘#xff0c;顺序写磁盘性能高于随机写内存
#xff08;2#xff09;Append Only 数据不更新#xff0c;无记录级的数据删除#xff08;只会整个segment删除#xff09;
#xf… Kafka高性能相关
1 高性能原因
1.1 高效使用磁盘
1顺序写磁盘顺序写磁盘性能高于随机写内存
2Append Only 数据不更新无记录级的数据删除只会整个segment删除
3充分利用Page CacheI/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 批处理和压缩
1Producer和Consumer均支持批量处理数据从而减少了网络传输的开销
2Producer可将数据压缩后发送给broker从而减少网络传输代价。目前支持SnappyGzip和LZ4压缩
1.4 Partitio
1通过Partition实现了并行处理和水平扩展
2Partition是Kafka包括kafka Stream并行处理的最小单位
3不同Partition可处于不同的Broker充分利用多机资源
4同一Broker上的不同Partition可置于不同的Directory如果节点上有多个Disk Drive可将不同的Drive对应的Directory从而是Kafka充分利用Disk Drive的磁盘优势
1.5 ISR
1ISR实现了可用性和一致性的动态平衡
2ISR可容忍更多的节点失败。Majority Quorum如果要容忍f个节点失败至少需要2f1个节点 ISR如果要容忍f个节点失败至少需要f1个节点
3如何处理Replica CrachLeader crash后ISR中的任何replica皆可竞选称为Leader如果所有replica都crash可选择让第一个recover的replica或者第一个在ISR中的replica称为leader
2 kafka性能影响因子
1producer producer和吞吐量成正比
2consumerconsumer数据量在没有达到partition个数之前和消费的吞吐量成正比。
3partition分区格式和生成的吞吐量在一定范围内先增长当达到某一个值之后区域稳定在上下浮动。
4message-size随着message size的增大生产者对应的每秒生成的记录数在成下降趋势区里的数据体积成上升趋势。
5replication副本越大自然需要同步数据的量就越多自然kafka的生成的吞吐量就越低。
2.1 kafka脚本查看kafka集群性能
1kafka-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
2kafka-consumer-perf-test.sh查看kafka消费者的性能。
bin/kafka-consumer-perf-test.sh --topic perftest \
--broker-list bigdata01:9092,bigdata02:9092,bigdata03:9092 \
--messages 100000 #总共要读取多少条记录
结果参数
start.time2019-08-06 02:31:23:738 ---开始时间
end.time2019-08-06 02:31:24:735 ---结束时间
data.consumed.in.MB0.9534 ---总共消费的数据体积
MB.sec0.9562 ---每秒钟消费数据体积
data.consumed.in.nMsg100000 ---总共消费的数据记录数
nMsg.sec100300.9027 ---每秒钟消费记录数
rebalance.time.ms47 ---进行rebalance的时间
fetch.time.ms950 ---抓取这10w条数据总共花费多长时间
fetch.MB.sec1.0035 ---每秒钟抓取数据体积
fetch.nMsg.sec105263.1579 ---每秒钟抓取数据记录数
