题目重点：从写入、复制、消费和提交位置解释消息系统，区分重放与外部副作用。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 参考Kafka分区日志模型；实际版本与acks/复制配置需确认，本文不指定当前默认值。
解题路线
- topic分partition，每partition追加日志提供局部顺序。key分区决定相同业务实体是否能保持顺序；跨partition不自动有全局顺序。
- producer批量与压缩提高吞吐，leader/副本和确认策略影响耐久性；客户端超时不必代表消息没写入，需幂等与重试合同。
- consumer group分配partition并跟踪offset；处理前提交可能丢处理，处理后提交遇崩溃可能重复。业务幂等或事务协调处理重复。
- Kafka内事务可协调支持范围内的读处理写，但向外部数据库/支付的副作用需要外部配合，不能说全系统exactly-once。
- 监控lag、消费速率、分区热点与rebalance；lag下降可能只是丢处理或offset跳过，需要业务完成指标。
手动走一遍
消费订单后数据库写成功但offset没提交，恢复后重放；按orderID/version唯一更新防重复副作用。同一热点key全部去同分区时，增加consumer不必提升这个key吞吐。
规模与取舍
吞吐受partition并发、批量、复制、磁盘和consumer处理限制；保留日志空间约写入字节率×留存时间×副本数，压缩等另计。
易错点与追问
容易失分的边界
- 全topic全局顺序。
- offset提交等于业务成功。
- Kafka事务自动覆盖任意外部系统。
继续深挖
- 如何设计死信与重放？
- 修改partition数如何影响按key顺序？
技术参考
- Kafka Design：技术语义参考，具体题目按本文约定。
