Kafka架构学习

上文回顾

kafka架构图

  • 生产者（Producer）通过发送数据到Kafka集群
  • Kafka集群包含多个Broker（节点），每个Broker中有多个Topic分区：
    • Topic-A
    • Topic-B
    • Topic-C
  • 每个Topic的分区都有一个Leader和多个Follower，用于数据复制和故障转移
  • 消费者组（Consumer Group）包含多个消费者，它们从Kafka集群中读取数据，消费者组就是让多个消费者并行消费信息而存在的，而且它们不会消费到同一个消息。

这种架构设计实现了高可用性和水平扩展能力，即使某个Broker发生故障，系统仍能继续运行。

Controller

熟知一个规律：在大数据分布式文件系统里面，95%的都是主从式的架构，个别是对等式的架构，比如ElasticSearch。

kafka也是主从式的架构，主节点就叫controller，其余的为从节点，controller是需要和zookeeper进行配合管理整个kafka集群。

不过在2.8后引入了KRaft替代了zookeeper，甚至在4.0之后废弃了zookeeper。

kafka和zookeeper如何配合工作以及KRaft

较老版本的kafka严重依赖于zookeeper集群。所有的broker在启动的时候都会往zookeeper进行注册，目的就是选举出一个controller，这个选举过程非常简单粗暴，就是一个谁先谁当的过程，不涉及什么算法问题。

那成为controller之后要做啥呢，它会监听zookeeper里面的多个目录，例如有一个目录/brokers/，其他从节点往这个目录上注册（就是往这个目录上创建属于自己的子目录而已） 自己，这时命名规则一般是它们的id编号，比如/brokers/0,1,2

注册时各个节点必定会暴露自己的主机名，端口号等等的信息，此时controller就要去读取注册上来的从节点的数据（通过监听机制），生成集群的元数据信息，之后把这些信息都分发给其他的服务器，让其他服务器能感知到集群中其它成员的存在 。

再kafka2.8版本之后，kafka引入了KRaft协议，旨在一处kafka对zookeeper进行元数据管理的依赖的依赖。

KRaft vs zookeeper

KRaft vs zookeeper

优势

  1. KRaft enables right-sized clusters, meaning clusters that are sized with the appropriate number of brokers and compute to satisfy a use case’s throughput and latency requirements, with the potential to scale up to millions of partitions
  2. Improves stability, simplifies the software, and makes it easier to monitor, administer, and support Kafka
  3. Allows Kafka to have a single security model for the whole system
  4. Unified management model for configuration, networking setup, and communication protocols
  5. Provides a lightweight, single-process way to get started with Kafka
  6. Makes controller failover near-instantaneous

​ 1. KRaft 支持按需扩展的集群规模，也就是说，可以根据具体业务的吞吐量和延迟需求，合理配置 Broker 数量和计算资源，同时具备扩展到百万级分区的能力。

​ 2. 提升了稳定性，简化了 Kafka 的整体架构，同时也降低了运维、监控与支持的复杂度。

​ 3. Kafka 全系统统一的安全模型得以实现，避免了原先 Zookeeper 和 Kafka 分别维护安全配置的麻烦。

​ 4. 提供了统一的管理模型，包括配置管理、网络设置以及通信协议等，使 Kafka 的部署和维护更加一致、标准化。

​ 5. 支持轻量级的单进程启动方式，降低了 Kafka 的上手门槛，特别适合本地开发和测试环境。

​ 6. 实现了几乎瞬时的控制器故障切换，极大提升了系统的可用性和稳定性。

性能

主要有三个方向：持久化存储、网络IO效率、消息可靠性

这里简易讲解持久化，之后分章节对各个方西那个进行讲解

持久化存储

Kafka严重依赖于文件系统和缓存消息，并且是在JVM上构建的程序，因此内存利用效率是在持久化过程中影响性能的一大要素。

  • 首先，要指出一大误区，磁盘io并不总是远远慢于内存io。

磁盘io那些事

影响磁盘性能的因素：

  1. 寻道时间(Tseek 3-15ms)
  2. 旋转延迟(Trotation)
  3. 数据传输的时间

事实上磁盘的连续读写性能很好，但是随机读写就会大大增加寻道时间。

在具有六个 7200rpm SATA RAID-5 阵列的 JBOD 配置上，线性写入的性能约为 600MB/秒，但随机写入的性能仅为 100k/秒，相差超过 6000 倍。

而Kafka就是采用连续读写的方式很好的减少了寻道时间

  • 其次JVM在数据存储上有很大的劣势
  1. 内存开销很大
  2. 随着对内存数据的增加，gc的操作会带来性能下降

因此Kafka采用紧凑的二进制日志的方式存储数据，同时引入PageCache用于缓存数据。