kafka 总结

淡淡的烟草味﹌ 2024-03-24 14:45 5阅读 0赞

## kafka 为什么快 ##

1.  分布式架构：Kafka 是一个分布式系统，可以将数据分散到多个节点上进行处理。数据生产者和消费者可以通过多个分区（Partition）并发地读写数据，从而提高系统的处理能力
2.  顺序读写磁盘分为顺序读写与随机读写，磁盘的顺序读写性能却很高，kafka 这里采用的就是顺序读写。
3.  Kafka 利用了操作系统本身的 Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。Page Cache 就是当往磁盘文件写入的时候，系统会先将数据流写入缓存中，但是什么时候将缓存的数据写入文件中是由操作系统自行决定。所以如果此时机器突然挂了，也是会丢失消息的。这个和Java NIO中的内存映射基本相同，mmf （Memory Mapped Files）直接利用操作系统的Page来实现文件到物理内存的映射，完成之后对物理内存的操作会直接同步到硬盘。
4.  零拷贝Kafka使用了零拷贝技术，也就是直接将数据从内核空间的读缓冲区直接拷贝到内核空间的 socket 缓冲区，然后再写入到 NIC 缓冲区，避免了在内核空间和用户空间之间穿梭。虚拟内存，可以把内核空间地址和用户空间的虚拟地址映射到同一个物理地址
5.  分区分段+索引，消息实际上是分布式存储在一个一个小的 segment 中的，每次文件操作也是直接操作的 segment。为了进一步的查询优化，Kafka 又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度。
6.  批量读写
7.  批量压缩

## **kafka 控制器是什么** ##

ISR：Leader 维护了一个动态的 ISR，当 leader 向 follower 中同步数据时间超过某个阀值的时候，该 follower 就会被提出 ISR  
在 Kafka 集群中会有一个或多个 broker，其中有一个 broker 会被选举为控制器，它负责管理整个集群中所有分区和副本的状态，kafka 集群中只能有一个控制器。当某个分区的 leader 副本出现故障时，由控制器负责为该分区选举新的 leader 副本。当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有 broker 更新其元数据信息。当为某个 topic 增加分区数量时，由控制器负责分区的重新分配

## **kafka 为什么抛弃zk** ##

从 Kafka 2.8.0 版本开始，Kafka 开始支持无 ZooKeeper 集群模式，这个特性也被称为 Kafka 无状态化（KIP-500）。这个特性的主要原因是为了简化 Kafka 集群的部署和管理，同时提高系统的可扩展性和可靠性。

在以前的版本中，ZooKeeper 被用来维护 Kafka 集群的元数据（例如分区的副本分布、消费者的消费进度等），同时也被用作领导者选举的机制。由于 ZooKeeper 的性能和可靠性受到了一定的限制，因此在高负载的情况下可能会影响 Kafka 集群的性能和可用性。此外，Kafka 和 ZooKeeper 之间的网络通信和协议的复杂性也增加了系统的复杂度。

为了解决这些问题，Kafka 开始支持无 ZooKeeper 集群模式，将元数据存储在 Kafka 集群的内部，同时引入了 Raft 协议，作为领导者选举和元数据同步的机制，Raft节点是去中心化的架构，不依赖外部的组件，而是作为一个协议簇嵌入到应用中的，即与应用本身是融合为一体的。在无 ZooKeeper 集群模式下，Kafka 集群可以更加简单、灵活、可靠地进行部署和管理，同时提高了系统的可扩展性和可靠性。

## kafka 实现事务和 Exactly Once ##

Kafka 从 0.11 版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

### Producer事务： ###

生产者端的事务管理 Kafka生产者端的事务管理主要涉及到以下几个API：

*  initTransactions：初始化事务，为一个事务分配一个唯一的事务ID。
 *  beginTransaction：开始事务，将消息写入事务日志，并锁定分配给该事务的分区。
 *  send：向主题发送消息，将消息写入生产者缓冲区。
 *  commitTransaction：提交事务，将所有消息写入主题，并释放该事务占用的所有资源。
 *  abortTransaction：中止事务，清空生产者缓冲区，释放该事务占用的所有资源。

生产者使用beginTransaction API开启一个事务，随后通过send API发送一系列消息。这些消息会被写入生产者缓冲区，但并不会立即写入主题分区。当所有的消息都已发送后，生产者使用commitTransaction API将这些消息一次性写入主题分区，完成事务提交。如果发生了错误或者需要回滚事务，生产者可以使用abortTransaction API将所有未提交的消息从生产者缓冲区清除。

### Consumer 事务 ###

与Kafka生产者不同，Kafka Consumer没有显式的事务API。但是，Kafka Consumer可以与外部的事务管理器集成，从而实现基于事务的消息处理。

具体来说，Kafka Consumer可以与外部事务管理器（如Apache Flink或Apache Spark Streaming）集成，或者手动提交 offset，通过以下步骤实现基于事务的消息处理：

*  事务管理器向Kafka服务端发送开启事务的请求，并分配一个唯一的事务ID。
 *  Kafka Consumer从Kafka服务端读取消息，并将这些消息缓存在本地缓存中，而不是立即将它们提交到外部存储系统中。
 *  Kafka Consumer将消息发送到事务管理器，将这些消息绑定到先前分配的事务ID上。
 *  事务管理器在接收到所有消息后，执行相应的处理逻辑，并将结果写入外部存储系统中。如果处理成功，则事务管理器会向Kafka服务端发送事务提交请求；否则，事务管理器会向Kafka服务端发送事务回滚请求。
 *  Kafka服务端将收到的事务请求记录在事务日志中，并根据请求的类型执行相应的操作。

通过这种方式，Kafka Consumer可以与外部事务管理器集成，实现基于事务的消息处理。但是需要注意的是，这种方式可能会导致一些性能问题和消息处理延迟，因为它需要将消息缓存在本地缓存中，并且需要通过网络将消息发送到外部事务管理器中。因此，在实现基于事务的消息处理时，需要权衡性能和可靠性，并根据具体应用场景进行优化和调整。

### 实现Exactly Once ###

Kafka实现Exactly Once的关键在于事务，具体而言，Kafka生产者使用事务机制来保证消息的Exactly Once语义。Kafka生产者通过在事务中将消息写入到Kafka Broker中，只有在事务成功提交后才将消息标记为已提交。如果事务回滚，则消息也将被回滚，从而保证了消息的Exactly Once语义。

Kafka生产者实现Exactly Once主要涉及以下几个步骤：

*  初始化事务：在事务开始前，生产者会向Kafka Broker发送一个请求，该请求包含了生产者想要创建事务的请求。
 *  写入消息：在事务中，生产者可以将多条消息写入Kafka Broker，这些消息都将被标记为未提交状态。
 *  提交事务：如果所有消息都成功写入Kafka Broker，生产者会将事务提交到Kafka Broker中。在事务提交成功后，所有已写入的消息将被标记为已提交状态，如果在提交事务前发生了任何错误，事务将被回滚。
 *  关闭事务：当生产者不再写入任何消息时，它可以关闭当前事务。如果在关闭事务之前发生了错误，事务将被回滚。

此外，为了实现Exactly Once，Kafka消费者端还需要实现幂等性和事务性，以保证消息不会被重复消费或丢失。

在Kafka 0.11版本及以后的版本中，Kafka引入了Transactional API和Idempotent Producer API来支持Exactly Once。Transactional API允许生产者通过事务机制实现Exactly Once，而Idempotent Producer API则通过保证消息的幂等性来实现Exactly Once。