CVTE 应用软件一面：告警洪峰、消息幂等与缓存故障

《面试题目》

1. 能否介绍自己，以及项目的核心处理链路？
2. 告警量突然增长二十倍，怎样避免接入服务被拖垮？
3. 怎样让同一个故障的事件有序处理，同时允许不同故障并行？
4. Kafka 提供消息可靠性后，业务层为什么仍需幂等？
5. 数据库事务提交成功、Kafka 消息发送失败，怎样保证事件最终送达？
6. 告警聚合怎样避免把两个独立故障合并？
7. Redis Cluster 主从切换时，为什么可能丢失已确认写入的数据？
8. 单个 Redis key 出现极高访问量时，怎样处理？
9. 分布式锁自动续期后，怎样防止过期持有者继续写数据？
10. MySQL 查询命中了索引，为什么仍可能很慢？
11. 可重复读事务中，普通查询和加锁查询为什么可能看到不同结果？

《参考解析》

有序不等于全局串行

先定义故障身份，让同一业务键进入同一分区，并在消费端保留该键的处理顺序。若收到消息后又直接扔进共享线程池，执行顺序仍可能变化。不同键可以并行，但同一键的状态更新要检查事件版本，重试也要使用同一个幂等标识。

Outbox 把业务与待发事件放进同一事务

业务更新时同时保存一条待发送事件，后台再把它投递到消息系统。这样，提交成功后可以从数据库中找到尚未发出的事件。发布器可能发成功后还没来得及标记状态就退出，因此消费者仍需要处理重复事件。它解决的是跨系统操作中可追踪、可补发的问题，不会让所有外部副作用自动只发生一次。

续期不能证明旧进程已经停下

旧持有者在长暂停后恢复，可能继续执行它以为仍然有效的任务。需要让最终资源检查所有权或递增的隔离令牌，拒绝已经失效的一代写入。同一代的多次合法操作如何识别也必须定义清楚，不能简单照搬一个比较符号。只有锁服务续期、资源端完全不校验，无法消除这种迟到写入。

先区分查询语义，再查慢在哪里

普通一致性读与锁定读有不同规则；等待锁、扫描过多记录、回表、排序和传输大字段都可能使查询变慢。可重复读下，一致性读通常复用首次一致性读建立的快照，不能笼统地说所有查询都固定在事务开始瞬间。相关规则见 MySQL 一致性非锁定读说明。