怎么用这份术语表
这份术语表不是词典，而是设计评审的共同语言。当架构师说「这个场景应该用 Saga」时，评审者需要确认双方对 Saga 的理解一致——是编排式 Saga 还是协同式 Saga？补偿失败怎么办？有没有人工出口？
术语表按五个维度排列：事件驱动基础、Kafka 生态、一致性模型、流处理、治理与监控。每个术语包含英文原文、中文译名、一句话定义，以及易混词辨析。如果某个术语没有辨析，说明它在当前语境下没有常见的混淆对象。
使用方式：直接跳到对应维度，或者按字母顺序检索。辨析部分尤其重要——很多设计分歧的根源是术语理解不一致。
一、事件驱动基础（12 条）
| 英文 | 中文 | 定义 | 易混词辨析 |
|---|---|---|---|
| Event | 事件 | 已发生事实的不可变记录，用过去时描述 | 不是命令（Command），命令是祈使意图 |
| Command | 命令 | 要求系统执行某个动作的意图表达 | 不是事件，命令可能被拒绝，事件不可撤销 |
| Query | 查询 | 读取系统当前状态的操作，无副作用 | 不是事件也不是命令，查询不改变状态 |
| Event-Driven Architecture | 事件驱动架构 | 以事件为核心通信机制的分布式架构风格 | 不是「用消息队列替代 RPC」的同义词 |
| CQRS | 命令查询职责分离 | 读写模型分离，写模型优化一致性，读模型优化查询 | 不是必须两套数据库，读模型可以是投影 |
| Saga | Saga 模式 | 长事务拆分为本地事务序列，失败时反向补偿 | 不是 2PC，Saga 是最终一致而非强一致 |
| Outbox Pattern | 发件箱模式 | 业务数据与事件原子写入本地表，异步转发到消息队列 | 不是事件溯源，Outbox 只保证发送不丢 |
| Event Sourcing | 事件溯源 | 以事件序列作为系统状态的唯一真相来源 | 不是 CQRS，事件溯源可独立存在 |
| Projection | 投影/读模型 | 从事件流重建的面向查询的数据视图 | 不是物化视图，投影是消费者维护的 |
| Read Model | 读模型 | 为查询优化的数据表示，通常由投影生成 | 不是缓存，读模型是持久化的数据副本 |
| Aggregate | 聚合根 | 领域模型中的一致性边界，同一聚合内强一致 | 不是数据库表，聚合是业务概念 |
| Domain Event | 领域事件 | 领域模型中状态变化触发的事件，有业务语义 | 不是集成事件，领域事件不跨边界 |
二、Kafka 生态（12 条）
| 英文 | 中文 | 定义 | 易混词辨析 |
|---|---|---|---|
| Topic | 主题 | 消息的逻辑分类通道，生产者发送消费者订阅 | 不是队列，Topic 可有多消费者 |
| Partition | 分区 | Topic 的物理分片，提供并行度和顺序保证 | 不是副本，分区是水平拆分 |
| Offset | 位移 | 消费者在分区中的读取位置标记 | 不是消息 ID，Offset 是单调递增的序号 |
| Consumer Group | 消费者组 | 共享消费同一 Topic 的消费者集合，分区自动分配 | 不是单个消费者，Group 内的消费者协同工作 |
| Rebalance | 重平衡 | 消费者组成员变化时重新分配分区的协议过程 | 不是重启，Rebalance 是 Kafka 的自动协议 |
| ISR | 同步副本集 | 与 Leader 保持同步的副本集合 | 不是全部副本，ISR 是同步子集 |
| Broker | 代理/节点 | Kafka 服务器实例，负责存储和转发消息 | 不是 ZooKeeper，Broker 是数据节点 |
| Producer | 生产者 | 向 Topic 发送消息的客户端 | 不是发布者，Producer 包含重试和批量逻辑 |
| Consumer | 消费者 | 从 Topic 读取消息并处理的客户端 | 不是订阅者，Consumer 维护位移和心跳 |
| Leader | 主副本 | 分区的读写入口，处理所有生产和消费请求 | 不是主节点，每个分区有独立的 Leader |
| Follower | 从副本 | 从 Leader 同步数据的备份副本 | 不是消费者，Follower 不参与业务消费 |
| Partition Key | 分区键 | 决定消息进入哪个分区的字段值 | 不是主键，Partition Key 只影响分区分配 |
三、一致性模型（12 条）
| 英文 | 中文 | 定义 | 易混词辨析 |
|---|---|---|---|
| ACID | 原子一致性隔离持久 | 数据库事务的四个保证特性 | 不适用于分布式系统，分布式用 BASE |
| BASE | 基本可用软状态最终一致 | 分布式系统的松弛一致性模型 | 不是 ACID 的替代，BASE 是分布式下的取舍 |
| Exactly-Once | 恰好一次 | 消息被处理且仅被处理一次的语义保证 | 不是天然支持，需要幂等 + 事务协同 |
| At-Least-Once | 至少一次 | 消息不丢失但可能重复处理的语义 | 不是缺陷，是 Kafka 的默认保证 |
| At-Most-Once | 至多一次 | 消息不重复但可能丢失的语义 | 不是推荐选项，丢失风险太高 |
| Idempotency | 幂等性 | 同一操作多次执行结果与一次执行相同 | 不是去重，幂等是去重的前提条件 |
| Compensating Transaction | 补偿事务 | Saga 失败时对已执行步骤的反向操作 | 不是回滚，补偿是业务语义的操作 |
| Eventual Consistency | 最终一致性 | 系统在无新更新的条件下最终达到一致 | 不是弱一致，最终一致有明确的窗口承诺 |
| Strong Consistency | 强一致性 | 任何时刻所有节点看到的数据一致 | 不是分布式默认，强一致需要共识协议 |
| Distributed Transaction | 分布式事务 | 跨多个节点或服务的事务操作 | 不是单机事务，分布式事务有额外协调成本 |
| Two-Phase Commit | 两阶段提交 | 分布式事务的协调协议，分准备和提交两阶段 | 不是 Saga，2PC 是强一致，Saga 是最终一致 |
| TCC | Try-Confirm-Cancel | 业务层面的三阶段分布式事务模式 | 不是 2PC，TCC 是业务实现，2PC 是协议层 |
四、流处理（12 条）
| 英文 | 中文 | 定义 | 易混词辨析 |
|---|---|---|---|
| Stream Processing | 流处理 | 对实时到达的数据流进行连续计算处理 | 不是批处理，流处理是逐条或微批处理 |
| KStream | 流抽象 | Kafka Streams 中无界事件序列的抽象表示 | 不是 KTable，KStream 不维护当前状态 |
| KTable | 表抽象 | Kafka Streams 中基于更新流维护的键值状态视图 | 不是 KStream，KTable 维护当前值 |
| Window | 窗口 | 流处理中对时间分段聚合的机制 | 不是数据库窗函数，流窗口有时间语义 |
| Tumbling Window | 翻滚窗口 | 固定大小、不重叠、连续排列的时间窗口 | 不是滑动窗口，翻滚窗口之间无重叠 |
| Sliding Window | 滑动窗口 | 固定大小但可重叠的时间窗口 | 不是翻滚窗口，滑动窗口有重叠区域 |
| Session Window | 会话窗口 | 按活动间隙划分的动态大小窗口 | 不是固定窗口，会话窗口大小依赖数据到达模式 |
| Join | 连接 | 合并两个数据流的操作，按键或时间对齐 | 不是 SQL Join，流 Join 有时间窗口约束 |
| State Store | 状态存储 | 流处理器维护的本地键值状态 | 不是 Redis，State Store 是 Streams 的内建机制 |
| Changelog | 变更日志 | 状态存储的变更记录 Topic，用于恢复 | 不是主 Topic，Changelog 只记录状态变化 |
| Topology | 拓扑 | 流处理图的结构描述，包含源、处理器、汇 | 不是 DAG 的同义词，Topology 有 Streams 特定语义 |
| Processor | 处理器 | 流拓扑中的计算节点，接收输入并产生输出 | 不是消费者，Processor 是 Streams 内部的计算单元 |
五、治理与监控（12 条）
| 英文 | 中文 | 定义 | 易混词辨析 |
|---|---|---|---|
| Schema Registry | Schema 注册中心 | 存储和校验事件 Schema 版本的服务 | 不是消息队列，Registry 只管理 Schema |
| Event Catalog | 事件目录 | 记录所有事件定义、消费者和版本信息的文档 | 不是 Registry，Catalog 是文档，Registry 是服务 |
| Consumer Contract | 消费者契约 | 消费者声明其依赖字段和兼容性要求的协议 | 不是 API 契约，Consumer Contract 关注事件字段级别 |
| Dead Letter Queue | 死信队列 | 存放消费失败消息的专用 Topic，用于后续排查 | 不是垃圾桶，DLQ 的消息需要人工或自动重处理 |
| Lag | 消费延迟 | 生产者最新 Offset 与消费者当前 Offset 的差值 | 不是处理延迟，Lag 是积压量，处理延迟是耗时 |
| Backpressure | 背压 | 消费者向生产者反馈处理能力不足的信号机制 | 不是限流，背压是双向反馈，限流是单向控制 |
| Observability | 可观测性 | 通过日志、指标、追踪了解系统内部状态的能力 | 不是监控，可观测性涵盖 more than 报警 |
| Trace | 链路追踪 | 跨服务的请求调用链记录，用于定位延迟根因 | 不是日志，Trace 关注调用关系，日志关注事件 |
| Lineage | 数据血缘 | 数据从产生到消费的完整流转路径和影响关系 | 不是追踪，Lineage 关注数据流向，Trace 关注请求流 |
| Quota | 配额 | 对资源使用量（带宽、存储）的上限限制 | 不是限流，Quota 是总量控制，限流是速率控制 |
| Retention | 保留期 | Topic 中消息保存的时间长度 | 不是 TTL，Retention 是全局配置，TTL 可针对单条 |
| Compaction | 压缩清理 | 仅保留每条键的最新值、删除旧值的消息清理策略 | 不是删除，Compaction 保留最新，删除是全部清除 |
术语表的速查用法
评审会上如果术语理解出现分歧，不要争论定义，直接翻出术语表读原文。这份表的设计原则是：一句话定义足够在评审会上使用，不需要背完整概念。
常见分歧场景：
| 分歧场景 | 术语表解法 |
|---|---|
| 「Event 和 Command 到底什么区别？」 | 翻到第 1 条和第 2 条，对比定义 |
| 「CQRS 是不是必须读写分离到两个库？」 | 翻到第 5 条，辨析明确指出「不是必须」 |
| 「Saga 和 2PC 哪个更好？」 | 翻到第 6 条和第 22 条，对比一致性强弱 |
| 「我们的消息保证 Exactly-Once 了吗？」 | 翻到第 14 条，确认需要幂等 + 事务协同 |
| 「Lag 大了是不是消费者有问题？」 | 翻到第 52 条，辨析指出 Lag 是积压量不是处理延迟 |
六十条术语的分布
| 维度 | 数量 | 核心关注点 |
|---|---|---|
| 事件驱动基础 | 12 | 事件、命令、CQRS、Saga、聚合的语义边界 |
| Kafka 生态 | 12 | 分区、位移、副本、重平衡的技术概念 |
| 一致性模型 | 12 | 事务语义、幂等、补偿、最终一致的适用场景 |
| 流处理 | 12 | 窗口、连接、状态存储的时间与状态语义 |
| 治理与监控 | 12 | Schema、血缘、配额、可观测性的工具边界 |
没有覆盖的术语（如 ZooKeeper、Broker 的 JMX 指标、Streams 的 punctuate）不是没有价值，而是它们属于工具层，不在架构讨论的核心范围。如果需要，可以在对应章节的代码注释中找到它们。
本节小结
- 术语表是评审共同语言，不是词典，辨析部分比对定义更重要。
- 六十条术语分五个维度排列，覆盖事件基础、Kafka 生态、一致性、流处理、治理监控。
- 常见分歧可以直接翻到对应条目，避免「你说的 Event 和我说的 Event 不是同一个东西」。
- 未覆盖的术语（如 ZooKeeper）属于工具层，在代码注释中补充即可。
阅读导航：上一节 15.3 全书验收 ｜ 下一节 附录 B ADR 模板
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。