Kafka为什么速度很快
其他网址
Kafka为什么吞吐量大、速度快？_开着奥迪卖小猪-CSDN博客_kafka为什么吞吐量大
Kafka 为什么那么快的 6 个原因！_勇往直前的专栏-CSDN博客
kafka为什么这么快？_guangxia_0430的博客-CSDN博客_kafka为什么快
简介
kafka是分布式消息系统，一般用于处理海量的消息，Kafka高性能、高吞吐、低延时。
Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强大的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几种方式实现了超高的吞吐率。
1.顺序读写硬盘
简介
Kafka将消息记录到本地磁盘中，采用的是顺序读写的方式（message是不断追加到本地磁盘文件末尾的，而不是随机的写入）。
磁盘的随机读写很慢，但磁盘的顺序读写性能却很高，一般而言要高出磁盘随机读写三个数量级。
如下图所示，kafka官方给出了测试数据 (Raid-5,7200rpm)：顺序 I/O：600MB/S；随机 I/O: 100KB/S。链接：https://kafka.apache.org/documentation/#persistence
详解
顺序写：Kafka 中每个分区是一个有序的，不可变的消息序列，新的消息不断追加到 partition 的末尾，这个就是顺序写。
顺序读：每个消费者（Consumer）对每个Topic都有一个offset用来表示读取到了第几条数据 ：
如上图所示：假设两个消费者ConsumerA和B都从一个Topic的一个Partition读数据，ConsumerA和B都有一个offset，这个offset是由客户端SDK负责保存的，Kafka的Broker完全无视这个东西的存在；一般情况下SDK会把它保存到zookeeper里面。(所以需要给Consumer提供zookeeper的地址)。
删除数据
由于磁盘有限，不可能保存所有数据，实际上作为消息系统 Kafka 也没必要保存所有数据，需要删除旧的数据。又由于顺序写入的原因，所以 Kafka 采用各种删除策略删除数据的时候，并非通过使用“读 - 写”模式去修改文件，而是将 Partition 分为多个 Segment，每个 Segment 对应一个物理文件，通过删除整个文件的方式去删除 Partition 内的数据。这种方式清除旧数据的方式，也避免了对文件的随机写操作。
Kakfa提供了两种策略来删除数据。一是基于时间，二是基于partition文件大小。
2.Page Cache
简介
为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。这样做的好处有：
- 避免Object消耗：如果是使用 Java 堆，Java对象的内存消耗比较大，通常是所存储数据的两倍甚至更多。
- 避免GC问题：随着JVM中数据不断增多，垃圾回收将会变得复杂与缓慢，使用系统缓存就不会存在GC问题
详解
使用 Page Cache 的好处：
- I/O Scheduler 会将连续的小块写组装成大块的物理写从而提高性能
- I/O Scheduler 会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间
- 充分利用所有空闲内存（非 JVM 内存）。如果使用应用层 Cache（即 JVM 堆内存），会增加 GC 负担
- 读操作可直接在 Page Cache 内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过 Page Cache）交换数据
- 如果进程重启，JVM 内的 Cache 会失效，但 Page Cache 仍然可用
Broker 收到数据后，写磁盘时只是将数据写入 Page Cache，并不保证数据一定完全写入磁盘。从这一点看，可能会造成机器宕机时，Page Cache 内的数据未写入磁盘从而造成数据丢失。但是这种丢失只发生在机器断电等造成操作系统不工作的场景，而这种场景完全可以由 Kafka 层面的 Replication 机制去解决。如果为了保证这种情况下数据不丢失而强制将 Page Cache 中的数据 Flush 到磁盘，反而会降低性能。也正因如此，Kafka 虽然提供了 flush.messages 和 flush.ms 两个参数将 Page Cache 中的数据强制 Flush 到磁盘，但是 Kafka 并不建议使用。
3.零拷贝
简介
Kafka 的生产和消费两个过程都使用了零拷贝（zero copy）：
网络数据持久化到磁盘 (Producer 到 Broker)。（使用了mmap）
磁盘文件通过网络发送（Broker 到 Consumer）。（使用了DMA）
零拷贝
零拷贝（Zero-copy）技术指在计算机执行操作时，CPU 不需要先将数据从一个内存区域复制到另一个内存区域，从而可以减少上下文切换以及 CPU 的拷贝时间。它的作用是减少数据拷贝次数，减少系统调用，实现 CPU 的零参与，彻底消除 CPU 在这方面的负载。
目前零拷贝技术主要有三种类型：
- 直接I/O：数据直接跨过内核，在用户地址空间与I/O设备之间传递，内核只是进行必要的虚拟存储配置等辅助工作；
- 避免内核和用户空间之间的数据拷贝：当应用程序不需要对数据进行访问时，则可以避免将数据从内核空间拷贝到用户空间
- mmap
- sendfile
- splice && tee
- sockmap
- copy on write：写时拷贝技术，数据不需要提前拷贝，而是当需要修改的时候再进行部分拷贝。
网络数据持久化到磁盘 (Producer 到 Broker)
传统的数据传输
这一过程实际上发生了四次数据拷贝（还伴随着四次上下文切换）：
- 首先通过 DMA copy 将网络数据拷贝到内核态 Socket Buffer
- 然后应用程序将内核态 Buffer 数据读入用户态（CPU copy）
- 接着用户程序将用户态 Buffer 再拷贝到内核态（CPU copy）
- 最后通过 DMA copy 将数据拷贝到磁盘文件
Kafka利用mmap进行传输
Memory Mapped Files：简称 mmap，将内核中读缓冲区（read buffer）的地址与用户空间的缓冲区（user buffer）进行映射。从而实现内核缓冲区与应用程序内存的共享，省去了将数据从内核读缓冲区（read buffer）拷贝到用户缓冲区（user buffer）的过程。它的工作原理是直接利用操作系统的 Page 来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上。
使用这种方式可以获取很大的 I/O 提升，省去了用户空间到内核空间复制的开销。
mmap 也有一个很明显的缺陷：不可靠，写到 mmap 中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用 flush 的时候才把数据真正的写到硬盘。Kafka 提供了一个参数——producer.type 来控制是不是主动flush；如果 Kafka 写入到 mmap 之后就立即 flush 然后再返回 Producer 叫同步(sync)；写入 mmap 之后立即返回 Producer 不调用 flush 就叫异步(async)，默认是 sync。
磁盘文件通过网络发送（Broker 到 Consumer）
传统的数据传输
传统方式实现：先读取磁盘、再用 socket 发送，实际也是进过四次 copy。
这一过程可以类比上边的生产消息：
- 首先通过系统调用将文件数据读入到内核态 Buffer（DMA 拷贝）
- 然后应用程序将内存态 Buffer 数据读入到用户态 Buffer（CPU 拷贝）
- 接着用户程序通过 Socket 发送数据时将用户态 Buffer 数据拷贝到内核态 Buffer（CPU 拷贝）
- 最后通过 DMA 拷贝将数据拷贝到 NIC Buffer
Kafka利用sendFile进行传输
总共发生 2 次内核数据拷贝、2 次上下文切换和一次系统调用，消除了 CPU 数据拷贝
Linux 2.4+ 内核通过 sendfile 系统调用，提供了零拷贝。数据通过 DMA 拷贝到内核态 Buffer 后，直接通过 DMA 拷贝到 NIC Buffer，无需 CPU 拷贝。这也是零拷贝这一说法的来源。除了减少数据拷贝外，因为整个读文件 - 网络发送由一个 sendfile 调用完成，整个过程只有两次上下文切换，因此大大提高了性能。
4.并行
概述
- 由于不同 Partition 可位于不同机器，因此可以充分利用集群优势，实现机器间的并行处理。
- 由于 Partition 在物理上对应一个文件夹，即使多个 Partition 位于同一个节点，也可通过配置让同一节点上的不同 Partition 置于不同的磁盘上，从而实现磁盘间的并行处理，充分发挥多磁盘的优势。
详解
Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。
通过这种分区分段的设计，Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度。
5.批量读写
简介
在向Kafka写入数据时，可以启用批次写入，这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。假设网络带宽为10MB/S，一次性传输10MB的消息比传输1KB的消息10000万次显然要快得多。
详解
kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去，然后将这批数据flush到磁盘(partition的segement)文件。比如可以指定缓存的消息达到某一个量的时候就发出去，或者缓存了固定的时间后就发送出去。比如：达到100条消息就发送，或者每5秒发送一次，这种策略将大大减少服务端的I/O次数。
(Message)消息flush到磁盘上，flush策略，以下两个参数在server.properties文件中
log.flush.interval.messages=
log.flush.interval.ms=
6.数据压缩
简介
Producer 可将数据压缩后发送给 broker，从而减少网络传输代价。
详解
- Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩。（如果每个消息都压缩，压缩率相对较低。）
- Kafka允许使用递归的消息集合，批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式，直到被消费者解压缩
- Kafka支持多种压缩协议，包括Gzip、Snappy、LZ4