四级渐进学习法 · Kafka 三层 topic · 第 4/9 篇

洪峰面前，先修水坝。

十万级终端不会匀速说话——它们会一起开口。Kafka 是链路里的水坝：三层 topic 各司其职（原始保真、标准可查、信令可追溯），洪峰进坝、Flink 匀速抽水，坝在，证据就在。

3 节点 · SASL SCRAM-SHA-512 agent-* 原始层 std_clasp_agent_* 标准层 las-* 信令层 · 40+ topic 预建
THE FRAMEWORK

先看地图，再出发THE FRAMEWORK — 链路的第四跳

全链路七跳，本页覆盖第四跳：终端 Agent → envoy mTLS → audit-gateway → Kafka（本页）→ Flink ETL → std topic → StarRocks。gateway 把原始报文交给 Kafka，Flink 再从 Kafka 取——一切削峰、解耦、重放的故事都发生在这里。

L1

受控语言

三十四句确定性短句，分五组：集群与认证、三层语义、原始层细分、信令层、为什么先 Kafka。

例：「原始层永远保留原文，标准化出错可以重放。」
L2

结构图

三张图：三层 topic 分流（可点击）、削峰水坝示意、Flink 故障重放回补。

例：水坝图里洪峰折线与匀速直线之间就是缓冲。
L3

交互网页

topic 路由器：八种载荷点一点，看各自落进哪层哪个 topic；洪峰演示：点一次洪峰，看坝内水位涨落。加六题自测。

例：token 撤销落哪层？
L4

定制视频

六镜头：洪峰进坝 → 三层水柜 → 保真 → 匀速抽水 → 重放回补 → 收尾。成片已交付 · 01:33。

例：一支片子讲完「先修水坝」。

本页名片（一分钟版）

主角：Kafka 集群（3 节点）
一句话：洪峰的缓冲池——原始保真、标准可查、信令可追溯。
三个数字：3 节点 · 三层 topic · 40+ 需预建。
解决两件事：洪峰不垮（削峰解耦）· 故障不丢（可重放）。

SASL SCRAM-SHA-512按业务拆 topic原始层保真

一句话主线（背下来，全页都在展开它）

audit-gateway → produce agent-*（原始保真）→ Flink 消费 → std_clasp_agent_*（标准可查）｜ 控制面 → las-*（信令可追溯）→ 洪峰进坝 · Flink 匀速抽水 · 故障可重放

L1 CONTROLLED LANGUAGE

受控语言：三十四句讲清水坝简短、确定、一词一义——不靠形容词，只靠事实

以下每句话都来自交接材料（Kafka Topic 列表、设计方案 v5）。读不懂的句子，去 L2 找对应的结构图。

集群与认证

§ 1 · 5 句

三层语义

§ 2 · 6 句

原始层细分

§ 3 · 10 句

信令层

§ 4 · 6 句

为什么先 Kafka

§ 5 · 7 句
L2 DIAGRAMS

结构图：水坝的真实骨架图 1 可点击三层 · 图 2 是本页的核心隐喻

三张图：先看三层 topic 怎么分流，再看削峰的几何形状，最后看 Flink 故障后怎么重放回补。

原始层 agent-* agent-audit-log-<来源>-linux secure · auth · messages · syslog kern · cron · yum · dpkg · journal windows: system / application / security agent-{heartbeat,resource,task-result}-<os> audit-gateway 生产 · 原始保真 标准化层 std_clasp_agent_* std_clasp_agent_audit_log_linux std_clasp_agent_audit_log_windows std_clasp_agent_cron_log_linux std_clasp_agent_{heartbeat,resource, 　task_result}_<os> Flink 产出 · 直写 StarRocks 业务信令层 las-* las-agent-command 任务生成 → 消费 → 待下发 las-token-credential-issue / revoke 颁发 / 撤销 token · 消费后持久化生效 控制面信令 · 非日志数据 Flink 三层各司其职：原始保真、标准可查、信令可追溯——部署前 40+ 个 topic 需全部提前创建
图 1 · 三层 topic 分流（点击任意层查看明细与角色）
点击图中的三层（agent-* / std_clasp_agent_* / las-*），这里显示它的角色与 topic 明细。
十万终端洪峰（突发） Kafka ×3 缓冲 · 削峰 缓冲水位 数据留在 topic · 不丢失 Flink 按自己的节奏消费（匀速） ETL 处理 压不垮 没有水坝：洪峰直接砸进计算层 → 雪崩 有水坝：洪峰变匀速 → 计算层永远从容
图 2 · 削峰：洪峰折线与匀速直线之间，就是 Kafka 的缓冲价值
Flink ETL ✗ 故障停止 消费暂停，但数据不丢 （Flink 恢复中…） agent-* 原始 topic offset 8000 …数据持续堆积… offset 12400 原文全在 · 保真 恢复后从 offset 8000 重放回补 正常时消费 std topic / StarRocks 重放的数据经同一套规则解析 补齐故障窗口的标准化结果 规则改对了也能重放历史 原始层是证据：Flink 挂了数据还在 topic，恢复后按 offset 重放——这就是「保真」的兜底价值
图 3 · 重放回补：故障窗口的数据一条不少地补回
L3 INTERACTIVE

交互探索：路由一跳，洪峰一次topic 路由器 + 削峰演示 + 六题自测

路由器：点八种载荷，看各自落进哪层哪个 topic、为什么。洪峰演示：每点一次「洪峰」，坝内水位涨一格，Flink 匀速抽走——涨落之间体会「削峰」。

3a · topic 路由器

8 种载荷 · 点选即路由
点上方任意一种载荷，看它落进哪层哪个 topic。

3b · 削峰演示

洪峰进坝 · 匀速抽水
坝内当前 0 条 · Flink 以 40 条/秒匀速消费
涌入速率
Kafka 缓冲水位
Flink 消费速率
初始化完成。点「发起洪峰」看水位变化。

3c · 概念自测

6 题 · 单选

已答 0 / 6 · 正确 0 · 正确率 0%

1. Kafka 集群采用哪种认证方式？

3 节点集群，SASL SCRAM-SHA-512。mTLS 是 Agent → envoy 那一关；到了 Kafka，认证换成 SASL。

2. 三层 topic 各自的语义是？

原始层保真存证、标准层支撑检索、信令层记录控制面动作——三个消费语义，各司其职。

3. Windows 原始层有哪三类来源？

Windows 三类来自事件日志通道；Linux 才是 audit、secure、auth、messages 等十类。

4. las-agent-command 的作用是？

创建任务后生成，消费后产生待下发指令——控制面的每个动作都过这条 topic，可追溯。

5. 为什么先落 Kafka 再做 ETL？

十万终端洪峰由 Kafka 缓冲，Flink 匀速消费；故障窗口的数据留在 topic，恢复后按 offset 重放——削峰 + 兜底，一举两得。

6. 关于 topic 创建，部署时必须？

agent-* 全量、std_clasp_agent_*、las-* 共 40+ 个 topic 必须部署前建好——这是部署手册明确列出的坑。
L4 VIDEO

定制视频：先修水坝六镜头 · 成片已交付 · 01:33· 分镜与解说骨架已备

六镜头沿用总览片「水坝」意象并展开：洪峰进坝、三层水柜、保真、匀速抽水、重放回补、收尾。画面里的 topic 名、节点数与 L1–L3 同源。

成片 · topic-04-kafka.mp4　✓ 已交付

00:00 开场 · 洪峰进坝 00:16 三层 · 三个水柜 00:33 削峰 · 下游永远匀速 00:48 重放 · 故障窗口回补 01:04 预建 · 40+ topic 01:18 收尾 · 不丢不堵

规格：1920×1080 · 30fps · 01:33 · H.264 + AAC · 中文配音（zh-CN-Yunxi 逐句合成，每句实测时长均落在自己的字幕窗口内）+ 画面内嵌字幕。底部常驻进度轨随镜头推进点亮。

分镜脚本

6 镜头 · 旁白即片中字幕

镜头 1 · 洪峰进坝

画面：十万终端图标同时亮起，洪峰曲线冲向一条细瘦的计算管道，管道爆红。
旁白：十万台终端不会排队说话。它们一起开口的那一秒，没有任何计算层扛得住——除非，先修一座坝。

镜头 2 · 三层水柜

画面：坝内剖开三个水柜：橙色的原始层、紫色的标准层、蓝色的信令层，各自水位独立。
旁白：坝里不是一个池，是三个柜。原始的进原始柜，标准的进标准柜，信令走自己的管道——永不相混。

镜头 3 · 原始保真

画面：一条日志原文滴进原始柜，玻璃柜壁上浮现「agent-audit-log-audit-linux」，字迹分毫未动。
旁白：原始柜有一条铁律：只进不改。无论后面怎么洗、怎么算，原文永远躺在这里——它是证据。

镜头 4 · 匀速抽水

画面：坝下 Flink 水泵匀速转动，出口水流平直；入侧洪峰忽高忽低，坝内水位缓缓起伏。
旁白：上游多猛都行，下游永远匀速。削峰不是让洪峰消失，是让计算层永远看不见洪峰。

镜头 5 · 重放回补

画面：Flink 水泵停转（红叉），原始柜水位上涨；水泵重启，倒带箭头沿 offset 回拉，故障窗口的数据重新流过。
旁白：计算层会挂，坝不会。恢复后从断点重放，故障窗口的数据一条不少地补回来。

镜头 6 · 收尾：不丢不堵

画面：全链路七跳点亮，Kafka 坝体居中发光，两侧流量平稳。
旁白：不丢，因为坝里留着原文；不堵，因为下游永远匀速。这就是消息层的答案——先修水坝，再谈计算。

解说骨架：六个设计决定

镜头 2–5 的旁白依据

① 先 Kafka 再 ETL

削峰解耦；Flink 挂了数据还在，可重放回补。

② topic 三层

原始保真、标准可查、信令可追溯——三个消费语义。

③ 原始保真

标准化出错的兜底：原文永远在，随时重放。

④ SASL 认证

内网消息层换 SASL SCRAM-SHA-512，与边缘 mTLS 分工。

⑤ 40+ 预创建

topic 不自动建；部署前建全，否则数据无处落。

⑥ 信令与日志分流

las-* 独立成层，控制面与数据面互不抢占。