【MQ】探索 Kafka

基本概念

主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。

分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。

副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。

生产者：Producer。向主题发布新消息的应用程序。

消费者：Consumer。从主题订阅新消息的应用程序。

消费者位移：Consumer Offset。表征消费者消费进度，每个消费者都有自己的消费者位移。

消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。

重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

Kafka 的三层消息架构

第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本。

第二层是分区层，每个分区的 N 个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。

第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。最后，客户端程序只能与分区的领导者副本进行交互。

Broker 是如何持久化数据

总的来说，Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。因为只能追加写入，故避免了缓慢的随机 I/O 操作，改为性能较好的顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段。不过如果你不停地向一个日志写入消息，最终也会耗尽所有的磁盘空间，因此 Kafka 必然要定期地删除消息以回收磁盘。怎么删除呢？简单来说就是通过日志段（Log Segment）机制。在 Kafka 底层，一个日志又进一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka 会自动切分出一个新的日志段，并将老的日志段封存起来。Kafka 在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。

高性能

• 消息的顺序性、顺序写磁盘

• 零拷贝

  • RocketMQ内部主要是使用基于mmap实现的零拷贝，用来读写文件

  • 减少cpu的拷贝次数和上下文切换次数，实现文件的高效读写操作

• Kafka

零拷贝

• Kafka 使用到了 mmap 和 sendfile 的方式来实现零拷贝。分别对应 Java 的 MappedByteBuffer 和 FileChannel.transferTo

顺序写磁盘

• Kafka 采用顺序写文件的方式来提高磁盘写入性能。顺序写文件，基本减少了磁盘寻道和旋转的次数
  • 完成一次磁盘 IO，需要经过寻道、旋转和数据传输三个步骤，如果在写磁盘的时候省去寻道、旋转可以极大地提高磁盘读写的性能。
  • Kafka 中每个分区是一个有序的，不可变的消息序列，新的消息不断追加到 Partition 的末尾，在 Kafka 中 Partition 只是一个逻辑概念，Kafka 将 Partition 划分为多个 Segment，每个 Segment 对应一个物理文件，Kafka 对 segment 文件追加写，这就是顺序写文件

页缓存技术

• 应当使用本地磁盘作为存储介质。Page Cache 的存在就可以提升消息的读取速度，

批量传输与压缩消息

• 生产端有两个重要的参数：batch.size和linger.ms。这两个参数就和 Producer 的批量发送消息有关。

网络模型

• Kafka 自己实现了网络模型做 RPC。底层基于 Java NIO，采用和 Netty 一样的 Reactor 线程模型。
  • Kafka 即基于 Reactor 模型实现了多路复用和处理线程池。
  • Reactor 模型基于池化思想，避免为每个连接创建线程，连接完成后将业务处理交给线程池处理；基于 IO 复用模型，多个连接共用同一个阻塞对象，不用等待所有的连接。遍历到有新数据可以处理时，操作系统会通知程序，线程跳出阻塞状态，进行业务逻辑处理

分区并发

• Kafka 的 Topic 可以分成多个 Partition，每个 Paritition 类似于一个队列，保证数据有序。同一个 Group 下的不同 Consumer 并发消费 Paritition，分区实际上是调优 Kafka 并行度的最小单元，因此，可以说，每增加一个 Paritition 就增加了一个消费并发。

高效的文件数据结构

• 每个 Topic 又可以分为一个或多个分区。每个分区各自存在一个记录消息数据的日志文件。Kafka 每个分区日志在物理上实际按大小被分成多个 Segment。
  • segment file 组成：由 2 大部分组成，分别为 index file 和 data file，此 2 个文件一一对应，成对出现，
  • index 采用稀疏索引，这样每个 index 文件大小有限，Kafka 采用mmap的方式，直接将 index 文件映射到内存，这样对 index 的操作就不需要操作磁盘 IO
  • 分段和索引的策略：利用偏移量和时间索引文件实现快速消息查找

高可用

• Kafka

  • Kafka 从 0.8 版本开始提供了高可用机制，可保障一个或多个 Broker 宕机后，其他 Broker 能继续提供服务

分区副本、备份机制

同一个 Partition 存在多个消息副本，每个 Partition 的副本通常由 1 个 Leader 及 0 个以上的 Follower 组成，

• Kafka 会尽量将所有的 Partition 以及各 Partition 的副本均匀地分配到整个集群的各个 Broker 上
• 多副本机制
  • 分区（Partition）引入了多副本（Replica）机制。
  • 多分区、多副本机制好处呢？
    • 1. Kafka 通过给特定 Topic 指定多个 Partition分区, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力（负载均衡）。
    • 2. Partition 可以指定对应的 Replica 数, 这也极大地提高了消息存储的安全性, 提高了容灾能力，不过也相应的增加了所需要的存储空间。

ACK 机制

• • • • 生产者发送消息中包含 acks 字段，该字段代表 Leader 应答生产者前 Leader 收到的应答数
      • 「acks=0」
        • 生产者无需等待服务端的任何确认，因此 acks=0 不能保证服务端已收到消息
      • 「acks=1」默认值
        • 只要 Partition Leader 接收到消息而且写入本地磁盘了，就认为成功了，不管其他的 Follower 有没有同步
      • 「acks=all or -1」
        • 服务端会等所有的 follower 的副本受到数据后才会收到 leader 发出的 ack，这样数据不会丢失
        • Broker 有个配置项min.insync.replicas(默认值为 1)代表了正常写入生产者数据所需要的最少 ISR 个数
    • 发送的 acks=1 和 0 消息会出现丢失情况，为了不丢失消息可配置生产者acks=all & min.insync.replicas >= 2

ISR 机制

• • • • ISR 中的副本都是与 Leader 同步的副本，不在 ISR 中的Follower副本就被认为是没有资格的
      • Follower 周期性地向 Leader 发送 FetchRequest 请求，发送时间间隔配置在replica.fetch.wait.max.ms中，默认值为 500
      • 每个分区的 Leader 负责维护 ISR 列表并将 ISR 的变更同步至 ZooKeeper，被移出 ISR 的 Follower 会继续向 Leader 发 FetchRequest 请求，试图再次跟上 Leader 重新进入 ISR
      • ISR 中所有副本都跟上了 Leader，通常只有 ISR 里的成员才可能被选为 Leader

主从同步

• • • • 1、Follower副本通过发送Fetch请求来同步Leader副本上的数据。
      • LEO（Log End Offset）
        • 对于Leader副本和每个Follower副本来说，它们都有各自的LEO
        • LEO是下一个要写入的消息的偏移量
      • HW（High Watermark）
        • HW是分区中所有副本的已提交消息的最大偏移量。是分区中所有ISR（In-Sync Replicas）副本的LEO中的最小值
        • 只要分区的Leader副本和至少一个Follower副本保持同步，消费者就能看到所有已提交的消息，即使Leader副本发生故障
      • 确保了Kafka在分区的Leader副本发生故障时，可以从ISR中选举出一个Follower副本作为新的Leader，
    • Unclean 领导者选举
      • 当 Kafka 中unclean.leader.election.enable配置为 true(默认值为 false)且 ISR 中所有副本均宕机的情况下，
      • 开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性，

Leader 选举 & 故障恢复机制

• • • • 「Kafka 从 0.8 版本开始引入了一套 Leader 选举及失败恢复机制」
      • 在集群所有 Broker 中选出一个 Controller，负责各 Partition 的 Leader 选举以及 Replica 的重新分配
      • Controller
        • 集群中的 Controller 也会出现故障，因此 Kafka 让所有 Broker 都在 ZooKeeper 的 Controller 节点上注册一个 Watcher。
      • 当出现 Leader 故障后，Controller 会将 Leader/Follower 的变动通知到需要为此作出响应的 Broker。
      • Kafka 使用 ZooKeeper 存储 Broker、Topic 等状态数据，Kafka 集群中的 Controller 和 Broker 会在 ZooKeeper 指定节点上注册 Watcher(事件监听器)，以便在特定事件触发时，由 ZooKeeper 将事件通知到对应 Broker
      • 当 Broker 发生故障后，由 Controller 负责选举受影响 Partition 的新 Leader 并通知到相关 Broker