kafka性能技术分析.docxVIP

kafka功能技术分析 2021-01-05 1.通过磁盘挨次读写，效率高，appendLog，对比raid-5 7200rpm的磁盘 sequence io 600M/s random io 100kb/s kafka写操作时，依靠底层文件系统的pagecache功能，pagecache会将尽量多的将空闲内存，当做磁盘缓存，写操作先写到pageCache，并将该page标记为dirty；发生读操作时，会先从pageCache中查找，当发生缺页时，才会去磁盘调整；当有其他应用申请内存时，回收pageCache的代价是很低的 ，使用pageCache的缓存功能，会削减我们队JVM的内存依靠，JVM为我们供应了GC功能，依靠JVM内存在kafka高吞吐，大数据的场景下有很多问题。假如heap管理缓存，那么JVM的gc会频繁扫描heap空间，带来的开销很大，假如heap过大，full gc带来的成本也很高；全部的In-Process Cache在OS中都有一份同样的PageCache。所以通过只在PageCache中做缓存至少可以提高一倍的缓存空间。假如Kafka重启，全部的In-Process ?Cache都会失效，而OS管理的PageCache照旧可以连续使用。 2.sendFile 传统网络IO模型 ① 操作系统将数据从磁盘拷贝到内核区的pagecache ② 用户程序将内核区的pagecache拷贝到用户区缓存 ③ 用户程序将用户区的缓存拷贝到socket缓存中 ④ 操作系统将socket缓存中的数据拷贝到网卡的buffer上，发送 问题：四次system call 两次context切换，同一份数据在缓存中拷贝多次，效率很低，拷贝动作完全可以在内核中进行，将2 3 步去掉，sendfile就是完成这一功能 kafka设计初衷是数据的拷贝完全通过pageCache来进行，尽量削减磁盘读写，假如kafka生产消费协作的好，那么数据完全走内存，这对集群的吞吐量提升是很大的 当集群只要写操作时，此时的集群只要写，没有读操作。10M/s左右的Send的流量是Partition之间进行Replicate而产生的。从recv和writ的速率比较可以看出，写盘是使用Asynchronous+Batch的方式，底层OS可能还会进行磁盘写挨次优化。而在有Read Request进来的时候分为两种情况，第一种是内存中完成数据交换。 ② 已经从pageCache刷出的数据，这时候的数据可以看出大部分走的是磁盘io TIPS ① kafka官方不建议使用erval.messages和erval.ms来强制刷盘，由于高牢靠应当通过replica副原来保证，强制刷盘对系统功能影响很大（生产是100000 和60000） ② 可以通过调整/proc/sys/vm/dirty_background_ratio和/proc/sys/vm/dirty_ratio来调优功能。 a. 脏页率超过第一个目标会启动pdflush开头Flush Dirty PageCache。 b. 脏页率超过其次个目标会堵塞全部的写操作来进行Flush。 c. 依据不同的业务需求可以适当的降低dirty_background_ratio和提高dirty_ratio。 （生产是10 和 20） 2 partition Partition是Kafka可以很好的横向扩展和供应高并发处理以及实现Replication的基础。 扩展性方面。首先，Kafka允许Partition在集群内的Broker之间任意移动，以此来均衡可能存在的数据倾斜问题。其次，Partition支持自定义的分区算法，例如可以将同一个Key的全部消息都路由到同一个Partition上去。 同时Leader也可以在In-Sync的Replica中迁移。由于针对某一个Partition的全部读写恳求都是只由Leader来处理，所以Kafka会尽量把Leader均匀的分散到集群的各个节点上，以免形成网络流量过于集中。 并发方面。任意Partition在某一个时辰只能被一个Consumer Group内的一个Consumer消费(反过来一个Consumer则可以同时消费多个Partition)，Kafka格外简约的Offset机制最小化了Broker和Consumer之间的交互，这使Kafka并不会像同类其他消息队列一样，随着下游Consumer数目的添加而成比例的降低功能。此外，假如多个Consumer恰巧都是消费时间序上很相近的数据，可以达到很高的PageCache命中率，因而Kafka可以格外高效的支持高并发读操作，实践中基本可以达到单机网卡上限。 不过，Partition的数量并不是越多越好，Partiti