高并发与系统设计题库

这部分是综合技术面、技术总监面特别容易问的。

重点不是背“高并发三板斧”，而是要让对方感觉你真的做过：

一、高并发系统你先看什么

我一般先看 5 件事：

很多链路不适合同步串到底。同步链路越长，延迟越大，失败点越多，高峰期也越容易被拖垮。

在推广 ROI 线里，点击处理、归因、回传、报表更新不适合都放在同步接口里，所以通过 Kafka 解耦，把可延迟处理的逻辑拆出去。

如果量小，可以扫订单表；如果量大，不应该全表扫描，而应该把超时事件独立出来，比如延迟队列、Redis ZSet、时间轮等。

真正关闭时，要通过状态机和条件更新保证幂等，只允许待支付订单关闭，防止和支付回调并发冲突。

消息系统里重复消费是常态，不是异常。

解决方式一般是：

缓存一致性没有万能方案，要看业务能容忍多大的短暂不一致。交易和支付状态这种敏感数据，我会更谨慎，不会过度依赖缓存。

我一般按链路拆：

建议按这个顺序答：

支付状态并发、回调重入、消息重复消费、点击回传链路高峰都可以讲。

因为本质是分析型查询，不是事务型查询，继续压在主库上收益很差。

核心链路保强一致，扩展链路尽量最终一致；不是所有动作都要一个大事务包住。

我做高并发和系统设计时，重点不是先上什么组件，而是先看链路、数据类型和一致性要求，再决定哪些地方用缓存、哪些地方异步、哪些地方需要状态机、幂等和补偿。像支付、订阅、回调、推广回传、报表分析这些场景，我更习惯先把问题拆层，再做方案，而不是直接堆技术。