把七个场景装进一张地图
走完七个场景，你会发现高并发没有"标准答案"，只有"合适的取舍"。这一页把所有场景摆到同一张桌子上横向对比，提炼通用原则，并给出可以直接抄的选型决策矩阵与演进路径。
七场景核心矛盾与优化方向横向对比
每个场景都有一句"命门"。把它们放在一起看，你会发现高并发的解法虽然千变万化，但套路高度收敛：拦截、异步、缓存、分片、降级——变的只是它们的组合比例。
| 场景 | 流量特征 | 核心矛盾（一句话） | 三角站位 | 王牌手段 |
|---|---|---|---|---|
| 秒杀/抢票 | 瞬时脉冲 | 百万人抢一行数据库记录 | 一致性+性能 | 漏斗拦截 + Redis 预扣减 + MQ 削峰 |
| 车联网/IoT | 持续高压写 | 写入永不停歇，存储无限膨胀 | 性能+可用性 | Kafka 缓冲 + 时序库 + 冷热分层 |
| Feed 流/推荐 | 读多写少 | 大V一发帖，千万收件箱爆炸 | 性能+可用性 | 推拉结合 + 多级缓存 |
| 热搜榜/在线统计 | 读写双高 | 全网流量砸向同一个热 Key | 性能+可用性 | 本地聚合 + 分片计数 + 概率算法 |
| 任务调度 | 整点脉冲 | 千万闹钟不重响、不漏响 | 一致性+可用性 | 时间轮 + 分片广播 + 幂等兜底 |
| 金融支付 | 高并发+强一致 | 又要快，又要分毫不差 | 一致性至上 | TCC/消息表 + 对账兜底 |
| 弹幕/IM 长连接 | 海量连接+扇出 | 连接吃内存，扇出吃带宽 | 性能+可用性 | 网关分层 + 批推抽样 + seq 补拉 |
高并发优化的通用原则（取舍与权衡）
能拦截就别处理 —— 漏斗原则
请求越早被挡下成本越低：CDN/静态化挡一批、网关限流挡一批、缓存挡一批，能到数据库的请求应该只剩涓涓细流。（秒杀页把 100 万请求过滤成 100 个写入）
能异步就别同步 —— 削峰填谷
用户只需要"受理成功"，不需要"处理完成"。MQ 是高并发第一神器：把脉冲流量摊平成匀速消费，代价是你要学会面对"处理中"这个中间态。
能不精确就别精确 —— 误差换性能
HyperLogLog 用 12KB 数 1 亿人，误差 0.8%；在线人数"10万+"模糊显示。先问业务容忍度，再决定花多少钱买精度。（热搜榜页的合法货币）
热点要拆，冷热要分 —— 分而治之
热 Key 拆分片、大 V 单独处理、热数据 SSD 冷数据对象存储。二八定律是高并发最可靠的地图：找到那 20% 的热点，单独伺候。
一切皆可降级 —— 保命优先
非核心功能（推荐、特效、实时性）都要有开关。大促前先演练"关掉哪些功能系统还能活"。降级预案没演练过 = 没有预案。
幂等是分布式的入场券 —— 重复必然发生
网络会重传、MQ 会重投、用户会连点、调度会重触发。"至少一次 + 幂等消费"是工程界的标准答案，唯一 ID + 状态机检查，每个写接口都要有。
最终一致 + 对账兜底 —— 别迷信强一致
强一致又慢又脆，多数链路用最终一致就够——但必须配对账/校准任务定期抓差异。支付系统如此，库存系统如此，计数系统也如此。
为失败设计，而不是为成功设计 —— 面向雪崩编程
重连要退避、依赖要熔断、缓存要防击穿、扩容要预留水位。压垮系统的从来不是流量本身，而是流量引发的连锁反应。（重连风暴、缓存雪崩、调度自杀式脉冲）
技术选型决策矩阵（QPS 量级 × 一致性要求）
把两个最关键的维度画成一张矩阵：横轴是流量量级，纵轴是一致性要求。每一格给出一个"组件套餐"——不是唯一解，但照抄不会翻车。
| 一致性 \ QPS | < 1千（起步） | 1千 ~ 1万（成长） | 1万 ~ 10万（大厂线） | > 10万（顶流） |
|---|---|---|---|---|
| 强一致 钱/库存/凭证 |
MySQL 事务 + 唯一索引幂等，什么中间件都别加 | MySQL 主从 + Redis 预扣减 + 本地消息表 | 分库分表 + TCC/事务消息 + 热点账户缓冲记账 + 对账 | 单元化多活 + 自研分布式事务框架 + 实时对账 |
| 最终一致 订单流转/通知/Feed |
MySQL + 定时任务补偿 | Redis 缓存 + RocketMQ/Kafka 异步化 | 多级缓存 + MQ 削峰 + 推拉结合 + 分片消费 | 异地多活 + 分层缓存体系 + 自动对账校准 |
| 弱一致/可丢 弹幕/计数/监控 |
Redis 单实例计数直接梭哈 | Redis + 本地聚合批量刷新 | 分片计数 + HyperLogLog + 抽样降级 | 边缘聚合 + Flink 流式计算 + 概率数据结构全家桶 |
架构演进路径：跟着业务生命周期走
最贵的错误不是"架构不够先进"，而是"架构超前于业务"。正确的姿势是：让架构永远比当前流量领先半步——不多不少。
🌱 初创期（日活 < 10万 · QPS < 1千）—— 单体 + 主从，跑通业务再说
- 架构：单体应用 × N 实例 + Nginx 负载均衡 + MySQL 主从 + Redis 缓存热点。就这四样，别加了。
- 必须做对的三件事：接口幂等（以后救命）、数据库索引（80% 的慢都是没索引）、代码分层清晰（为日后拆分留缝）。
- 常见翻车：初创团队上微服务 + K8s + 服务网格，业务没跑通，运维先累死——复杂度是借来的债，流量没来就要付利息。
🌿 成长期（日活 10万~500万 · QPS 1千~5万）—— 拆服务、上 MQ、防热点
- 架构：按业务域拆微服务（订单/用户/商品，别拆太细）+ MQ 异步解耦 + 多级缓存 + 核心表分库分表。
- 标志性事件：第一次大促被打挂 → 引入限流熔断降级三件套；第一次缓存雪崩 → 学会过期时间加随机数。
- 常见翻车：拆微服务拆上瘾，200 个服务互相调用查个订单要过 8 跳——拆分的粒度应该由团队人数决定，不是由技术情怀决定。
🌳 成熟期（日活 > 500万 · QPS > 5万）—— 单元化、多活、精细化治理
- 架构：同城双活/异地多活 + 单元化部署（用户分片封闭）+ 全链路压测 + 混沌工程常态化演练。
- 关注点转移：从"扛得住吗"变成"挂了一个机房还扛得住吗"和"这么多机器能不能省点钱"（冷热分层、弹性伸缩、离在线混部）。
- 常见翻车：多活架构建好了但从来不敢真切流量——没有定期演练的多活，只是贵了三倍的单活。
结语
如果这一整套 Wiki 只能让你记住三句话，希望是这三句：
1️⃣ 高并发的本质是取舍
不可能三角逼你排优先级。先问"什么可以牺牲"，再问"怎么优化"——顺序反了，做出来的就是又贵又慢的四不像。
2️⃣ 套路是收敛的
拦截、异步、缓存、分片、降级、幂等——七个场景翻来覆去就这六板斧。新场景来了先套用矩阵定位，八成能直接抄作业。
3️⃣ 架构跟着业务走
没有"最好的架构"，只有"当前阶段合适的架构"。让架构领先业务半步：领先太多是浪费，落后半步是事故。