Kafka 整体架构
Kafka是大数据领域无处不在的消息中间件，目前广泛使用在企业内部的实时数据管道，并帮助企业构建自己的流计算应用程序。
Kafka虽然是基于磁盘做的数据存储，但却具有高性能、高吞吐、低延时的特点，其吞吐量动辄几万、几十上百万。
Kafka为什么速度快、吞吐量大？
Kafka是将消息记录持久化到本地磁盘中的，一般人会认为磁盘读写性能差，可能会对Kafka性能如何保证提出质疑。实际上不管是内存还是磁盘，快或慢关键在于寻址的方式，磁盘分为顺序读写与随机读写，内存也一样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢，但磁盘的顺序读写性能却很高，一般而言要高出磁盘随机读写三个数量级，一些情况下磁盘顺序读写性能甚至要高于内存随机读写。
这里给出著名学术期刊 ACM Queue 上的性能对比图： queue.acm.org/detail.cf
磁盘的顺序读写是磁盘使用模式中最有规律的，并且操作系统也对这种模式做了大量优化，Kafka就是使用了磁盘顺序读写来提升的性能。Kafka的message是不断追加到本地磁盘文件末尾的，而不是随机的写入，这使得Kafka写入吞吐量得到了显著提升 。
上图就展示了Kafka是如何写入数据的， 每一个Partition其实都是一个文件 ，收到消息后Kafka会把数据插入到文件末尾（虚框部分）。
这种方法有一个缺陷—— 没有办法删除数据 ，所以Kafka是不会删除数据的，它会把所有的数据都保留下来，每个消费者（Consumer）对每个Topic都有一个offset用来表示 读取到了第几条数据 。
两个消费者，Consumer1有两个offset分别对应Partition0、Partition1（假设每一个Topic一个Partition）；Consumer2有一个offset对应Partition2。这个offset是由客户端SDK负责保存的，Kafka的Broker完全无视这个东西的存在；一般情况下SDK会把它保存到zookeeper里面。(所以需要给Consumer提供zookeeper的地址)。
如果不删除硬盘肯定会被撑满，所以Kakfa提供了两种策略来删除数据。一是基于时间，二是基于partition文件大小。具体配置可以参看它的配置文档：http://kafka.apache.org/08/documentation/#configuration。
在kafka/config/目录下面有3个配置文件：
producer.properties
consumer.properties
server.properties
详细配置文件参考：https://www.jianshu.com/p/c5618df93b43。
Page Cache 是什么？
PageCache是OS对文件的缓存，用于加速对文件的读写。一般来说，程序对文件进行顺序读写的速度几乎接近于内存的读写访问，这里的主要原因就是在于OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache。
对于数据文件的读取，如果一次读取文件时出现未命中（cache miss）PageCache的情况，OS从物理磁盘上访问读取文件的同时，会顺序对其他相邻块的数据文件进行预读取（顺序读入紧随其后的少数几个页面）。这样，只要下次访问的文件已经被加载至PageCache时，读取操作的速度基本等于访问内存。
Page Cache是针对文件系统的缓存，通过将磁盘中的文件数据缓存到内存中，从而减少磁盘I/O操作提高性能。
对磁盘的数据进行缓存从而提高性能主要是基于两个因素：
- 磁盘访问的速度比内存慢好几个数量级（毫秒和纳秒的差距）；
- 被访问过的数据，有很大概率会被再次访问。
文件 IO 读写流程
读流程
1、应用程序发起读请求，触发系统调用read()函数，用户态切换为内核态；
2、文件系统通过目录项→inode→address_space→页缓存树，查询Page Cache是否存在；
3、Page Cache不存在产生缺页中断，CPU向DMA发出控制指令；
DMA 控制器将数据从主存或硬盘拷贝到内核空间（kernel space）的缓冲区（read buffer）；
4、DMA 磁盘控制器向 CPU 发出数据读完的信号，由 CPU 负责将数据从内核缓冲区拷贝到用户缓冲区；
5、用户进程由内核态切换回用户态，获得文件数据；
写流程
1、应用程序发起写请求，触发系统调用write()函数，用户态切换为内核态；
2、文件系统通过目录项→inode→address_space→页缓存树，查询 Page Cache是否存在，如果不存在则需要创建；
3、Page Cache 存在后，CPU将数据从用户缓冲区拷贝到内核缓冲区，Page Cache 变为脏页（Dirty Page，内存数据页跟磁盘数据页内容不一致），写流程返回；
4、用户主动触发刷盘或者达到特定条件内核触发刷盘，唤醒 pdflush 线程，pdflush 将内核缓冲区的数据刷入磁盘；
脏页: 当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。
pdflush回写时机
定时方式执行；
内存不足时；
用户主动触发；
DMA传输
DMA 的全称叫直接内存存取（Direct Memory Access），是一种允许外围设备（硬件子系统）直接访问系统主内存的机制。基于 DMA 访问方式，硬件与内核缓冲区的数据传输由DMA控制器控制，CPU只需在数据传输开始和结束时做一点处理外（开始和结束时候要做中断处理），释放了CPU。目前大多数的硬件设备，包括磁盘控制器、网卡、显卡以及声卡等都支持 DMA 技术。
https://blog.csdn.net/yangguosb/article/details/77886826
2、读Cache
当内核发起一个读请求时（例如进程发起read()请求），首先会检查请求的数据是否缓存到了Page Cache中。
如果有，那么直接从内存中读取，不需要访问磁盘，这被称为cache命中（cache hit）；
如果cache中没有请求的数据，即cache未命中（cache miss），就必须从磁盘中读取数据。然后内核将读取的数据缓存到cache中，这样后续的读请求就可以命中cache了。
page可以只缓存一个文件部分的内容，不需要把整个文件都缓存进来。
3、写Cache
当内核发起一个写请求时（例如进程发起write()请求），同样是直接往cache中写入，后备存储中的内容不会直接更新（当服务器出现断电关机时，存在数据丢失风险）。
内核会将被写入的page标记为dirty，并将其加入dirty list中。内核会周期性地将dirty list中的page写回到磁盘上，从而使磁盘上的数据和内存中缓存的数据一致。
当满足以下两个条件之一将触发脏数据刷新到磁盘操作：
- 数据存在的时间超过了dirty_expire_centisecs（默认300厘秒，即30秒）时间；
- 脏数据所占内存 > dirty_background_ratio，也就是说当脏数据所占用的内存占总内存的比例超过dirty_background_ratio（默认10，即系统内存的10%）的时候会触发pdflush [note]刷新脏数据。
Kafka 对 page cache 的利用
Kafka为什么不自己管理缓存，而非要用page cache？原因有如下三点：
1.JVM中一切皆对象，数据的对象存储会带来所谓object overhead，浪费空间；
2.如果由JVM来管理缓存，会受到GC的影响，并且过大的堆也会拖累GC的效率，降低吞吐量；
3.一旦程序崩溃，自己管理的缓存数据会全部丢失。
Kafka三大件（broker、producer、consumer）与page cache的关系可以用下面的简图来表示。
producer生产消息时，会使用pwrite()系统调用【对应到Java NIO中是FileChannel.write() API】按偏移量写入数据，并且都会先写入page cache里。consumer消费消息时，会使用sendfile()系统调用【对应FileChannel.transferTo() API】，零拷贝地将数据从page cache传输到broker的Socket buffer，再通过网络传输。
图中没有画出来的还有leader与follower之间的同步，这与consumer是同理的：只要follower处在ISR中，就也能够通过零拷贝机制将数据从leader所在的broker page cache传输到follower所在的broker。
同时，page cache中的数据会随着内核中flusher线程的调度以及对sync()/fsync()的调用写回到磁盘，就算进程崩溃，也不用担心数据丢失。另外，如果consumer要消费的消息不在page cache里，才会去磁盘读取，并且会顺便预读出一些相邻的块放入page cache，以方便下一次读取。
由此我们可以得出重要的结论：如果Kafka producer的生产速率与consumer的消费速率相差不大，那么就能几乎只靠对broker page cache的读写完成整个生产-消费过程，磁盘访问非常少。这个结论俗称为“读写空中接力”。并且Kafka持久化消息到各个topic的partition文件时，是只追加的顺序写，充分利用了磁盘顺序访问快的特性，效率高。
关于 Linux 文件 IO 读写，参考：https://www.jianshu.com/p/d81f51e58b83
Java 的 IO 读写
Java的 IO读写大致分为三种：
1、普通IO(java.io)
例如FileWriter、FileReader等，普通IO是传统字节传输方式，读写慢阻塞，单向一个Read对应一个Write 。
2、文件通道 FileChannel(java.nio)
FileChannel fileChannel = new RandomAccessFile(new File("data.txt"), "rw").getChannel()
全双工通道，采用内存缓冲区ByteBuffer且是线程安全的
使用FileChannel为什么会比普通IO快？
一般情况FileChannel在一次写入4kb的整数倍数时，才能发挥出实际的性能，益于FileChannel采用了ByteBuffer这样的内存缓冲区。这样可以精准控制写入磁盘的大小，这是普通IO无法实现FileChannel是直接把ByteBuffer的数据直接写入磁盘？
ByteBuffer 中的数据和磁盘中的数据还隔了一层，这一层便是 PageCache，是用户内存和磁盘之间的一层缓存。我们都知道磁盘 IO 和内存 IO 的速度可是相差了好几个数量级。我们可以认为 filechannel.write 写入 PageCache 便是完成了落盘操作，但实际上，操作系统最终帮我们完成了 PageCache 到磁盘的最终写入，理解了这个概念，你就应该能够理解 FileChannel 为什么提供了一个 force() 方法，用于通知操作系统进行及时的刷盘，同理使用FileChannel时同样经历：
磁盘->PageCache->用户内存
这三个阶段。
3、内存映射MMAP(java.nio)
mmap的工作原理：当你发起这个 mmap 文件读写调用的时候，它只是在你的虚拟空间中分配了一段空间，连真实的物理地址都不会分配的。在你访问这段空间的时刻，CPU触发了 OS内核缺页异常[note]，执行 PageFault 异常处理，然后异常处理会在这个时间分配物理内存，并用文件的内容填充这片内存，然后才返回你进程的上下文，这时你的程序才会感知到这片内存里有数据。
Linux 是直到，实在实在是不行的时候，才会分配物理页。
https://www.zhihu.com/question/48161206/answer/110418693
note:关于缺页异常，参考：https://www.jianshu.com/p/5ff9b1b3c95e
Java 中的 mmap 实现类： MappedByteBuffer
MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, position, fileSize)
mmap 把文件映射到用户空间里的虚拟内存，省去了从内核缓冲区复制到用户空间的过程，文件中的位置在虚拟内存中有了对应的地址，可以像操作内存一样操作这个文件，相当于已经把整个文件放入内存，但在真正使用到这些数据前却不会消耗物理内存，也不会有读写磁盘的操作，只有真正使用这些数据时，也就是图像准备渲染在屏幕上时，虚拟内存管理系统 VMS
MMAP 并非是文件 IO 的银弹，它只有在一次写入很小量数据的场景下才能表现出比 FileChannel 稍微优异的性能。紧接着我还要告诉你一些令你沮丧的事，至少在 JAVA 中使用 MappedByteBuffer 是一件非常麻烦并且痛苦的事，主要表现为三点：
MMAP 使用时必须实现指定好内存映射的大小，并且一次 map 的大小限制在 1.5G 左右，重复 map 又会带来虚拟内存的回收、重新分配的问题，对于文件不确定大小的情形实在是太不友好了。
MMAP 使用的是虚拟内存，和 PageCache 一样是由操作系统来控制刷盘的，虽然可以通过 force() 来手动控制，但这个时间把握不好，在小内存场景下会很令人头疼。
MMAP 的回收问题，当 MappedByteBuffer 不再需要时，可以手动释放占用的虚拟内存。
参考资料
https://www.jianshu.com/p/958f82922e4b
https://blog.csdn.net/yancychas/article/details/88561291
https://blog.csdn.net/gx11251143/article/details/107620259
https://zhuanlan.zhihu.com/p/22604682
https://www.sohu.com/a/406019130_115128
https://blog.csdn.net/yangguosb/article/details/77886826
