Kafka使用总结

1、Kafka是何如做到高性能的？

a、消息批处理减少网络通信开销，提升系统吞吐能力（先攒一波，消息以“批”为单位进行处理）

生产端：无论是同步发送还是异步发送，Kafka都不会立即就把这条消息发送出去。而是先把这条消息存放在内存中缓存起来，然后选择合适的时机把缓存中的所有消息成批的一次性发给Broker

Broker：整个处理流程中，无论是写入磁盘、从磁盘读出来、还是复制到其他副本，批消息都不会被解开，一直是作为一条“批消息”来进行处理

消费端：消息同样以批为单位进行传递，Consumer 从 Broker拉到一批消息后，在客户端进行批消息解开，再一条一条交给用户代码处理

构建批消息和解开批消息分别在发送端和消费端的客户端完成，不仅减轻了 Broker 的压力，最重要的是减少了 Broker 处理请求的次数，提升了总体的处理能力。

b、顺序读写减少寻址次数，提升磁盘 IO 性能 

        基于磁盘文件高性能顺序读写的特性来设计的存储结构 ，顺序读写相比于随机读写省去了很多寻址时间，它只要寻址一次，就可以连续地进行读写，所以性能要比随机读写要好很多（固态硬盘顺序读写的性能比随机读写快几倍、机械硬盘差距会达到几十倍)

c、利用PageCache 加速消息读写,减少 IO开销

        程序在调用系统的API进行读写文件时，实际操作的都是 PageCache（文件在内存中缓存的副本）并不会直接去读写磁盘上的文件，大部分情况下，消费读消息都会命中 PageCache，一个是读取的速度会非常快，另外一个是，给写入消息让出磁盘的 IO 资源，间接也提升了写入的性能。

        根据局部性原理，通常刚被访问的数据在短时间内再次被访问的概率很高，PageCache用来缓存最近被访问的数据，当空间不足时淘汰最久未被访问的缓存，所以读磁盘数据的时，优先在 PageCache查找，如果数据存在则可以直接返回；如果没有再从磁盘中读取，然后缓存PageCache中（消息队列的场景一般都是发送即接收，PageCache利用率很高）

        缺点：在传输大文件（GB 级别的文件）时，PageCache会不起作用，浪费一次数据拷贝，造成性能下降，即使使用了 PageCache 的零拷贝也会损失性能 

        PageCache(磁盘高速缓存)：操作系统在内存中给磁盘上文件建立的缓存

d、使用零拷贝（ZeroCopy）减少数据拷贝开销

borker中消息的消费流程：从文件中找到消息数据读到内存中；然后把消息通过网络发给客户端

1. 从文件复制数据到 PageCache 中，如果命中 PageCache，可以省掉；
2. 从 PageCache 复制到应用程序的内存空间中，也就是我们可以操作的对象所在的内存；
3. 从应用程序的内存空间复制到 Socket 的缓冲区，这个过程就是我们调用网络应用框架的 API 发送数据的过程。

        Kafka 使用零拷贝技术可以把这个复制次数减少一次，上面的 2、3 步骤两次复制合并成一次复制。直接从 PageCache 中把数据复制到 Socket 缓冲区中，这样不仅减少一次数据复制，更重要的是，由于不用把数据复制到用户内存空间，DMA 控制器可以直接完成数据复制，不需要 CPU 参与，速度更快

扩展：在Unix-like操作系统中 mmap/sendfile 用于实现零拷贝

mmap：允许将一个文件映射到进程的地址空间中，使得文件的内容可以直接通过内存访问，而无需通过读取和写入系统调用。这样可以实现零拷贝，因为数据可以直接从文件映射的内存区域传输到网络或其他设备，而无需在用户空间和内核空间之间复制数据。在Java中，可以使用FileChannel的map()方法来实现内存映射。

sendfile：是一个系统调用，允许将一个文件的内容直接从内核空间传输到另一个文件描述符（通常是网络套接字）中，无需在用户空间和内核空间之间复制数据。这可以在发送文件时实现零拷贝，在Java中，可以使用FileChannel的transferTo()方法或transferFrom()方法来使用sendfile进行文件传输

e、其他

全异步化的线程模型、高性能的异步网络传输、自定义的私有传输协议的序列化、反序列化

2、kafka是如何实现复制的？

Kafka的复制基本单位是分区，每个分区的几个副本之间采用一主多从，构成一个小的复制集群，Broker 只是这些分区副本的容器。

Kafka 写入消息时采用的是异步复制方式,消息写入主节点之后，并不马上返回写入成功，而是等待用户指定个数的副本节点都复制成功后再返回。

配置副本节点数：ISR（In Sync Replicas) 即：保持数据同步的副本 ；PS：ISR中是包含主节点的

如果所有的 ISR 节点都宕机了，分区就无法提供服务了。也可以选择配置成让分区继续提供服务，这样只要有一个节点还活着，就可以提供服务，代价是无法保证数据一致性，会丢消息。

高可用：Kafka 采用 ZooKeeper 监控每个分区的多个节点，如果发现某个分区的主节点宕机了，会通过 ZooKeeper 选举方式选出一个新的主节点，选举时会从所有 ISR 节点中来选新的主节点，这样可以保证数据一致性。