Hexo

LLM 推理优化学习主干道前置差距分析 分析日期：2026-03-29 前置能力 是否具备 处理方式 Transformer / Attention 基本概念 ❌ 缺失 纳入主干道节点 01 C++ 基础（指针、内存模型、RAII） ❌ 缺失 纳入主干道节点 02-03 CUDA 执行模型（thread/warp/block/shared memory） ❌ 缺失 纳入主干道节点 04-05 GPU 内存层级（HBM/SRAM/带宽瓶颈） ❌ 缺失 纳入主干道节点 06 LLM 推理系统（KV cache、batching、调度） ❌ 缺失 纳入主干道节点 07-11 OS 底层（内存管理、进程、调度） ✅ 已具备 节点 06、08 直接复用 向量化执行引擎经验（Gluten） ⚠️ 部分相关 节点 05、09 作为理解锚点 Java / Spark Infra 经验 ✅ 已具备 节点 11 系统设计时复用 核心抽象LLM 推理优化是一个 在有限硬件资源上最大化语...

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 删除该消息 处理失败可以 ...

01 · Transformer 结构与 Attention 计算 目标：理解 LLM 推理时到底在算什么——从 token 输入到新语义向量输出的完整计算流程 一、推理的本质：一切都是矩阵乘法神经网络是一个函数：输入一组数字，输出一组数字。推理（Inference）就是执行这个函数，不涉及任何参数更新。 LLM 推理： 输入：一串 token（文字被切分并编码成数字序列） 输出：下一个 token 的概率分布 整个推理过程中，绝大部分计算量只有一种运算：矩阵乘法（GEMM）。这是 GPU 适合做推理的根本原因——GPU 专为大规模并行矩阵乘法设计。 二、Attention 出现之前：RNN 的问题RNN 处理语言序列的方式是逐词传递隐状态： 123"猫" → [RNN] → h₁"喜欢" → [RNN, 读入 h₁] → h₂"鱼" → [RNN, 读入 h₂] → h₃ 问题：隐状态每传一步就被压缩一次，越早的词信息越难保留。处理”鱼”时，”猫”的信息已经被稀释了两次。这叫长程依赖问题。 另一个问题：必须...