题目重点：EM 系统设计题目要求 producer SDK、topic/partition/broker 与 durability、consistency、availability，重点拆解跨 broker 顺序。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版为同一 topic-partition 提供每分区严格日志顺序，不承诺不同 partition 的全局总序。
- Broker 路由应由分区元数据和当前 leader 决定；客户端错误地投向旧/非 leader 节点时返回 leader 信息重试。
解题路线
- 定义 API：produce(topic,key,payload,producerId,sequence) 与 consume(partition,offset)，先算吞吐、保留期、消息大小和可容忍丢失窗口。
- key 决定 partition，同分区 leader 分配递增 offset；producer SDK 缓存元数据、处理重试/退避并用 producerId+sequence 去重，避免超时后重复写。
- Leader 写 WAL 并复制到足够副本后按 ack 策略确认；说明强 durability 与延迟/可用性的取舍。leader 换届要 fencing 旧 leader 和恢复已提交日志。
- 题中 producer2 打到 broker1 时不能由 broker1 随便给同分区新顺序：先检查其是否为该 partition leader；否则转发或返回错误重定向。若两个 producer 在不同 partition，必须先问是否真的需要跨分区全局序。
- 消费者按 offset 读，可重复消费时业务端幂等；副本落后、broker 故障、网络分区分别说明读写可用性与数据恢复。
手动走一遍
两个 producer 都写 partition P：leader B1 对成功提交的消息依次赋 offset 100、101；producer2 误发 B2 时 B2 返回 B1 的元数据。若 B1 故障，选新 leader 时只对已提交日志承诺顺序，旧 B1 复活要被 fencing。
规模与取舍
单分区追加通常按消息大小顺序写入并向 R 个副本复制，网络写放大约 R；吞吐可通过 P 个分区横向扩展，但仅保留分区内顺序。没有题目规模参数，不给具体 broker 数。
易错点与追问
容易失分的边界
- 把 Raft 直接当全系统跨分区顺序的答案。
- 客户端发错 broker 后让非 leader 独立落盘。
- 重试不带序号导致重复。
- 只有副本却没有明确 ack/已提交定义。
- 把消费成功和生产确认混为一个事务。
继续深挖
- 必须全局顺序怎么办、成本如何？
- leader 故障时已 ack 消息可丢吗？
- 慢消费者和积压怎么处理？
- producer 超时后不知道是否成功怎么去重？
