标签：翻译 ade 虚拟内存 头部 单点故障 leader ibm 物理内存 获取
1. kafka 使用了 分区、分布式、leader/followere 的方式。
分布式让 kafka 排除了单点故障，分区和分区复制让数据不丢失
2. kafka 使用 zero copy 技术 (基于 linux 的 sendfile 函数)，可以减少传统数据传递时在 kernel 态和 user 态的 context 切换的空间和时间损耗。zero copy 技术使得将文件内容可以直接提交到 kenel 的 socket buffer. 避免了用户态调用 kenel 获取数据，然后用户态再将数据提交到 kenel 态的时间和空间。
zero copy : https://www.ibm.com/developerworks/linux/library/j-zerocopy/
3.kafka 使用大的 SATA 盘存储数据， 数据进入到分区的消息队列尾部，这样的磁盘顺序写比传统的 BTREE 随机写性能高了很多。磁盘顺序写的速度甚至比内存随机写都快。
消费者与生产者互相不干扰，消费者读取消息队列的头部，生产者读取消息队列的尾部。 这样没写锁，读锁。性能非常高。
即便是顺序写入硬盘，硬盘的访问速度还是不可能追上内存。所以Kafka的数据并不是实时的写入硬盘，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。
Memory Mapped Files(后面简称mmap)也被翻译成内存映射文件，在64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上（操作系统在适当的时候）
通过mmap，进程像读写硬盘一样读写内存（当然是虚拟机内存），也不必关心内存的大小有虚拟内存为我们兜底。
使用这种方式可以获取很大的I/O提升，省去了用户空间到内核空间复制的开销（调用文件的read会把数据先放到内核空间的内存中，然后再复制到用户空间的内存中。）也有一个很明显的缺陷——不可靠，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。Kafka提供了一个参数——producer.type来控制是不是主动flush，如果Kafka写入到mmap之后就立即flush然后再返回Producer叫同步(sync)；写入mmap之后立即返回Producer不调用flush叫异步(async)。
mmap其实是Linux中的一个函数就是用来实现内存映射的，谢谢Java NIO，它给我提供了一个mappedbytebuffer类可以用来实现内存映射（所以是沾了Java的光才可以如此神速和Scala没关系！！）
标签：翻译 ade 虚拟内存 头部 单点故障 leader ibm 物理内存 获取
原文地址：https://www.cnblogs.com/wq920/p/8986384.html
