--- title: "Kafka Simulator v2.0 - 完整的课程体系与重建的演练场" date: 2026-10-21T00:00:00.000Z author: "michal" excerpt: "v2.0 补齐了全部 136 个场景：Schema Registry 与授权，并为自由模式带来治理层级；共享组（KIP-932）、无盘主题（KIP-1163/1164 草案）以及综合实战场景。围绕它们的演练场也经过了重建 - 三种查看集群的方式、一条读得懂的时间线、能回答问题的检查器，以及不再挡住画布的终端。" --- v2.0 是课程体系的最后一个包。它新增四个模块 - **schema-registry**、**authorization**、**share-groups** 和 **capstones** - 外加存储模块中的三个**无盘主题（diskless topics）**场景、dr 模块中的一个双活（active-active）DR 演练，以及 producer 模块中的机架感知分区，合计 **24 个新场景**。它在自由模式中解锁了 **governance** 和 **diskless** 两个层级，并让 [Kafka Simulator](/kafka-simulator/) 的课程体系达到 **136 个中的 136 个**。 这也是围绕这些场景的演练场被重建的一个版本。自 v1.9 以来，它几乎每个部分都变了：画布有了三种视图，时间线变成了可以阅读的东西，检查器回答问题而不再罗列字段，终端也不再挡住画布。 ## v2.0 里有什么 **Schema Registry（`schema-registry`，3 个场景）。** [subject 与版本](/kafka-simulator/scenarios/subjects-and-versions/)、[backward、forward 和 full 兼容性各自检查什么](/kafka-simulator/scenarios/compatibility-modes/)，以及[一个在注册之前就被拒绝的破坏性变更](/kafka-simulator/scenarios/breaking-change-rejected/)。 **授权（`authorization`，2 个场景）。** 数据路径上的访问控制：在授权器默认拒绝的情况下，[一条 ACL](/kafka-simulator/scenarios/acls-authorizing-a-producer/) 或[一个 RBAC 角色绑定](/kafka-simulator/scenarios/rbac-role-bindings/)如何允许或拒绝一次生产请求。 两者都随新的**治理层级（governance tier）**进入自由模式：Schema Registry、ACL 和 RBAC 控件，以及终端里的 `kafka-acls`，因此场景里展示的一切，你都可以亲手重建、亲手搞坏。 **共享组（`share-groups`，9 个场景）。** [Kafka 的队列语义](/kafka-simulator/scenarios/share-group-queue/)，由 KIP-932 引入： - 共享组如何让[多个消费者处理同一个分区](/kafka-simulator/scenarios/cooperative-beyond-partitions/)，逐条确认记录，而不是按已提交的 offset 推进。 - [获取、确认与释放](/kafka-simulator/scenarios/acknowledge-accept-release-reject/) - 队列式消费背后每条记录的生命周期。 - 投递次数上限与[毒丸消息的处理路径](/kafka-simulator/scenarios/share-group-poison-pill/) - 一条反复失败的记录如何被归档，而不是被无休止地重新投递。 共享组改变了 Kafka 的消费方式，把它们和经典的消费者组放在一起看，就能看出不同之处。 **综合实战（`capstones`，5 个场景）。** 端到端的场景，把持久性、事务、存储、多数据中心和治理结合在一起，而且同一时间发生的事情不止一件：[一条能扛过区域丢失的精确一次支付管道](/kafka-simulator/scenarios/exactly-once-payments-pipeline/)、[一次零数据丢失的区域故障切换](/kafka-simulator/scenarios/survive-regional-outage-zero-loss/)、[一次借助 Cluster Linking 完成的零停机迁移](/kafka-simulator/scenarios/migrate-with-cluster-linking/)、[一个多数据中心双活的事件骨干网](/kafka-simulator/scenarios/active-active-event-backbone/)，以及[一条同时针对吞吐量和延迟调优的管道](/kafka-simulator/scenarios/tune-high-throughput-low-latency/)。 **灾难恢复（`dr`，新增 1 个场景）。** [一次双活 DR 演练](/kafka-simulator/scenarios/active-active-dr-drill/)：失去 west 区域，把它的生产者和消费者组迁到 east 继续写入，再重启 west 并把它们迁回。全程不做任何提升，代价是 west 从未镜像出去的那些记录。 **生产者（`producer`，新增 1 个场景）。** [机架感知分区](/kafka-simulator/scenarios/rack-aware-partitioning/)：这是 Kafka 4.4 的新功能，生产者把没有键的记录留在自己所在的可用区内，直到该可用区失去它的 leader。详见下文的「Apache Kafka 4.4」。 ## 无盘主题（KIP-1150 方向，KIP-1163/1164 草案） 无盘主题把分区数据保存在对象存储中，而不是 broker 的磁盘上。broker 把来自多个分区的记录缓冲起来，作为一个 WAL 对象上传；无盘协调器在提交该对象时分配 offset，生产请求在提交时得到确认。副本通过从存储中读回该对象来构建自己的日志，而不是从 leader 拉取，生产者和消费者则使用与自己处于同一可用区的副本。 现状如下：[KIP-1150](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1150%3A+Diskless+Topics) 已被接受为方向，而定义其具体工作方式的 [KIP-1163](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1163%3A+Diskless+Core) 和 [KIP-1164](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1164%3A+Diskless+Coordinator) 仍处于 Under Discussion 状态（实现进度由 [KAFKA-19161](https://issues.apache.org/jira/browse/KAFKA-19161) 跟踪）。我们模拟的是当前草案，并在模拟器中处处标注为「KIP draft」。在其中任何部分真正进入 Kafka 之前，名称和行为都可能发生变化。 **三个场景（`storage`，05.4.1-05.4.3）：** - **[无盘：写入路径](/kafka-simulator/scenarios/diskless-write-path/)** - 两个生产者和两个分区共享一个 WAL 对象，在协调器提交之前不存在任何 offset，副本则从对象存储中读回数据。 - **[不跨可用区复制](/kafka-simulator/scenarios/no-cross-az-replication/)** - 同样的 3 条记录分别写入跨三个可用区的经典主题和无盘主题；Cross-AZ traffic 卡片最终显示经典主题 7 跳、无盘主题 0 跳。 - **[代价是延迟](/kafka-simulator/scenarios/diskless-produce-latency/)** - 同一次 `acks=all` 生产，在经典主题上 300 ms 得到确认，在无盘主题上则需要 1300 ms，而一批填满缓冲区的突发写入在 800 ms 内得到确认。这些时间被等比放大，以便每一步都清晰可见。 **在自由模式中：** 一个 **Diskless 3 AZ** 预设、按主题切换的无盘开关，以及调节无盘时序的滑块。画布新增一条拥有独立时间轴的对象存储泳道、每个 broker 下方的 WAL 托盘和一个协调器徽标，指标面板则新增一张 **Cross-AZ traffic** 卡片。在终端中，`kafka-topics --create --config diskless.enable=true` 会创建一个无盘主题，而 `kafka-diskless-metadata`（它本身也是草案中的工具，尚未进入 Apache Kafka）会显示每个分区的 offset，并列出存储中的 WAL 对象。 一句话概括其中的取舍：跨可用区的复制流量更少，生产更慢 - 草案的目标是生产延迟 P50 约 500 ms、P99 为 1-2 s。经典 Kafka 已经可以从同一可用区的 follower 读取（KIP-392），因此无盘真正带来的，是没有 broker 之间的复制，以及生产请求不必到达 leader。 ## Apache Kafka 4.4 模型现在遵循本周发布的 Apache Kafka 4.4。我们对比了 4.3.0 和 4.4.0，没有发现模拟器所依赖的默认值、CLI 输出或错误信息有任何变化，因此场景中的一切都与以前相同。 v2.0 对 4.4 的一项新功能进行了建模：生产者的机架感知分区（[KIP-1123](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1123%3A+Rack-aware+partitioning+for+Kafka+Producer)）。设置 `partitioner.rack.aware=true` 和 `client.rack` 之后，默认分区器会把没有键的记录发送到 leader 位于生产者所在可用区的分区；如果该可用区没有 leader，则发送到任意分区，从而让生产流量留在可用区内。新场景[机架感知分区](/kafka-simulator/scenarios/rack-aware-partitioning/)展示了这两种情况。在自由模式中，生产者检查器提供了这个开关，沙盒初始的生产者可以选择自己的 `client.rack`。没有 `client.rack` 时，生产者会像 Kafka 一样拒绝这个设置。 另一项 4.4 新功能，共享组的死信队列（KIP-1191），目前还没有建模。 ## 重建的演练场 ### 三种查看集群的方式 画布现在有三种视图，可以从它的工具栏切换： - **Brokers** 是熟悉的画面：生产者在左边，集群在中间，消费者组和共享组在右边。 - **Lanes** 为每个分区画一行，共用一条 offset 轴：副本上下排列，leader 在最前，高水位线是一条贯穿所有副本的线。滞后的 follower 的日志明显更短，已停止的 broker 的日志停在原地，每个消费者都标在自己的读取位置上，并附带已提交的 offset 和滞后。每个参与者在日志中处于什么位置，一眼就能看出来。 - **Matrix** 适用于大到画不下的集群：一张表，纵向是主题，横向是 broker，配有四个视角 - **Failures**、**Balance**、**Lag** 和 **Traffic** - 它们为表格着色并把最差的排在前面。把鼠标悬停在某个 broker 上，就能在停掉它之前，按主题逐一看到集群会失去什么。规模较大的自由模式集群会自动以 Matrix 视图打开。 ### 画布展示发生了什么变化 状态变化现在会在发生变化的那个元素上播放，而不是一个通用的脉冲效果：高水位线标记滑到新的 offset，leader 的皇冠从旧 leader 移到新 leader，follower 的 ISR 标签则以变化的颜色显示。生产出来的记录会落在它自己的日志格子上，繁忙的画布把记录画成短轨迹，已停止的 broker 会以淡化的样子留在画布上，让你看得到那里原来有什么。在多区域画布上，镜像链路会显示它的 RPO，每个 DC 色带会说明失去它的代价，网络分区会显示哪一侧继续提供服务，KRaft 条会计算它的多数，共享组的泳道则显示每条记录的锁定计时器和投递次数。 ### 一条读得懂的时间线 在桌面端，底部停靠栏现在是一条单行的**轨道（rail）**：各帧位于它们真实的模拟时间上，因此一阵突发读起来就是一簇，一段平静期就是一个空隙，你可以沿着它拖动来回放。展开它的**事件泳道**，这次运行中的每个事件都会按生产、复制、broker 和消费几条泳道排开，故障标为红色，每一帧的主要事件也会被标出。 ### 能回答问题的检查器 右侧面板现在从你会问的问题出发。分区呈现为一把 offset 刻度尺，broker 呈现为它停掉时你会失去什么，主题呈现为每个分区一条泳道，生产者呈现为它的发送路径，消费者组则呈现为泳道或分区网格。**Why** 列出出了什么问题以及原因，**Metrics** 按角色分组，有些检查器还会展示接下来会发生什么，而不只是当前状态。多区域视图新增一张 DR 卡片，显示每个区域的日志，并把尚未镜像的尾部作为 RPO 显示出来。 ### 画布为终端让出空间 Kafka CLI 终端仍然停靠在画布下方，但现在画布会为它让出空间，而不是被它挡住 - 于是 `kafka-server-stop` 和 broker-1 宕机会同时出现在屏幕上，终端也能用画布的全部宽度来显示你输入的命令和工具的输出。在宽屏上，点击标题栏中的 **dock side** 可以把它移到画布旁边的一列。输出保持按列对齐，主机菜单则是一张列出所有 broker 和 controller 的 `ssh` 表格。broker 的配置文件与 Kafka 4.4 一致，`kafka-reassign-partitions --generate` 以及在移除 broker 之前先将其排空，都与真实集群上的做法一致。 ### 入门，不再需要导览 13 步的模态导览已经取消。取而代之的是画布角落里的一张 **Getting started** 卡片：同样的主题，变成一份可以按任意顺序完成的清单，每一项都带有「Show me」。帮助现在是一份供你查阅的参考资料；脚本化场景可以分叉成一个带撤销功能的沙盒；场景会给出自己的「Try it yourself」操作建议和下一步该做什么；分享出去的链接现在会重放它是如何到达所展示状态的。 ### 全新的外观，以及一轮无障碍改进 整个网站，包括演练场，都换上了以我们名字里的寒鸦为灵感的新外观：深墨色、蓝色光泽和灰色，每一组文字颜色对比都达到 WCAG AA。随之而来的还有跳转链接和命名区域、只占一个 Tab 停靠点的场景导航栏、非活动区域的 AA 对比度、按压反馈和更大的触控目标，以及遵循 `prefers-reduced-motion` 的动效：保留淡入淡出，去掉位移动画。手机布局也单独做了一轮优化，细致到有一项测试专门检查每个标签是否仍然放得下。 ## 演练场之外 演练场本身不可被索引，因此搜索引擎从未看到过其中的场景文字。现在 [/kafka-simulator/scenarios/](/kafka-simulator/scenarios/) 下**每个场景都有了自己的页面**：包括它的引言和结论、每一个带有「Open at this step」链接的步骤、一个可以逐步浏览的真实画布帧，以及它涉及的 Kafka 配置。随着 v2.0 发布，这样的页面一共有 136 个。 与之并列的是针对 Kafka 错误和症状的**[故障排查页面](/kafka-simulator/troubleshooting/)**：问题意味着什么、可能的原因、修复方法和不该做的事，以及客户端是否会重试 - 每个页面都链接到出现该问题的场景，并直接打开在问题发生的那一刻。授权相关的页面也随本次发布加入其中。[更新日志](/kafka-simulator/changelog/)现在以时间线上的发布说明形式呈现。 ## 还有一件事 我们在这个版本里藏了点东西。能不能找到，就看你的了。 ## 路线图的终点 v2.0 完成了从 v1.0 开始的一切：十一个双周发布包，136 个场景，从单个 broker 的内部构造，一直到队列和全平台的综合实战。一切都在浏览器中确定性地运行，遵循 Apache Kafka 4.4 的语义，没有后端，也不收集任何关于你的场景的遥测数据。 课程体系已经完整，但模拟器是一个沙盒，而不是一门学完就结束的课程。打开[模拟器](/kafka-simulator/)，搭点什么，然后把它搞坏。