消息队列

三大价值：异步化，把非核心链路（发短信、积分、记日志）从同步调用中剥离，响应时间从串行总和降到主链路耗时；解耦，生产者只管发事件，下游增删订阅方不改上游代码，系统按主题演进；削峰填谷，流量洪峰先进队列排队，消费端按自己的处理能力匀速拉取，数据库不被瞬时打挂。代价同样要答全：系统复杂度上升，多一个要高可用部署与容量规划的基础设施；一致性从强变最终，要处理消息丢失、重复与乱序；延迟与排查难度增加，链路跨了队列后问题定位要靠消息轨迹与全链路追踪；宕机风险转移，队列本身故障影响面大，需集群与副本。结论是业务允许异步与最终一致时才值得引入。

存储层：分区文件用仅追加的顺序写（磁盘顺序写带宽接近内存），并按策略刷盘与页缓存利用操作系统 cache，读也是顺序读，写入快照式保留而非删一条动一次；消费者各自维护 offset，broker 无消费状态，天然规模化。传输层：小消息批量聚合发送与压缩（gzip、lz4、zstd、snappy），摊薄网络与序列化开销；零拷贝发送，日志段经 sendfile 直接从页缓存到网卡，跳过用户态拷贝；分区内批次顺序消费利用预读。架构层：分区是并行单位，横向扩 broker 与分区线性扩吞吐；rebalance 与元数据管理持续优化（KRaft 去掉 ZooKeeper）。答出顺序写、零拷贝、批量压缩、分区并行四点并解释消费者 pull 模型的优势即完整。

消费者组是横向扩展与容错的单位：一个分区在同一时刻只被组内一个消费者消费，组内消费者数超过分区数则多余者空闲，吞吐上限由分区数决定；不同组之间互不影响，各自全量消费，实现发布订阅。组内成员与分区分配靠组协调者（broker 侧）维持：成员入组选 leader、按分配策略（range、round-robin、sticky、cooperative-sticky）生成分配方案下发。rebalance 触发条件是成员增减、订阅主题或分区数变化；期间旧协议 stop-the-world 暂停消费，全组重复加入，频发 rebalance 是线上消费延迟的头号原因。治理手段：session 与 max poll 间隔调优防误判、cooperative-sticky 增量重平衡、静态成员资格免重启触发。跨组重复消费需外部幂等。能讲触发条件与调优手段即优秀。

不丢失要分段保证。生产端：acks 设 all 等待所有 ISR 副本确认，开启重试并配幂等生产者（producer id 加序列号去重）与 delivery timeout，回调确认失败落库补偿。broker 端：副本因子不小于 3、min.insync.replicas 不小于 2，acks all 与之配合在宕机时不丢；关闭 unclean leader 选举防落后副本上位；刷盘依赖副本冗余而非单机 fsync。消费端：先处理完业务再手动提交 offset，禁止先提交后处理的自动提交习惯；处理与提交放同一事务或用幂等表兜底。不重复在分布式下无法绝对避免（网络重试必然引入重复），标准答案是消费幂等：唯一键去重表、数据库唯一约束、Redis setnx 加状态机版本号，或把消费与业务写在同一本地事务。能按三段各给参数即满分。

kafka 只保证分区内有序，全局有序要么单分区（牺牲吞吐），要么按业务键（同一订单 id）哈希到同一分区，保证同一实体的事件顺序。乱序的来源：生产端重试与 acks 为 1 时先发后到，需开幂等生产者（max in flight 五以内）保序；rebalance 期间分区换人接管、offset 回退重放历史消息与新消息交错；消费端多线程并发处理同一分区消息时完成顺序与拉取顺序不同，要按 key 再哈希到线程或用内存队列保序；事务与超时回滚后重投。RocketMQ 的顺序消息在生产者队列选择与消费端锁队列上做了封装。回答主线：识别顺序单位（entity 级而非全局）、发送端分区键、消费端单线程或键级串行，再点出重试与 rebalance 两个破坏点。