消息、事件与异步

• Emissary 模式的定位（进程外代理）
• API 代理与协议转换
• 遗留系统适配

Emissary 模式（也称 Ambassador 或 Sidecar 的前身）是一种进程外代理（out-of-process proxy）模式：在应用进程之外放置一个代理进程，代表应用消费外部服务或对应用提供代理。它把横切关注点（连接管理、重试、超时、限流、认证、协议转换、度量）从应用逻辑中剥离，放在代理侧。在 API 代理场景，Emissary 作为应用与外部 API 之间的中间层，拦截出站请求并统一加入安全头、重试、熔断、日志与追踪；在协议转换场景，Emissary 把应用使用的协议（如内部 protobuf/gRPC）转换为外部系统要求的协议（如 REST/JSON），或反之，实现异构技术栈之间的适配；在遗留系统适配场景，Emissary 充当"翻译官"，把新系统的请求转换为遗留系统（如旧 SOAP、旧协议、COBOL 服务）能够理解的格式，并屏蔽其稳定性问题（重试、超时、降级）。由于是独立进程，可实现语言无关、可独立升级、可集中治理。

Emissary 的核心价值是"把与业务无关的通信与适配职责下沉到进程外代理"，实现关注点分离与语言无关。它与 Sidecar 相似但更强调"出站/外部访问"与"协议适配"，是连接遗留系统与多云外部 API 的常用手段。

• ACK 机制与 at-least-once
• 死信队列（DLQ）
• 重试退避策略

可靠投递的核心是"at-least-once + 幂等消费"。ACK 机制：消费者处理完消息后向 broker 发送 ACK，broker 才删除消息；若消费者未 ACK 或处理失败（nack），broker 会重新投递（可能导致重复消费，需幂等）。死信队列（DLQ）：当消息重试达到最大次数仍失败（如业务数据异常、格式错误），将其移入死信队列，由专门消费者/人工处理，避免无限重试阻塞主队列。重试退避：对失败消息采用指数退避（如 1s、2s、4s…）+ 随机抖动（jitter），避免重试风暴，并设置最大重试次数。消息回溯：broker 支持按 offset 或时间戳重置消费位点（Kafka 的 reset offsets、RabbitMQ 的重新入队），用于故障恢复、重放消费、修复因代码 bug 产生错误数据，或审计回放。设计与顺序：先 ACK 保证至少一次，DLQ 兜底异常消息，退避防风暴，回溯支持重放与恢复。

可靠投递没有"恰好一次"，工程上用 at-least-once + 幂等 + DLQ + 重试退避 + 回溯组合。ACK 决定消息是否被 broker 认为已处理，DLQ 隔离永久失败，退避降低重试压力，回溯提供运维恢复能力。

• 分区顺序写
• 页缓存与零拷贝
• 日志分段删除

Kafka 的存储模型基于"追加日志"（append-only log）：每个 topic 的每个分区（partition）是一个有序的日志文件，消息按 offset 严格追加写入。分区顺序写使磁盘写入为顺序 I/O（而非随机 I/O），配合批量发送与异步刷盘，大幅提升写吞吐（顺序写速度远高于随机写）。读路径上，Kafka 利用操作系统页缓存（page cache）：消息写入后先缓存在页缓存，消费者读时直接命中页缓存，避免磁盘与用户态缓冲拷贝；结合零拷贝（zero-copy，sendfile 系统调用）把数据从页缓存直接发送到 socket，不经用户态，降低数据拷贝与 CPU 开销，是实现高吞吐读的关键。日志按段（segment）删除：Kafka 把每个分区的日志分成多个 segment 文件，每个 segment 有起始 offset 与最大时间戳；日志保留策略（按时间/大小）基于 segment 删除整个旧 segment，而不是逐条删除，因为删除整个文件是 O(1) 操作且不产生碎片，配合偏移索引（offset index）可快速定位。删除键是"segment 粒度"而非"消息粒度"，这是高吞吐与简单清理的关键。

Kafka 高吞吐的三支柱：顺序写（append-only）、页缓存 + 零拷贝（读路径）、segment 粒度删除（清理）。每条消息的删除成本高，故按 segment 整个删除，并用保留策略（retention.ms/bytes）控制。

• 竞争消费者模型
• 并行消费与消息确认
• 失败重试

Competing Consumers 模式让多个消费者实例同时消费同一个消息队列，broker 把每条消息只投递给其中一个消费者（竞争消费），从而实现并行处理与水平扩容（消费者越多，吞吐越高，但共享同一队列）。工程实现要点：消息确认（ack）——消费者处理完成才 ack，broker 才删除消息；若消费者崩溃未 ack，broker 重新投递（at-least-once，需幂等）。并行性——消费者数量可独立于队列扩展，但要注意分区/顺序场景下需配合分区（如 Kafka 每个分区同一时刻仅一个消费者），否则无法保证顺序。失败重试——消费者处理失败可 nack 让 broker 重投，或使用拒绝 + 重试队列（retry queue）+ 死信队列（DLQ），重试采用指数退避 + 抖动，达到最大重试次数进入 DLQ。并发控制——消费者可并发处理多条消息（线程池），但需处理顺序与幂等。

Competing Consumers 是最常见的消息消费模型，通过"多条消息竞争多个消费者"实现水平扩展。它牺牲了顺序（除非社区分区），换取吞吐；确认与重试 + DLQ 保证可靠性与幂等。

• 事件驱动与请求驱动差异
• 松耦合的收益
• 调试追踪复杂度

请求驱动（request-driven）是同步调用模型：客户端发请求，服务端响应，调用方直接依赖被调用方的接口与响应，耦合紧密、时序清晰、易追踪，但服务间耦合重、易级联、吞吐受限。事件驱动（event-driven）是异步发布/订阅模型：服务发布事件，其他服务订阅并处理，发布方不关心谁消费、何时消费，实现松散耦合（时间、空间、逻辑解耦），利于扩展、容错与异步削峰。何时带来松耦合：当业务链路由多个服务通过事件连接、发布方与消费方生命周期独立、需要异步解耦与扩展时，事件驱动显著降低耦合。何时引入复杂度：当事件流需要全局追踪（跨多个服务的事件链难以用单一 traceId 关联）、调试困难（事件顺序、重复、丢失、延迟导致状态不确定）、需要处理最终一致与补偿、事件 schema 演进与重放时，事件驱动会引入显著的调试与追踪复杂度。因此，简单强同步流程用请求驱动，解耦/异步/削峰需求用事件驱动，但需配套可观测性（traceId 传播、事件元数据、幂等与审计）。

事件驱动是把"调用"变"通知"，解耦与容错换取"流程不可见"与"最终一致"。松耦合适合异步、可扩展、多依赖场景；复杂度主在追踪、调试、一致性。选择取决于耦合需求与可观测性投入。

• lag 定义与计算
• 分区数固定对扩容的限制
• 突破积压的方法

消费延迟（lag）指消费者尚未消费的消息数量，即"生产者写入的最新 offset - 消费者已提交/已消费的 offset"，在 Kafka 中可通过 kafka-consumer-groups --describe 查看每个分区的 LAG（latest offset - current offset）。lag 持续增长说明消费速度跟不上生产速度，需要治理。消费者扩容时，Kafka 的并行度受分区数限制：一个分区同一时刻只能被一个消费者组内的一个消费者消费，因此消费者数量最多等于分区数，超过分区数的消费者是空闲的。若要突破分区数限制提升消费并行度，方法包括：增加分区数（topic 分区可扩容，但会改变消息顺序与 key 分区策略，需谨慎）；在应用内采用多线程消费（一个消费者拉取，内部线程池并发处理每条消息，提升处理吞吐）；解耦"拉取"与"处理"（consumer 拉取后提交 offset 进内存队列，由处理线程池处理，处理失败再重试）；若积压由单个慢消费者造成，可拆分 topic 或按更大粒度分区。此外可配合限流告警、临时加消费者、优化消费逻辑（批处理、数据库批写）缓解。

lag 是积压的度量，分区数是 Kafka 消费并行度的硬上限。突破积压需从"增加分区/消费者"或"应用内多线程并发处理"两个方向：前者受分区数约束，后者受单消费者处理能力约束。需谨慎扩容分区以免破坏顺序。

• Avro/Protobuf 兼容规则
• Schema Registry
• 版本升级避免下游破坏

事件 Schema 治理的核心是"演进兼容"：保证事件结构升级时，旧消费者（读新 schema）与新消费者（读旧 schema）都能正常解析。Avro 与 Protobuf 都支持字段级的向后/向前兼容：Avro 通过字段 name + 默认值，新增字段必须带默认值才能向后兼容（消费者读旧数据时用默认值），删除字段需保留 name；Protobuf 靠字段编号（field number），新增字段用新编号（旧消费者忽略未知字段=向前兼容），删除字段用 reserved 保留编号，字段类型不可变更。常配合 Schema Registry（如 Confluent Schema Registry、Apicurio）集中管理 schema 版本，生产者/消费者按 schema id 解析，并启用兼容性校验（backward/forward/full），在发布前阻止不兼容变更。版本升级避免下游破坏的要点：只增不改不删（新增字段带默认值、唯一编号）、用 reserved 保护编号、通过 Schema Registry 校验兼容性、灰度发布新 schema、消费端用默认值兜底、避免破坏性字段类型变更。

事件 schema 的兼容性靠"字段编号/名字 + 默认值 + reserved"的契约，配合 Schema Registry 的版本管理与兼容性校验，在发布期拦截破坏性变更，从而让事件在长期演进中不破坏下游消费者。

• 事件溯源 vs 消息队列
• 事件存储作为事实源
• 重放重建

事件溯源（Event Sourcing）把应用状态作为"事件流的投影"，事件存储是事实源（source of truth）：只有事件是源头，状态是派生的。而消息队列（如 Kafka）是传输/分发机制，用于事件在服务间传播与解耦。关系：事件溯源常把事件存储用支持追加日志的存储实现（Kafka 即可作为事件日志），事件追加到事件存储后，通过消息队列/订阅分发给投影（读模型）与下游服务。区别：事件存储保证"权威、有序、持久、可重放"，是事实源；消息队列侧重"投递与消费"，被消费后可能移除（虽 Kafka 可保留）。重放重建：事件溯源可从事件日志重放（replay）重建任意状态——读取事件流，按序应用事件到聚合/投影，得到当前状态；也可在代码 bug 或需要时重建读模型。因此事件存储必须不可变、可重放、可追加，并支持快照加速。

事件溯源的核心是"事件即事实源"，消息队列是传播通道。二者常结合（事件存储可基于 Kafka），但职责不同：事件存储保证权威与重放，消息队列保证分发。重放是事件溯源重建状态、审计与修复的关键能力。

• 重复消费来源
• 业务去重表
• 状态机兜底

在 at-least-once 投递下，消息可能被重复消费（重试、分区 rebalance、broker 重投、消费者崩溃后重拉），因此消费端必须幂等。业务去重表（dedup table）：消费者在处理前，把消息/业务唯一键（如订单号、消息 ID）写入本地数据库去重表（唯一索引），若已存在则说明已处理，直接跳过；去重表与业务处理在同一事务提交，保证"处理与去重原子"（类似于 Inbox 模式）。状态机兜底：业务对象的状态机（如订单状态：待支付→已支付→已发货）天然具有幂等性，重复处理同一状态转换时，若目标状态已达成则忽略（如重复"已支付"事件，若订单已是已支付则直接返回成功），避免重复扣款、重复发货。去重表处理"是否已处理"，状态机处理"业务状态是否已达成"，两者结合：去重表从"操作层面"去重，状态机从"业务状态层面"兜底，保证重复消息不产生重复副作用。

幂等消费 = 去重表（操作级去重）+ 状态机（业务状态兜底）。去重表防重复执行，状态机让重复执行无副作用。两者适合在数据库事务内提交，保证消息处理与去重/状态推进的原子性。

• pub/sub 广播语义
• work queue 竞争消费语义
• 典型场景

事件总线（pub/sub，发布/订阅）：一个事件被广播给所有订阅者（每个订阅者都收到同一份），订阅者之间互不干扰，事件与订阅者解耦，典型实现如 Kafka topic（多个 consumer group 各自收到全量）、RabbitMQ fanout/topic exchange。点对点队列（work queue，竞争消费）：一个消息只被一个消费者取走，多个消费者竞争处理同一条消息，用于任务分发与负载均衡，典型实现如 RabbitMQ work queue、JMS queue、Kafka 同一 consumer group 内。语义差异：pub/sub 是"一事件多消费者"（广播、扇出），work queue 是"一消息一消费者"（竞争、负载均衡）。典型场景：pub/sub 用于事件驱动集成、领域事件广播、数据同步到多个下游（如订单事件同时通知库存、通知、分析）；work queue 用于任务队列、异步处理、削峰填谷（如邮件发送、图片处理，多个 worker 竞争消费任务）。

核心差异是"投递到几个消费者"：pub/sub 广播给所有订阅者（扇出），work queue 竞争消费（一个消息一个消费者）。选择取决于"一个事件需要多个消费者各自处理"还是"一个任务只需一个消费者处理"。

• 按 offset/时间戳重置位点
• 故障恢复与重放
• 与死信重投的差异

消息回溯（message replay / reset offset）是消费端把消费位点（offset）重置到历史位置，从而重新消费历史消息。Kafka 支持按 offset 重置（--reset-offsets --to-offset）或按时间戳重置（--to-datetime），将消费组指到某个分区位置或时间点，重新消费该位置之后的消息。用途：故障恢复——当消费者代码/数据被污染（如写错库、bug 产生错误数据）时，回退到出错前的位点重新消费，修复数据；重放——把某时间窗的事件重放给新消费组/投影，重建读模型或做审计。与死信重投的差异：死信重投是把死信队列（DLQ）中的失败消息重新投回主队列（或重试队列）再消费，针对"单条失败消息"，目标是重试该条；消息回溯是针对"一段历史消息"整体重新消费，目标是修复/重放，不改变单条消息的失败结论。两者都涉及"重新消费"，但粒度（单条 vs 一段）与目的（重试失败 vs 修复重放）不同。

消息回溯是"回到历史位点重新消费"的运维能力，用于故障恢复与投影重放；死信重投是"把失败消息放回队列重试"。区别在粒度与目的。回溯依赖消息保留（retention），需合理配置保留时长。

• Adapter 模式原理
• 遗留系统适配
• 与 ACL 的关系

Adapter（适配器）模式本质是结构型模式：把某个类的接口转换成客户端期望的另一个接口，使原本不兼容的接口协同工作。在遗留系统到微服务的适配中，Adapter 作为"中间翻译层"，把遗留系统（如老 SOAP、旧 RPC、私有协议、COBOL 系统）的接口转换成新微服务/客户端期望的标准接口（REST/gRPC），屏蔽遗留系统的实现细节与协议差异。例如，把遗留系统的 getCustomerByID 包装成微服务期望的 GET /customers/{id}，或把旧 XML/SOAP 转为 JSON。Adapter 与 Anti-Corruption Layer（ACL）相关但不同：ACL 是更广义的防腐层，包含接口适配、语义翻译、数据转换与防止领域模型污染；Adapter 是其中"接口适配"的具体手段。使用 Adapter 可让新系统不直接依赖遗留实现，便于后续替换遗留系统。

Adapter 把"接口形态"翻译为客户端期望的形态，是遗留系统集成与微服务边界适配的常用手段。它隔离了遗留与新的契约差异，支持渐进式替换（配合 Strangler Fig）。

• Aggregator 模式
• 多服务聚合
• API Composition

Aggregator（聚合器）模式在系统边界提供一个聚合服务，它调用多个后端服务（或资源），把它们的响应合并为一个组合响应返回给客户端。在微服务中，客户端往往需要组合多个服务的数据（如订单详情 = 订单服务 + 用户服务 + 商品服务 + 支付服务），若让客户端逐个调用会导致多次往返（Chatty I/O）与客户端耦合。Aggregator 在服务端做 API Composition（API 组合）：用一个聚合接口并行/串行调用多个服务，合并结果、裁剪字段、统一错误，返回给客户端一个聚合响应。它与 BFF 相关但定位不同：Aggregator 偏"服务端聚合多个服务数据"，BFF 偏"面向特定前端的聚合裁剪"。实现要点：聚合服务可并行调用（CompletableFuture/异步）减少延迟、处理部分失败（有聚合有降级）、注意不要变成耦合的业务逻辑层。

Aggregator 用"服务端聚合"替代"客户端多次调用"，减少往返、隐藏内部服务拓扑。它是 API Composition 的典型实现，适合"一个聚合接口需要多个服务数据"的场景，但需防止聚合服务变重。

• 吞吐与存储模型
• 顺序与延迟
• 多租户

Kafka：设计为高吞吐分布式日志流，基于分区 + 顺序写 + 页缓存 + 零拷贝，吞吐极高；顺序通过分区内有序（同一 key 同分区），跨分区不保证全局有序；延迟相对较高（批量、异步刷盘），通常是秒级内；多租户通过 topic 隔离，但无原生强多租户隔离。RabbitMQ：基于 AMQP 的通用消息队列，支持多种 exchange（direct/topic/fanout/headers）与路由，吞吐中等（低于 Kafka），但延迟低（单条投递）、功能灵活（ack、确认、死信、优先级）；顺序上单个队列内有一定保证，但对高吞吐与多消费者场景较弱；多租户通过 vhost 隔离。Pulsar：较新的分布式消息系统，分离存储与计算（broker 无状态 + 分层存储），吞吐高（类似 Kafka）、支持低延迟与多租户（原生 namespace 级多租户、配额、隔离）、支持分区顺序与持久化分层存储（可无限回溯）。总体：Kafka 适合高吞吐日志流、事件流；RabbitMQ 适合低延迟、路由灵活、任务队列；Pulsar 综合（高吞吐 + 低延迟 + 多租户 + 分层存储）。

三者的选型维度是吞吐、延迟、顺序保证、多租户与路由能力。Kafka 吞吐最高、延迟高；RabbitMQ 延迟低、路由灵活但吞吐一般；Pulsar 兼顾吞吐与多租户/分层存储。按业务需求（日志流 vs 任务队列 vs 多租户平台）选择。

• rebalance 触发时机
• offset 提交与监听器配合
• 重复消费与丢失消费并存

Kafka 消费者组中，当消费者加入/退出/崩溃或分区数变化时触发 rebalance，重新分配分区给消费者。rebalance 期间存在"停止消费、重新分配"的窗口，配合 offset 提交保证消费位置。offset 提交时机：自动提交（默认每 5s 提交已 poll 的 offset）与手动提交（commitSync/commitAsync）。为避免 rebalance 丢失或重复，需用再均衡监听器（ConsumerRebalanceListener）：onPartitionsRevoked（分区被撤销前调用）——在撤销前提交已处理的消息 offset，避免丢失；onPartitionsAssigned（分区被分配后调用）——在新分区上定位起始 offset（如 seek 到上次提交位置）。重复消费与丢失消费并存的原因：如果消费者在处理完一批消息但尚未提交 offset 时发生 rebalance，这些消息会被新消费者重新拉取（重复消费）；如果消费者在撤销前没有提交 offset（自动提交延迟或崩溃），已被消费但未提交的 offset 之后的消息可能会被跳读（丢失消费）。因此手动提交前处理 + 在 onPartitionsRevoked 中提交，能减少重复与丢失；但 at-least-once 下重复无法完全避免，需幂等兜底。

rebalance 的核心矛盾是"消费进度（offset）与分区所有权"的时序。提交 offset 与 rebalance 监听器配合，保证在分区移交时提交进度，避免丢失；而重复则是"已处理未提交"导致的，需幂等兜底。二者并存是 at-least-once 的固有特性。

• 业务唯一键去重
• 幂等消费实现
• 与 Outbox 配合

重复投递下，消费端需用业务唯一键去重实现幂等。业务唯一键是能唯一定位一次业务操作的标识（如订单号、消息 ID、业务流水号、用户操作 ID）。流程：消费者收到消息后，先根据业务唯一键查询去重表/数据库，若已存在则视为已处理，直接 ACK 跳过；若不存在则执行业务处理，并在同一事务内写入去重记录（唯一索引），保证"处理与去重原子"，避免并发重复处理。与 Outbox 配合：Outbox 在发送端保证"业务提交与消息产生原子"，并把消息 ID 与业务唯一键关联；消费端用这个消息的 ID/业务唯一键做去重（Inbox）。这样形成"发送端 Outbox 保证至少一次投递 + 消费端 Inbox 去重保证幂等"的可靠消息链路，实现"effectively-once"（幂等消费 = at-least-once + 去重）。

幂等消费 = 业务唯一键去重（Inbox/去重表）+ 同一事务原子写入。Outbox 保证发送端可靠，Inbox 保证消费端幂等，二者配合使整条消息链路达到"effectively-once"。

• 分区内有序
• 同 key 保序
• 跨分区全局有序的困难

Kafka 中，topic 被分成多个分区，每个分区内消息按 offset 严格有序（追加写入、顺序读取）。同一 key 的消息通过分区器（partition key）哈希到同一分区，因此同一 key 的消息在分区内保持写入顺序，消费时按分区内顺序处理，从而保证"同一业务实体（如同一订单、同一用户）的更新顺序"。跨分区全局有序难的原因：Kafka 只在分区内保证顺序，不同分区之间没有全局顺序；生产端把消息分散到多个分区（并行写），broker 无法跨分区排序；消费端多个消费者并发消费不同分区，也无法保证跨分区顺序。若想全局有序，需全部消息写入单分区（分区数=1），但那样丢失并行度与吞吐，且生产端多线程写入也很难保证全局顺序（需单线程写）。因此工程上通常"以 key 分区保序 + 单分区场景保全局序"，牺牲全局有序换取并行与吞吐。

Kafka 的顺序是"分区内有序"而非"全局有序"。同 key 同分区保证业务实体顺序，跨分区全局有序违背并行设计，成本高（单分区/单线程）。选型时用 key 分区满足业务实体级顺序，避免追求全局有序。

• traceId 跨消息传播
• 消费延迟监控
• 链路可观测性

异步消息链路的可观测性难点在于"事件在服务间异步传递，产生跨服务的调用链"。traceId 传播：生产者把 traceId（与 spanId）写入消息头（如 Kafka 消息 header、RabbitMQ 消息属性），消费者从消息头取出 traceId 并注入到处理上下文，从而使"生产事件 → 消费处理 → 下游调用"连成一条完整 trace，配合 OpenTelemetry/Zipkin 实现跨服务链路追踪。传播时需处理消息批量、重试（同一 traceId 多次消费）、二进制消息头格式。消费延迟监控：监控每个消费组/分区的 lag（最新 offset - 已消费 offset），通过指标（如 Kafka lag、消息从生产到消费的端到端时间）告警，反映消费积压与处理延迟；同时监控消息处理耗时、失败率、重试次数。异步可观测性还需记录事件元数据（traceId、事件类型、时间戳、来源）、审计日志与死信队列监控。

异步可观测性 = traceId 跨消息传播（组成链路）+ 消费延迟/lag 监控（反映积压与健康）。traceId 传播是异步链路追踪的关键，消费延迟监控是异步系统健康的核心指标。

• 四种 exchange 语义
• 绑定（binding）与路由键
• 适用场景

RabbitMQ 通过 exchange 决定消息如何路由到队列：

• direct：按完整的路由键（routing key）精确匹配队列绑定的键，一对一精确路由，适用于按 key 定向投递（如按级别、按用户）。
• topic：路由键支持通配符（* 匹配一个词、# 匹配零个或多个词），按模式匹配绑定，灵活，适用于按主题/模式分类（如 order.* 匹配 order.created）。
• fanout：把消息广播到所有绑定该 exchange 的队列，忽略路由键，适用于事件广播到多个消费者（pub/sub）。
• headers：按消息头（headers）匹配绑定（而非路由键），可指定匹配规则（x-match: all/any），适用于依赖头属性的复杂路由。 适用场景：direct 精确路由、topic 按主题模式路由、fanout 广播、headers 按属性路由。工程上常用 topic 实现灵活的事件路由，fanout 实现广播。

四种 exchange 的差异在"路由匹配规则"：direct 精确键、topic 通配模式、fanout 广播、headers 按头属性。选型取决于路由的精确性、灵活性与广播需求。

• batch 大小对吞吐/延迟的影响
• 压缩算法选择
• 原理

Kafka 生产端默认使用批量（batch）发送：消息先累积到缓冲（linger.ms、batch.size），达到 batch 大小或超时后作为一个批次发送，减少网络往返与 broker 请求数，提升吞吐。batch 越大，单次请求包含消息越多、吞吐越高，但会增加延迟（等待凑满 batch）与内存占用；batch 过小则吞吐低、请求多。压缩：Kafka 支持 gzip、snappy、lz4、zstd 等压缩算法，压缩消息体积，减少网络传输与磁盘占用，提升有效吞吐。压缩也依赖批量（批量越大压缩率越高）。压缩算法选型：gzip 压缩率高但 CPU 开销大、延迟略高；snappy/lz4 压缩快、CPU 低、延迟低；zstd 压缩率高且速度较快，是吞吐与压缩兼顾的选择。权衡：大 batch + 高压缩率提升吞吐但增加延迟与 CPU；小 batch + 低压缩降低延迟但吞吐下降。需按场景（吞吐优先 vs 延迟优先）调参。

batch 与压缩是 Kafka 吞吐与延迟的核心杠杆：batch 大小、linger.ms 决定攒批程度（吞吐 vs 延迟），压缩算法决定"体积 vs CPU"。批量与压缩相互配合（批量提升压缩率），工程上需权衡吞吐、延迟与 CPU。