Hexo

Kafka 学习主干道核心抽象Kafka 是一个持久化的分布式日志系统，所有设计围绕一个核心约束展开： 消息是不可变的、有序的、可重放的日志，消费者通过 offset 自主控制读取位置 从这个约束出发，可以推导出它的所有设计决策： 抽象 一句话 Topic / Partition 日志的逻辑分组与物理分片，分片是并发和扩展的基本单位 Offset 消费者在分区日志中的位置指针，由消费者自己管理 Consumer Group 一组消费者共同消费一个 topic，每个分区只被组内一个消费者消费 Replication / ISR 分区副本机制，ISR 决定谁有资格成为 leader Producer Acks 生产者对”写入成功”的定义，决定可靠性与延迟的取舍 Log Segment 分区在磁盘上的物理存储单元，append-only，支持顺序写 主干道节点 # 文件 内容 状态 1 01-core-concepts.md Topic / Partition / Offset / C...

01 · Core Concepts 目标：理解 Kafka 的四个核心抽象及其关系，能画出消息从 produce 到 consume 的完整路径 核心概念TopicTopic 是逻辑概念，是消息的命名分类单位（如 order-events、user-clicks）。Topic 本身不存储数据，真正存储数据的是 partition。 PartitionPartition 是物理存储单元。每个 partition 在磁盘上是一个目录，目录下包含多个 segment 文件（.log、.index、.timeindex）。Kafka 按大小或时间把数据切割成多个 segment，避免单个文件无限增长。 Partition 解决两个问题： 并行度：多个 partition 分布在不同 broker 上，读写可以同时进行，吞吐量线性扩展。消费端同理，N 个 partition 最多支持 N 个消费者并行消费。 水平扩展：partition 是 Kafka 的最小分布单元，不同 partition 可以在不同 broker 上，单个 topic 的数据量不受单台机器限制。 注意：pa...

02 · 日志抽象与 Push vs Pull 目标：理解 Kafka 的存储基础——日志抽象，以及消费模型选择 Pull 的设计动机 核心概念一、什么是日志日志是最简单的存储抽象：只追加、全局有序、按时间排列的记录序列。 每条记录追加到末尾，每条记录被分配一个唯一的单调递增序号。这个序号定义了一种”时间”概念——序号小的记录比序号大的旧。 关键性质：这种”时间”与物理时钟无关。 在分布式系统里，不同机器的物理时钟不同步，即使同步了，同一毫秒内发生的两件事也无法用物理时间判断先后。日志序号解决的是全局定序问题——整个系统里所有事件有一个统一的、无歧义的顺序。这是 Kafka 能作为”事件的单一来源”的基础。 注意区分两种”日志”： 应用日志（log4j、syslog）：给人读的非结构化文本 数据日志（Kafka partition）：给程序读的结构化序列，是这里讨论的概念 二、只追加带来的三个好处1. 顺序写性能极高 磁盘随机写慢，顺序写可以接近内存速度。日志只追加意味着所有写入都是顺序的，Kafka 因此能在普通机械硬盘上达到很高的吞吐量。 2. 消息不因消费而删除，...

03 · 存储设计：Segment、Page Cache、零拷贝、Retention、Log Compaction 目标：理解 Kafka partition 在磁盘上的物理结构，以及高性能背后的存储设计 核心概念一、Segment：Partition 的物理存储单元一个 partition 目录下有多组文件，每组对应一个 Segment： 12345678/data/kafka/order-events-0/├── 00000000000000000000.log ← segment 1 的消息数据├── 00000000000000000000.index ← segment 1 的 offset 稀疏索引├── 00000000000000000000.timeindex ← segment 1 的时间索引├── 00000000000001048576.log ← segment 2├── 00000000000001048576.index├── 00000000000001048576.timeindex└── ... 文...

03 · Replication / ISR / Leader Election 目标：理解 Kafka 如何通过副本机制保证数据不丢，以及 ISR、Leader Election、acks 的设计取舍 核心概念一、为什么需要副本单台 broker 随时可能挂掉。如果 partition 只存在一台 broker 上，broker 挂了数据就永远丢了。 解决方案是副本（Replica）：每个 partition 在多台 broker 上各存一份。副本数量由 replication factor 控制，比如 replication factor = 3，意味着这个 partition 在 3 台不同的 broker 上各有一份完整数据。 二、Leader 和 Follower多个副本里，有且只有一个是 Leader，其余是 Follower。 Leader：负责所有读写请求。Producer 写给 Leader，Consumer 也从 Leader 读。 Follower：唯一职责是从 Leader 同步数据，保持冗余备份，不直接服务读写请求。...

06 · Producer：路由、批量、压缩、幂等、事务、Exactly-Once 目标：理解 Producer 的完整工作机制——从消息如何路由、如何提升吞吐，到如何保证数据可靠性 一、key 路由：消息写入哪个 PartitionProducer 直接把消息发给目标 partition 的 leader broker，没有中间路由层。路由方式有三种： 1. 指定 key（语义分区）对 key 做哈希映射到某个 partition。相同 key 的消息永远进同一个 partition，实现局部保序。 局部保序的核心价值：让有因果关系的事件在消费侧天然有序，简化业务逻辑。 例：用 order_id 作为 key，同一个订单的”创建、支付、发货”三个事件全在同一个 partition，消费者按顺序读就能拿到完整的状态变更序列，不需要跨 partition 聚合。 2. 随机分配（无 key）消息随机分配到各个 partition，实现负载均衡，不保证顺序。 3. 自定义分区函数完全覆盖默认的 hash 策略，实现业务定制的路由逻辑。 二、批量发送：用延迟换吞吐Producer...

05 · Consumer：Rebalance 与 Offset 提交策略 目标：理解 Consumer Group 如何协调 partition 分配，以及 offset 提交策略的取舍 核心概念一、Group Coordinator 与 Group LeaderGroup Coordinator（GC）：某个 Broker 上的组件，负责管理 Consumer Group 的成员关系和协调流程。不负责计算分配方案，只负责协调过程和下发结果。 Group Leader（GL）：Coordinator 从 JoinGroup 的成员中选出的一个 Consumer，负责计算 partition 分配方案，计算完成后发回给 Coordinator，再由 Coordinator 通知所有成员。 12345678Consumer 启动→ 找到 Group Coordinator（特定 broker）→ 发送 JoinGroup 请求→ Coordinator 选出 Group Leader→ Group Leader 计算 partition 分配方案→ 发回给 Coordinato...

08 · KRaft：为什么去掉 ZooKeeper，元数据如何管理 目标：理解 ZooKeeper 模式的根本问题，以及 KRaft 如何用内部机制替代它 一、ZooKeeper 模式是什么Kafka 4.0 之前，集群元数据（哪些 broker 在线、partition leader 是谁、ISR 列表、topic 配置）由外部的 ZooKeeper 集群管理。运维 Kafka 意味着同时运维两套系统。 二、ZooKeeper 模式的三个核心问题1. 元数据状态经常不一致 ZooKeeper 用 watch 机制监控元数据变化，但 watch 机制性能有限，经常导致 ZooKeeper 里的元数据和 broker 内存里的状态不同步。同时，ZooKeeper 的推送通知不是原子操作，可能有些 broker 收到了变更，有些没收到，导致不同 broker 对集群状态的认知出现分歧。 2. 扩展性瓶颈 所有元数据都存在 ZooKeeper 里，ZooKeeper 的容量和性能成了 Kafka 集群规模的上限，直接限制了单个集群能支持的 partition 数量。 3. 运维...

09 · 工程定位：Kafka 在真实系统中的角色与取舍 目标：理解 Kafka 适合什么、不适合什么，以及它在真实系统架构中的位置 一、Kafka 的本质定位高吞吐、持久化、可重放的异步数据管道。 所有设计都围绕这个定位展开：append-only log 保证高吞吐和可重放，partition 保证水平扩展，Consumer Group 保证并行消费，offset 由消费者自己管理保证解耦。 二、典型使用场景 场景 Kafka 的角色 为什么适合 数据管道 / ETL 连接数据源和目的地，解耦上下游 高吞吐、持久化、上下游独立演进 事件流处理 实时处理用户行为、交易、日志等事件流 有序、可重放、支持多消费者 日志聚合 多台服务器的日志集中收集 高吞吐写入、持久化存储、可回溯 事件溯源 用不可变日志记录所有状态变更 append-only 天然契合事件溯源模型 三、Kafka 不适合什么1. 任务队列传统任务队列（如 RabbitMQ）的工作方式： 消费者取一条消息 → 处理 → ack → broker 删除该消息 处理失败可以 ...

array 121.买卖股票的最佳时机 215.数组中的第k个最大元素 54.螺旋矩阵 56.合并区间 560.和为-k-的子数组 88.合并两个有序数组 912.排序数组 bfs 102.二叉树的层序遍历 103.二叉树的锯齿形层序遍历 binary_search 34.在排序数组中查找元素的第一个和最后一个位置 4.寻找两个正序数组的中位数 69.x-的平方根 dfs 200.岛屿数量 22.括号生成 39.组合总和 40.组合总和-ii 46.全排列 695.岛屿的最大面积 79.单词搜索 dp 1143.最长公共子序列 122.买卖股票的最佳时机-ii 152.乘积最大子数组 198.打家劫舍 300.最长递增子序列 322.零钱兑换(递归) 322.零钱兑换(递推) 416.分割等和子集 516.最长回文子序列 53.最大子数组和 64.最小路径和(递归) 64.最小路径和(递推) 70.爬楼梯 72.编辑距离(递归) 72.编辑距离(递推) graph 207.课程表 linkedlist 141.环形链表 143.重排链表 148.排序链表 160.相交...