Kafka 架构与核心概念

2026-10-28

前言

本文从概念层面介绍 Kafka 是什么、整体架构、核心概念（Topic、Partition、Replica、ISR、消费组）以及一条消息从生产到消费的完整流转路径。

版本

Kafka 2.8.2

一、Kafka 是什么

Kafka 最初由 LinkedIn 开发，后捐赠给 Apache 基金会，是一个用 Scala/Java 编写的分布式事件流平台。它常被称作消息队列，但更准确的定位是分布式提交日志平台——核心是一个高吞吐、可持久化、可分区的追加式日志。

它解决的核心问题：

高吞吐的消息发布与订阅：单机每秒可处理数十万条消息
消息持久化：消息落盘，消费后按 retention 策略保留一段时间，支持多消费者重复消费
水平扩展：通过分区把负载分散到多个 Broker
故障容忍：通过副本机制，单个 Broker 宕机不影响服务

和传统消息队列（如 RabbitMQ）相比，Kafka 的设计取向不同：RabbitMQ 侧重灵活路由和即发即收，消息被消费后即删除；Kafka 侧重日志的持久化和顺序，消息按 offset 保留，消费者可以任意回退重读。这个差异决定了后面所有核心概念的设计。

more >>

展开全文 >>

Flink Checkpoint 源码（二）：Barrier 对齐与状态快照

2026-10-13

前言

上一篇分析了 JobManager 端 CheckpointCoordinator 的触发链路：从定时触发、请求决策，到发送触发 RPC、收齐确认、完成 Checkpoint。这一篇转到 TaskManager 端，回答上一篇留下的问题：Task 收到触发请求或 Barrier 之后，如何对齐 Barrier、如何执行状态快照、如何把确认发回 JobManager。

Task 端一次 Checkpoint 的完整路径：

1	Source 注入 Barrier → Barrier 随数据流传播 → 中间 Task 对齐 → 状态快照（同步 + 异步）→ 向 JobManager 发 ack

前置知识：

版本

Flink 1.15.3

一、Task 端概览

Task 端的核心组件：

StreamTask（mailbox 线程）
  ├── SubtaskCheckpointCoordinator    快照协调器
  │     └── AsyncCheckpointRunnable   异步阶段（asyncOperationsThreadPool）
  ├── CheckpointBarrierHandler        Barrier 状态机
  │     ├── SingleCheckpointBarrierHandler   aligned / alternating / unaligned
  │     └── CheckpointBarrierTracker         AT_LEAST_ONCE（只计数不阻塞）
  ├── CheckpointedInputGate           网络层 Barrier 事件分发
  ├── OperatorChain                   算子链
  │     └── StreamOperatorStateHandler  单算子快照
  └── StateBackend                    keyed 状态 / operator 状态

分工：

CheckpointBarrierHandler 负责”何时快照”——接收各输入通道的 Barrier，执行对齐，到齐后通知 Task 快照
SubtaskCheckpointCoordinator 负责”怎么快照”——执行快照的同步阶段和异步阶段，把结果上报 JobManager
StreamOperatorStateHandler 负责”单个算子怎么快照”——调用用户算子的 snapshotState() 钩子和 StateBackend 的快照

mailbox 线程是 StreamTask 处理数据的唯一线程：数据记录、watermark、控制事件都提交到 mailbox 队列，在这个线程里串行执行。Checkpoint 同步阶段也是提交到 mailbox 执行的，因此天然和数据处理串行。

线程模型是读这篇的主线：

阶段	线程	内容
Barrier 处理（对齐）	mailbox	从网络读 Barrier、阻塞/放行通道
快照同步阶段	mailbox	prepareSnapshotPreBarrier、转发 Barrier、各算子快照（拿到 future）
快照异步阶段	asyncOperationsThreadPool	等待 future 完成、状态落盘、发 ack

同步阶段为什么必须在 mailbox 线程？Barrier 是数据流上的切割点，快照必须相对数据流”原子”——发生在两条记录之间，不能和数据处理交错。mailbox 线程是处理数据的唯一线程，同步阶段放在这里才能保证原子性。异步阶段是磁盘 IO，耗时不可控，放到线程池避免阻塞数据流。

more >>

展开全文 >>

Flink Checkpoint 源码（一）：CheckpointCoordinator 触发链路

2026-09-20

前言

本文是 Flink Checkpoint 源码分析的第一篇，聚焦 JobManager 端 CheckpointCoordinator 的触发链路：从定时调度、触发决策，到向各 Task 发送触发请求，再到收齐确认、完成 Checkpoint 的全过程。Barrier 的注入和传播属于 TaskManager 端的逻辑，将在下一篇展开。

前置知识：

Flink Checkpoint 原理：概念与整体流程

版本

Flink 1.15.3

一、CheckpointCoordinator 概览

CheckpointCoordinator 是 Checkpoint 的总调度者，运行在 JobManager 上，每个 Job 一个实例，承担三项职责：

触发：定时或按需发起 Checkpoint 请求
收集：接收各 Task 的快照确认（ack）
完成：收齐后持久化 Checkpoint 元数据，并通知 Sink 提交

它的主要组件：

CheckpointCoordinator
  ├── CheckpointRequestDecider      请求队列 + 决策（TreeSet，按优先级排序）
  ├── CheckpointPlanCalculator      计算本次 Checkpoint 涉及哪些 Task
  ├── CheckpointIDCounter           ID 分配（HA 模式走 ZooKeeper 保证单调递增）
  ├── pendingCheckpoints            进行中的 Checkpoint（LinkedHashMap<id, PendingCheckpoint>）
  ├── completedCheckpointStore      已完成的 Checkpoint（持久化元数据，淘汰旧的）
  ├── checkpointStorageView         Checkpoint 存储位置（目录初始化）
  ├── masterHooks                   外部系统钩子（如 HBase 协同快照）
  ├── failureManager                失败处理策略
  ├── timer                         单线程定时器（周期触发 + 超时取消）
  └── executor                      IO 线程池（存储初始化等异步任务）

两个线程池值得注意：timer 是单线程的，负责创建 PendingCheckpoint、abort、complete 等所有状态变更；executor 是多线程 IO 池，负责存储目录初始化等耗时操作。源码里很多方法都显式指定了运行线程，这是读触发链路的一条主线。

more >>

展开全文 >>