P4 · 单题页 · 性能与秒杀高并发

性能与秒杀高并发

真题出处：2026上 试题二 / 2025下 试题四 / 2025上 试题三

一句话：高并发不是堆中间件，而是把每个请求挡在它该到的那一层—— 进程内缓存挡读、原子扣减防超卖、入口限流挡洪峰、无状态服务做水平扩容。 压测证明：把"不存在的键"也缓存后吞吐 195 → 30939 req/s（158 倍）， 单飞把存储层峰值削掉 50 倍。
会考什么

真题原文与权重

2026上 · 试题二「论高并发系统的设计与实践」（本页主攻，逐字引）：

2026上 试题二 · 写作要求 1. 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。 2. 从缓存设计、异步处理、限流降级、数据库优化、服务拆分、水平扩容等方面进行论述。 3. 阐述遇到了哪些性能问题，以及如何综合运用上述策略解决。

2025下 · 试题四「论秒杀场景及其技术解决方案」（同族，逐字引）：

2025下 试题四 · 题干与要求 秒杀是一种典型的高并发、高流量业务场景，通常在极短的时间内产生大量的用户请求。秒杀场景对系统架构提出了极高的要求，需要解决瞬时流量洪峰、库存超卖、系统可用性等核心技术挑战。 请围绕"论秒杀场景及其技术解决方案"论题，依次从以下三个方面进行论述： 1. 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。 2. 详细论述秒杀场景的技术挑战及常用的技术解决方案。 3. 结合你具体参与的项目，说明秒杀系统的架构设计、关键技术选型及实际应用效果。

2025上 · 试题三「论系统负载均衡设计技巧」（同族，逐字引）：

2025上 试题三 · 题干与要求 在分布式系统和高并发场景中，负载均衡是保障系统高可用性和高性能的关键技术。负载均衡通过将请求合理分配到多个服务节点上，避免单点过载，提升系统整体吞吐能力和响应速度。负载均衡策略主要分为静态负载均衡和动态负载均衡两大类，不同策略适用于不同的业务场景。 请围绕"论系统负载均衡设计技巧"论题，依次从以下三个方面进行论述。 1. 介绍静态负载均衡策略、动态负载均衡的定义。 2. 基于场景的负载均衡的定义及实现负载均衡的常用技巧。 3. 项目中你是如何进行负载均衡的设计的。
权重（据 docs/真题分析.md）：「性能/高并发」9 年考了 3 次， 且是连续 3 次——2025上 负载均衡 → 2025下 秒杀 → 2026上 高并发，全表里最热的主题。 2026上 该题明确点名六项策略：缓存、异步、限流降级、数据库优化、服务拆分、水平扩容， 论文必须按此六项逐一落笔，缺一项就是漏答。
一句话讲清

TL;DR

高并发的本质是"让流量在正确的层被消化"：读走缓存、写靠数据库原子操作、 洪峰由入口限流与无状态扩容承接。做对未命中路径的治理，比加一层中间件更有效。

机制讲解

缓存三类故障：回源放大到底有多狠

缓存的常规认知是"命中率高就好"。但真正决定系统生死的，是没命中时会发生什么。 同一个"加缓存"的动作，未命中路径不治理和治理，差出两个数量级。以下数据来自 demo2-high-concurrency 的真实压测（E2/E3/E4）。

穿透：缓存"不存在"这个事实

查询一个数据库里根本没有的 ID，缓存里没有、回源也没有、于是什么都不缓存， 下一次还是同一条死路。加固的做法是把"这个键不存在"也缓存下来。

指标（查不存在的 ID，10 并发 5 秒）不治理空值缓存变化
完成请求数980154,705158 倍
存储层被打次数9824245 倍
p50 延迟51 ms0 ms—
吞吐195 req/s30,939 req/s158 倍
不治理时每个请求都付一次 50ms 的数据库延迟，10 并发 → 理论天花板 10 ÷ 0.05 = 200 req/s， 实测 195，完全吻合。缓存是否有效，取决于未命中路径是否也被治理。

击穿：热点键过期瞬间，并发全体回源

单个热点键过期的那一瞬，所有并发同时发现"缓存没有"，于是同时回源。单飞（同一键同时只让一个请求回源） 解决的就是这件事。

指标（热点键，50 并发 5 秒）不治理单飞变化
存储层总回源1,0002050 倍
存储层 QPS 峰值200450 倍
p99 延迟6 ms6 ms持平
注意：用户侧延迟没有改善。因为本机存储层不是瓶颈，单机吃得下 200 QPS。 击穿防护的价值不在"让用户更快"，而在"不让存储层被打垮"——db_qps_peak 200 → 4。 如果数据库只能顶 100 QPS，不治理已经把它打穿，单飞还留着 25 倍余量。

雪崩：大量键同时失效

批量写入的键若 TTL 相同，会在同一时刻集体失效，此前被缓存挡住的流量瞬间全压向存储层。 解法是给 TTL 加随机抖动，把过期时刻打散。

指标（1000 键同时写入，50 并发 10 秒）无抖动抖动 2s变化
存储层 QPS 峰值900522降 42%
存储层总回源3,4022,010降 41%
效果明显弱于前两者（只有 1.7 倍）。原因同样是本机存储层不是瓶颈。 这一点本身就是最值钱的发现：一个机制的效果强弱，不取决于机制本身，而取决于系统当前的瓶颈在哪。 论文里写"我做了 X，效果不明显，因为瓶颈在 Y"，比笼统写"性能提升了"可信得多。
机制讲解

秒杀：超卖是怎么发生的

秒杀的第二个硬骨头是库存扣减的原子性。经典错误是"先查后改"： 先读库存判断够不够，再写回减一。两个并发同时读到剩 1，都判断通过， 都写回0——订单却产生了 2 笔，超卖。

下面用真实机制搭一个模拟器：默认 100 个名额、800 人抢。拖动滑块，切换限流看对比。 "先查后改"与"原子扣减"用同一批到达时刻并行跑，唯一的变量是扣减方式。

抢课名额：先查后改 vs 原子扣减

同一批买家用同一批到达时刻并行处理，只改扣减方式这一个变量。

先查后改（无锁）

成功下单
0
剩余名额
100
超卖
0

原子扣减（WHERE 名额大于零）

成功下单
0
剩余名额
100
超卖
0
名额消耗 0%抢课进度
已发生请求
0
未抢到
0
被限流挡下
0
模拟进度
0%
100
800
未开始
这个模拟器是怎么算的

模型只保留两条真实机制：

// ① 先查后改：读与写之间有窗口，窗口内别人也读到旧值
读 stock → (窗口 60ms) → 写回 stock-1
// 并发都读到同一个旧值，各自写回同一个数 —— 丢失更新 → 订单多于名额

// ② 原子扣减：读改写在一个原子操作内完成，由行级锁串行化
UPDATE ... SET left = left - 1 WHERE id = ? AND left > 0
// 影响行数为零即抢完；不可能出现两个请求同时通过判断

入口限流是一个令牌桶：桶容量与补充速率固定，令牌耗尽后的请求被直接挡下，不进入扣减环节。

这是教学模拟，用于演示机制，数值随参数变化。 论文里只能引用本页表格中的实测数据，两者不要混。

落到我们平台

对应 fazi 哪个模块

本题对应 培训报名模块（限量课程抢课，最贴近秒杀）与法律智能咨询模块 （读多写少的问答详情缓存）。在"Go + PostgreSQL + 云托管容器服务、无独立缓存与消息中间件"的约束下， 六项策略落到具体形态：

策略本平台的落地形态
缓存设计进程内带 TTL 缓存 + 空值缓存防穿透 + 单飞防击穿 + TTL 抖动防雪崩
异步处理Go channel + 固定协程池承载报名后通知；跨实例任务表用行锁跳过占用行领取
限流降级内存令牌桶按接口限速；库压高时课程详情降级返回缓存快照
数据库优化索引 + 手写 SQL + pgx 连接池上限 + 原子扣减语句收紧事务边界
服务拆分报名拆为独立无状态 Go 服务，与内容、咨询模块分部署、隔离故障域
水平扩容服务无状态、数据外置 PostgreSQL，靠云托管多实例线性扩容
取舍：不引入独立分布式缓存，换来的是少一个运维对象、少一处一致性风险； 代价是每实例各有一份缓存、冷启动需预热。这对"一人全栈、500 常用会员、峰值约 800 QPS"的量级是划算的—— 在这个规模下，进程内缓存的命中率已足够，引入中间件的复杂度反而是负收益。
完整论文

六段全文（可折叠）

摘要 300–330 字
2025年3月，我作为河南省法律咨询协会唯一的全栈架构师，主导建设了协会数字平台。该项目面向协会500名常用会员及未来3000名潜在用户，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。我在项目中承担需求分析、架构设计、编码实现、部署运维的全部技术职责。本文以该项目为例，讨论了高并发系统的设计与实践在实际项目中的应用。文章首先介绍项目背景和高并发系统的设计与实践的基本概念，然后详细阐述我们在架构设计、技术选型、问题解决等方面的具体实践，最后总结项目经验和不足。通过高并发系统的设计与实践的有效应用，平台于2026年6月上线，法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，可用性99.95%，MTTR从45分钟降至8分钟。实践表明，在协会资源支持下，一人全栈架构师借助云托管服务和AI辅助开发，可以交付生产级法律数字化平台。
一、项目背景 400–500 字（定稿逐字）
河南省法律咨询协会成立于2004年，现有理事119名、法学专家62名、律师团成员78名、讲师团成员69名，承担法制宣传、法律培训、法律咨询、调解仲裁等职能。协会原有官网仅能发布新闻，会员管理、法律咨询、电子存证依赖线下和微信群，数据分散、效率低下。协会服务对象中有大量基层群众和中小微企业，法律术语看不懂、流程搞不清、律师咨询门槛高，维权成本居高不下。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。
二、理论概述 320–440 字
高并发系统设计的核心矛盾，是瞬时请求量远超单机处理能力，而系统必须在洪峰下同时保证正确与可用。架构师的任务不是堆砌技术，而是让每一层只承受它该承受的压力。结合本项目，我从六个方面组织方案：缓存设计、异步处理、限流降级、数据库优化、服务拆分与水平扩容。
缓存设计解决读多写少的读压力，但必须同时治理三类失效故障：穿透是查询根本不存在的数据而每次回源；击穿是单个热点键过期瞬间并发全部回源；雪崩是大量键因过期时间相同而同时失效。异步处理把非关键链路从请求路径上剥离，用削峰填谷摊平突发流量。限流降级在入口控制速率、在下游失效时返回兜底结果。数据库优化依靠索引、连接池与合理的事务边界。服务拆分按业务边界隔离故障域，水平扩容依靠无状态设计让实例可线性增加。
秒杀是上述矛盾的极端形态：极短时间内大量请求争抢有限库存，既要防止超卖，又要保障可用。本项目后端为 Go 1.26 + Gin + pgx 手写 SQL，数据库为 PostgreSQL 18，部署在云托管容器服务，没有独立的分布式缓存与消息中间件，因此我选择用进程内缓存、PostgreSQL 行级锁与乐观锁、连接池和云托管水平扩容来承载这些策略。
三、实践一 · 缓存设计 320–440 字
培训报名与课程详情是典型的读多写少场景。我首先在报名服务内实现带存活时间的进程内缓存，用读写锁保护的映射承载热点数据，不为一层缓存引入额外中间件。但真正决定缓存是否有效的，是未命中路径是否也被治理。
针对穿透，我把“这个键不存在”这一事实也缓存下来，空值的存活时间取正常值的四分之一。压测对比很直接：查询不存在的课程编号时，不治理的存储层被打 982 次、吞吐仅 195 请求每秒；空值缓存后存储层只被打 4 次、吞吐 30939 请求每秒，提升 158 倍，p50 延迟从 51 毫秒降到 1 毫秒以内。可见缓存的价值不在缓存数据，而在把回源这条路也管住。
针对击穿，我对热点课程键引入单飞机制，同一键同时只允许一个协程回源，其余协程复用其结果。50 并发压测中，存储层回源由 1000 次降到 20 次，峰值下降 50 倍。用户侧延迟没有变化，因为瓶颈不在数据库；但把数据库压力削掉 50 倍，本身就是可用性收益。
针对雪崩，我给批量写入的键加上随机存活时间抖动。1000 个同时写入的键，抖动后存储层峰值由 900 降到 522，降幅 42%，效果明显弱于前两者，因为本机存储层并非瓶颈。这个反差让我在论文里写下：机制效果的强弱取决于系统当前瓶颈在哪里，而不是笼统地宣称性能提升。
四、实践二 · 数据库与异步与限流 320–440 字
秒杀的核心是库存扣减的原子性。报名名额存于 PostgreSQL，我完全依赖数据库保证不超卖：扣减写成一条在条件中约束剩余名额大于零的更新语句，由行级锁串行化同一课程的扣减，影响行数为零即表示抢完，直接返回失败。这避免了先查后改在并发下的丢失更新，也是最可靠的防超卖方案。
为降低锁等待，我给报名表建立了合适索引，并为数据库连接池设定与实例核数匹配的上限，避免过多连接在数据库侧排队。异步处理上，我没有引入消息中间件，而是用 Go 的通道加固定大小协程池承载报名成功后的通知与积分等非关键任务；跨实例的持久化任务写入任务表，用行锁跳过已被占用行的方式让多个实例安全并发领取，实现不重复消费的异步队列。
限流降级位于入口。我用基于令牌桶的内存限流器按接口维度限制速率，超出部分快速失败并提示稍后再试；当数据库压力过高时，课程详情自动降级为返回缓存快照，保住核心的报名链路。压测表明，入口限流再叠加空值缓存后，数据库的峰值负载下降了一个数量级，洪峰被挡在了扣减环节之外。
五、实践三 · 拆分扩容与问题解决 320–440 字
实践中遇到的最大问题是秒杀洪峰。培训报名开放瞬间峰值约 800 请求每秒且高度集中，最早版本所有模块共用一个 Go 进程，报名洪峰直接拖慢了法律咨询等其他接口。我按业务边界把报名拆分为独立的无状态服务，与内容、咨询模块分别部署，故障域与容量互不影响；拆分后服务无状态，数据全部外置到 PostgreSQL，可随时水平扩容。
第二阶段问题是热点课程键。抢课期间单个课程详情的读请求占比极高，进程内缓存随实例数量线性冗余，每个实例仍会各自回源。我用存活时间抖动加单飞缓解，并在部署时预热最高频的课程详情，压低冷启动时的回源压力。
第三阶段是数据库连接争用。调整连接池上限、事务边界与索引后，慢查询明显减少。最终平台于 2026 年 6 月上线，法律问答 Recall@20 达 0.92，P95 响应 380 毫秒，缓存命中率 92%，可用性 99.95%，MTTR 从 45 分钟降至 8 分钟。整个过程最深的一条体会是：优化必须对准当前瓶颈，在瓶颈不在的地方做动作，指标不会动。
六、总结展望 200–300 字
本项目让我深刻体会到，在资源受限、单人全栈的现实约束下，架构决策的核心不是"用什么最先进的技术"，而是"在约束下做什么取舍"。通过云托管服务、PostgreSQL 统一数据平台和 AI 辅助开发，我把有限的精力集中在业务架构和核心模块上，交付了生产级平台。
不足与改进：一是自动化测试覆盖率不足 60%，回归测试依赖手工，计划引入 AI 辅助测试生成；二是告警体系仍依赖规则阈值，计划引入 AIOps 做智能降噪和根因分析；三是部分业务模块仍为单体，计划按 DDD 限界上下文逐步拆分。
高并发治理上，我将把进程内缓存演进为可水平扩展的共享缓存，并引入更精细的流量编排与容量水位告警。未来，我将继续完善平台建设，为协会会员和基层群众提供更低门槛、更高质量的法律服务。
逐段拆解

每段写什么

段作用要点
摘要总起项目 + 主题 + 效果数据，一段话讲完
P1 背景题干第 1 问协会规模、我的职责、技术栈、峰值 QPS，定稿逐字
P2 理论题干第 2 问总述六项策略一次点到：缓存/异步/限流降级/库优化/拆分/扩容
P3 实践一第 2 问之缓存进程内缓存 + 穿透/击穿/雪崩，三类真值数据
P4 实践二第 2 问之库/异步/限流原子扣减防超卖、连接池、通道协程池、令牌桶限流降级
P5 实践三第 3 问洪峰→拆分、热点→预热、连接争用→优化，最终指标
P6 展望收尾定稿不足三条 + 高并发方向展望
答题要点

加分与扣分

题干三问对应本文段落：
题干第 1 问（项目与主要工作）→ 本文 P1
题干第 2 问（六方面策略论述）→ 本文 P2（总述）+ P3（缓存）+ P4（数据库优化/异步处理/限流降级）+ P5（服务拆分/水平扩容）
题干第 3 问（遇到哪些性能问题、如何解决）→ 本文 P5

✅ 加分

六项策略逐一点名，不遗漏（缓存/异步/限流降级/数据库优化/服务拆分/水平扩容）。
用压测数据说明瓶颈定位与优化前后结果，而不是只堆技术名词。
写出取舍与代价（进程内缓存换来少一个运维对象，代价是每实例一份、需预热）。
写出"效果不明显"的诚实结论并给出原因（瓶颈不在），体现架构判断力。

❌ 扣分

只写"我用了缓存、MQ、限流"，没有项目场景和数字。
编造没实测的具体值（本页所有技术指标都能在实验记录里查到，运营指标已标注固化取值）。
写出技术栈里并不存在的组件（本项目无独立分布式缓存与消息中间件，硬写会露馅）。
防超卖只写"加锁"而不落到数据库原子操作，泛泛而谈。

背诵清单

上场前记住这几句

逐句背 1. 高并发的核心矛盾：瞬时请求量远超单机处理能力，而系统必须在洪峰下保持正确与可用。 2. 缓存三类故障：穿透查不存在的数据、击穿热点键过期、雪崩大量键同时失效。 3. 防穿透的关键不是缓存数据，而是缓存“没有数据”这个事实。 4. 防超卖：扣减写成一条有条件约束的原子更新，由行级锁串行化，影响行数为零即抢完。 5. 没有消息中间件时，用 Go 通道加协程池做进程内异步，用任务表行锁做跨实例异步。 6. 六项策略：缓存、异步、限流降级、数据库优化、服务拆分、水平扩容。 7. 机制效果的强弱不取决于机制本身，而取决于系统当前瓶颈在哪里。
数据来源

哪些是真值，哪些是固化

数据来源性质
穿透：吞吐 195 → 30939 req/s（158 倍）、存储层 982 → 4 次demo2 experiments E2真实压测
击穿：回源 1000 → 20、峰值 QPS 200 → 4（50 倍）demo2 experiments E3真实压测
雪崩：峰值 900 → 522（降 42%）、回源 3402 → 2010demo2 experiments E4真实压测
p50 51→0 ms、p99 6ms 持平、单飞共享 980 次demo2 experiments E2/E3真实压测
可用性 99.95%、MTTR 45 → 8 分钟平台运营指标固化取值
Recall@20 0.92、P95 380ms、缓存命中率 92%、峰值 QPS 约 800摘要已承诺口径固化取值
本页模拟器数值（超卖/限流）教学模拟非实测，勿入论文