1 互联网行业方案要回答什么
互联网行业方案首先要回答：谁在什么时间访问系统，系统必须完成什么业务，遇到拥堵时又优先保住什么。只画出负载均衡、应用、缓存和数据库，还不能解释这些问题。架构图表达组件关系，方案还要交代需求、容量依据、选择理由、成本边界和故障动作。对于刚开始做方案的人，最有价值的能力是把业务语言转换为可测量的条件，再把条件转换为可以验证的设计。
本课沿用零售订单 API 桰例。用户浏览商品后提交订单，再查询订单结果；订单服务记录订单，并调用库存预留能力。商品图片和公开活动说明属于内容访问，创建订单与查询个人订单属于业务 API。库存的具体扣减、支付流程与大促交易一致性留给后续课程。本课只约定：创建订单返回成功前，订单已经持久化，库存预留已经得到明确结果；结果不明确时返回处理中，由订单标识继续查询，不能把超时直接解释成失败。
为使讨论可复现，先设定练习条件：业务 API 平时每秒收到 3000 个请求，预计峰值为每秒 12000 个请求，持续 15 分钟。查询占 80%，创建占 20%；静态内容流量另计，不能混进这个比例。正常峰值时，查询响应时间的 p95 不超过 200 毫秒，创建请求的 p95 不超过 500 毫秒。p95 表示约 95% 的请求在该时间内完成，不能拿平均值替代。主动限流、业务拒绝和服务错误要分别统计，也要保留全部请求的等待体验。
需求还包括数据边界。个人订单必须经过身份校验，不能进入公开内容缓存；用户只允许查看有权限的订单。创建请求必须携带幂等标识，同一个业务意图重复提交时应得到相同订单结果。幂等不是在入口看到重复就简单丢弃，而是让业务服务识别同一个意图，并能查询此前处理结果。实现细节可以逐步完善，方案中却必须先写清楚由谁负责，以及记录保存多久。
高可用目标也要翻译成场景。本课要求单个可用区退出后，系统仍能接住上述业务峰值；这需要计算剩余容量，并确认数据库和库存接口能否继续工作。月度可用性暂定为 99.9%，但这个目标不能直接推出某种部署方式。可用性应从用户能否完成约定业务来衡量，而不是只看应用进程是否存活。故障时允许短时间展示最近的非敏感商品信息，却不允许伪造下单成功或放松订单访问权限。
因此，方案的起点是一份条件清单：流量规模、读写比例、响应目标、正确性要求、故障范围和预算口径。这里的数字都是练习假设，实际项目应由业务预测、访问日志和压测共同支持。遇到未知值可以先给区间，同时注明验证负责人和截止时间。把未知条件藏在图里，会让评审者误以为容量和承诺已经得到证明。
2 流量入口、会话与内容分发
把用户点击后的请求路径展开，才能判断哪些流量应该到达订单应用。公开商品图片适合经过内容分发网络，即 CDN，由靠近用户的节点返回副本；创建订单必须进入业务入口。CDN 的作用是缩短公开内容的传输距离、减少源站重复发送，并不能替订单服务确认身份或完成写入。即使它们使用相同域名，也要根据路径和响应策略划清缓存边界。
业务请求通常经过域名解析、入口接入、负载均衡和应用实例。域名解析帮助客户端找到入口地址；入口负责连接接入、基础安全检查和路由；负载均衡把请求分给健康实例。现实产品可能把这些能力组合提供，初学时按职责理解即可。链路增加的每个环节都有超时、容量和故障边界，不能因为架构图上只有 1 个方框，就假定它具有无限吞吐能力。
会话决定请求能否自由分配。如果用户登录状态只保存在某个应用实例的内存里，后续请求切换实例就可能被要求重新登录。把会话放到共享存储，或者使用可验证的身份凭据，可以减少对特定实例的依赖。共享存储本身仍是依赖，需要容量与可用性保障。可验证凭据也需要有效期、签名校验和撤销策略。这里先关注责任和边界，不展开密码协议的内部机制。
对订单 API，应区分身份、会话和幂等标识。身份回答谁在访问，会话维护登录上下文，幂等标识关联某次创建意图。用户刷新页面可以产生新的查询请求，却不应因此产生新的订单。入口即使做过身份检查，订单服务仍要按用户与订单的归属执行授权检查。客户端传来的用户编号、订单编号和转发头都不能天然视为可信，可信来源与覆盖规则应明确记录。
内容分发的难点往往在缓存什么。公开图片可以使用带版本的文件名，发布新图片就生成新地址；活动说明可以设置较短有效期，并提供主动更新方式。个人订单查询带有身份信息和状态变化，不能直接套用公开页面的缓存策略。业务服务内部可以缓存经过授权的数据，但必须给出隔离键、可接受陈旧时间和失效规则。缓存命中率提高，并不意味着所有响应都可以共用。
响应头、路径规则和错误响应也应进入检查范围。登录跳转不能把个人内容变成公开对象，创建接口的错误不能被内容节点长时间缓存。对公开内容，要说明未命中时如何回到源站；对业务接口，要说明入口是否执行重试。入口不应自动重放未确认安全的创建请求。若客户端因超时使用同一个幂等标识重试，应能得到原订单结果，而不是再次创建。
把入口当作总闸门，也不等于把所有业务决策塞进去。入口适合按路由、调用方和总体压力执行粗粒度控制；某个订单是否允许取消、某个用户是否有权查询，仍由业务服务决定。分清这些职责后，方案才能解释为什么 CDN 命中会减少图片源站压力，却不会直接降低订单事务数量，也能解释为什么应用扩容之前必须先解决会话对实例的绑定。
3 弹性伸缩与热点保护
弹性伸缩的目的，是让可用处理能力跟上需求变化，同时控制空闲成本。它不是看到请求多就立即增加任意数量的实例。扩容要经过指标采集、规则判断、资源准备、进程启动、连接建立和健康检查。假设指标确认需要 30 秒，新实例准备需要 90 秒，从触发到接流量约有 120 秒间隔。流量在 10 秒内上涨时，单靠事后扩容无法填补这段空缺。
本课把经过压测的应用安全容量暂定为每实例每秒 1000 个请求。这里已经包含目标响应时间和实际接口组合，不能用最简单健康检查接口的吞吐量替代。平时部署 6 个实例，分布在 3 个可用区，每区 2 个；峰值前增加到 18 个，每区 6 个。峰值时退出任意 1 个可用区，剩余 12 个实例的安全容量恰好为每秒 12000 个请求。这是教学计算，实际还应验证入口分流与故障切换的瞬时影响。
已知活动可以提前 5 分钟扩容，并用小规模探测确认新实例可用。不可预测的增长则需要基础余量、自动扩容和入口保护共同承担。扩容指标可以同时参考请求量、处理队列、响应时间与资源使用率。只看 CPU 容易漏掉等待数据库连接的拥堵；只看响应变慢又可能在下游故障时盲目增加调用者。规则必须限制扩容速度与最大规模，并说明指标异常时如何处理。
热点保护解决另一种问题：总容量有余量，某个资源却被集中访问。假设缓存有 16 个分片，每个分片压测安全能力为每秒 1500 次访问，总量看似很大。但热门商品状态的某个 Key 每秒收到 6000 次查询，如果它始终落在同一个分片，该分片会先拥堵。增加应用实例只会带来更多并发连接，并不会把这个 Key 自动平均分散到所有分片。
对于允许短时陈旧的公开商品信息，可以考虑应用本地短缓存、热点副本或请求合并。短缓存降低重复远程访问，副本分担读取，请求合并让同一时刻的多个未命中共用少量回源。每种方式都要注明更新与过期规则。个人订单状态变化快、授权边界清晰，不能因为热门就直接复制成所有人可读的公开数据。热点策略应按数据类别选择，不能按缓存产品名字选择。
限流与排队也是容量设计的一部分。限流表示明确拒绝超过承受能力的请求，排队表示让请求等待可用资源；队列不是越长越安全。若请求只剩 100 毫秒时限，却还要排队 2 秒，最终只是占用内存并制造超时。订单创建应设置有界等待和明确结果，客户端收到限流后按约定退避，避免立即反复重试。对于查询，可以在满足数据边界时返回带更新时间的最近结果。
缩容也有业务影响。实例退出前要停止接收新请求，并给在途请求合理的完成时间；未完成的创建仍依赖幂等与结果查询处理。伸缩策略要防止指标轻微波动导致实例频繁增减。至于预测算法、调度器内部机制和复杂热点拆分，本课不展开；入门阶段先学会判断瓶颈位置、准备延迟和保护边界，比记住更多自动化术语更重要。
4 动手：对照一次大流量入口路径
这次动手使用测试环境与虚构订单，不向真实用户、真实支付或生产库存发压。目标是对照路径与证据，而不是把请求量数字推到最大。准备公开图片、个人订单查询和创建订单 3 类请求。查询使用多个测试账号及各自订单，创建使用可追踪的幂等标识。测试数据不能只有同一个订单，否则测到的可能只是特殊缓存命中，不能代表真实业务组合。
先写预期路径：图片在内容节点命中时不经过订单应用；查询经过入口、身份校验、应用与缓存，未命中才访问数据库；创建经过入口、应用、库存预留与订单持久化。为每次测试分配运行编号，并让业务请求携带请求标识。日志记录路由、结果类别与关键耗时，避免记录凭据和完整个人信息。请求标识应能关联链路，幂等标识则用于识别业务意图，二者用途不同。
先以每秒 3000 个业务请求稳定运行，再逐步提升到每秒 12000 个，并保持查询与创建的比例。公开图片负载独立记录。每个阶段都观察请求到达量、进入应用量、完成量、主动拒绝量和错误量，还要记录等待中的请求。不要只看压测工具成功收到响应的部分；压测端自身过载也可能让发送量下降，从而造成服务似乎稳定的错觉。
对照 3 组证据。入口侧看路由分布、排队、限流与连接错误；应用侧看实例数量、每实例吞吐、p95 和在途请求；依赖侧看缓存分片、数据库连接等待和库存接口响应。把这些指标放在相同时间轴上，标注流量变化与扩容时刻。如果入口收到的请求很多而应用接收较少，应先查入口限制与连接问题，不能直接判断应用处理太慢。
然后做受控对照：保持业务请求不变，让图片分别走已缓存路径和冷内容路径，观察变化是否发生在内容源站。再将测试会话分配到不同应用实例，检查登录状态是否保持。最后让少量创建请求在响应返回前模拟客户端超时，再用原幂等标识重试并查询订单。核对业务记录，确认重复请求没有变成重复订单；只看到相同响应码不足以证明幂等成立。
继续安排故障场景前，先设停止条件。出现订单重复、越权响应、依赖连接等待持续上升，或者测试错误率超过约定阈值，就暂停增压并保留现场。可以在预先授权的测试环境中停用某个应用可用区，观察入口是否转向剩余实例。数据库故障切换应另设演练，不能从应用故障的通过结果推断数据库也已经验证。每个场景只改变明确的条件，便于解释因果。
最终输出应是一页对照记录：预期路径、实际证据、出现偏差的时间、偏差对应的指标、下一步判断。比如图片源站请求明显下降而数据库写入保持不变，正好证明内容分发与订单写入属于不同负载。若扩容完成后应用耗时下降、数据库等待却上升，则说明瓶颈已经转移。动手的价值是校正方案假设，而不是给所有组件都贴上“压测通过”的标签。
5 成本与体验取舍
成本比较要先保证口径相同。单看实例单价，无法判断方案是否划算；还要纳入内容传输、入口处理、缓存、数据库、日志、跨区通信和故障余量。业务成本可以表达为每 1000 个成功创建订单消耗多少资源，也可以同时报告每 1000 个查询请求的成本。主动拒绝请求不能算作成功业务来稀释成本，压低成功量也不能伪装成资源效率提升。
先比较 3 个选项。方案 A 长期保留峰值应用容量，准备简单但平时空闲较多；方案 B 平时保持基础容量，在已知活动前扩容，并配置自动扩容兜底；方案 C 使用较小应用池，主要依赖入口限流维持稳定。它们分别影响固定支出、准备风险与请求完成比例。对于本课可预测的 15 分钟峰值，选择 B 比较合理，但仍需要为突然增长保留余量和明确拒绝策略。
可以把决定写成简短的架构决策记录，即 ADR。记录当前背景、备选项、最终决定、理由、代价与复议条件。比如“采用活动前预扩容，原因是启动与指标确认合计约 120 秒；接受平时保留 6 个实例的成本；若活动时间不再可预测，重新评估基础余量”。这样的记录让后来的人知道设计依赖什么条件，而不是把当时的结论当成永久规则。
依赖成本需要单独计算。假设峰值查询为每秒 9600 次、创建为每秒 2400 次，查询缓存命中率为 95%。把本练习中每次创建的完整事务和每次未命中查询，暂各记为 1 个已压测的数据库等效工作单位，则依赖需求为每秒 2880 个单位。数据库按相同业务组合测得安全预算为每秒 4000 个单位，预警线取 3200。这个简化只用于比较，真实读写成本不相等时必须换成实测权重，不能把它当作 SQL 条数。
缓存命中率如果降到 80%，同样流量会产生每秒 4320 个单位，超过安全预算。此时应用 CPU 可能仍然不高，用户却已经因数据库等待而超时。反过来，提高命中率也可能增加数据陈旧风险。允许陈旧 3 秒的公开商品说明与需要准确确认的订单创建，不应该使用相同体验承诺。成本优化必须在数据语义允许的范围内进行。
使用滑块时，先固定流量放行比例，观察命中率下降造成的依赖变化；再固定命中率，调整放行比例，观察完成机会与保护效果。主动拒绝能减少依赖压力，但会降低本次请求立即完成的比例。模型不计算用户重试、缓存热点和库存容量，因此只能帮助理解方向，不能直接产生生产配置。真正的参数还要通过流量分布、业务优先级和演练确定。
成本结论应有时间范围和价格来源。比较 1 个月的常态成本时，还要说明其中包含多少次活动、每次预热多久、故障余量是否持续保留。没有报价也可以先比较资源小时、传输量与存储量，避免编造金额。把更低支出换来的体验变化说清楚，才能让业务负责人判断这种取舍是否可接受。
6 常见坑：只扩应用不扩依赖
“应用已经扩到 18 个实例，为什么订单仍然超时？”常见原因是请求最终汇聚到没有扩展的依赖。每个应用实例若最多建立 50 个数据库连接，6 个实例的连接上限是 300，18 个实例则变为 900。数据库未必能承受这个并发，而且连接更多也不意味着事务完成更快。大量请求争用同一资源时，等待时间反而可能急剧上升。
因此，应用扩容前要列出依赖预算：数据库连接、缓存分片吞吐、库存调用速率、入口连接数以及日志写入能力。给应用分配的连接总额应受数据库整体预算约束，再按实例规模分配；不能让每个实例都以为自己可以用完整预算。连接池用于复用和限制连接，不是把等待消除。若池内请求等待已经超过接口剩余时限，应尽早失败并给出可识别结果。
重试会把局部拥堵变成额外流量。入口重试、应用重试和客户端重试如果互相叠加，同一个意图可能产生多次依赖调用。每层都认为只重试少量请求，整体放大却可能非常明显。方案要指定哪些错误允许重试、由哪层负责、总时限和最大次数是多少。创建接口还要依赖幂等保证，不能把“请求可能再发一次”与“业务允许再执行一次”混为一谈。
缓存故障尤其容易暴露这个问题。健康时，大部分查询在缓存结束；缓存不可用后，如果全部查询直接转向数据库，数据库收到的就接近完整业务流量。在本课峰值下，负载可能从每秒 2880 个等效单位升到 12000。此时无限等待缓存恢复、无限回源和继续扩应用，都会扩大影响。应设置短超时、有限回源与独立于缓存健康的依赖保护预算。
服务降级要写成具体行为。公开商品信息可以使用有年龄上限的最近副本；个人订单查询可以提示稍后刷新，或在满足隔离与时效约定时显示最近状态；创建订单无法确定结果时显示处理中，并提供查询入口。已经确认的失败、仍在执行的请求和成功持久化的订单必须区分。用统一的“系统繁忙”掩盖所有状态，会诱发用户重复提交，也会增加客服判断成本。
高可用部署同样不能只数应用副本。应用分布在 3 个可用区，如果数据库只有单个可用区的实例，故障边界仍然没有闭合。数据库需要适当的复制与切换能力，缓存要有分片或节点故障处理，入口必须能剔除异常目标。复制延迟、切换中断和客户端重新连接都会影响用户体验。是否丢失已确认订单，要根据数据库承诺和实际演练说明，不能仅凭“有副本”下结论。
检查方案时，可以沿每条业务路径反问：应用实例翻倍后，哪个依赖的总需求会同步增长；某个可用区退出后，哪个组件还剩足够容量；某个依赖超时后，谁停止继续施压。回答这些问题，往往比增加更多应用节点更能改善稳定性。复杂的复制协议和事务恢复机制可以后学，依赖清单、容量预算与故障动作现在就应该写完整。
7 案例：热点 Key 打满缓存分片
活动开始后，用户集中查看某个热门商品的展示状态。订单 API 总请求量仍为每秒 12000，应用整体 CPU 未达到预警线，但查询 p95 升高，创建订单也开始变慢。值班人员先检查总缓存命中率，发现仍接近原有水平，于是怀疑应用实例不足。这个判断忽略了请求分布：缓存能命中，不代表每个分片都能及时完成请求。
按分片展开指标后，发现 16 个分片中的某个分片每秒承受超过 6000 次访问，而其压测安全能力只有每秒 1500 次；其他分片还有较多余量。进一步按经过脱敏的 Key 标识聚合，确认大部分访问来自热门商品展示键。这个键用于公开展示信息，允许最多 3 秒陈旧；个人订单键和创建幂等记录使用独立类别，不能跟随展示信息的策略一起调整。
故障链由此清楚：热点请求集中到单个分片，分片等待增加，应用等待缓存响应；部分请求超时后直接回源，数据库负载上升；数据库连接又与订单创建共享，最终查询问题扩散到创建路径。根因是局部访问集中与保护不足，表象却出现在多个组件。若此时扩容应用，更多连接可能让等待和回源更严重，无法修复热点分布。
应急动作先控制扩散。对热点公开查询设置独立并发与回源上限，缩短无效等待；在已验证的范围内启用带有效期的本地副本，并合并同一数据的并发刷新。优先保留订单创建所需的数据库预算。若缓存整体不可用，在每秒 3200 个等效单位的目标内，先为每秒 2400 次创建预留容量，再将需要回源的查询控制在每秒 800 次以内。实际是否能完成创建，还取决于库存等依赖是否健康。
这种优先级不意味着无条件接收所有创建。达到创建预算时，同样要明确限流；结果不明确的请求继续按幂等标识查询。对允许陈旧的展示信息，返回副本时标注更新时间，超过 3 秒上限就停止使用该副本，转为受限刷新或明确暂不可用。不能让临时缓存无限续期，否则系统虽然响应很快，展示内容却已经偏离业务承诺。
恢复后再做长期调整。可选择热点本地缓存、只读副本分散或业务数据重组，但每个选项都要分析失效和更新成本。单纯增加缓存分片可能改善总体分布，却未必分散同一个 Key。先用受控流量验证热点比例、刷新数量和副本陈旧时间，再逐步放量。恢复原来的命中率只是观察点，还要确认数据库等待下降、创建成功率恢复、主动拒绝量回落。
复盘记录应保留触发条件、受影响业务、关键时间线、保护动作和剩余风险。新的 ADR 可以注明：公开展示热点采用短时本地副本，接受有限陈旧以隔离依赖压力；订单状态继续使用独立规则。完成改造后重演同样的热点分布，验证它不再通过回源挤占创建预算。这样，案例就从“缓存慢了”变成可复用的容量与隔离经验。
8 把互联网流量假设写进方案
流量假设不是在首页写一句“支持高并发”，而是描述可检验的输入。订单 API 的每秒 12000 个峰值请求，要同时带上持续 15 分钟、查询占 80%、创建占 20%、访问集中程度和客户端重试行为。还要说明统计位置：本课指到达业务入口的请求，公开图片另计。若业务预测给的是活跃用户数，必须结合用户操作频率与页面调用数量推导，不能直接当成请求速率。
平均负载与短时突发要分开描述。每分钟平均相同的请求量，可以是持续均匀到达，也可以集中在几秒内；二者对排队与准备容量的要求不同。写方案时给出预测范围、增长速度和测量窗口。请求体大小、响应体大小和慢客户端比例也可能影响入口连接与带宽。本课不展开复杂排队模型，但应让评审者知道哪些因素已经纳入测试，哪些仍待验证。
数据分布同样属于假设。除了总命中率，应注明是否存在每秒 6000 次访问的热点 Key，热门对象是否能接受短时陈旧，是否有大量首次查询造成冷缓存。缓存预热只能覆盖已知对象，不能保证所有新订单都已缓存。对本课案例，创建请求比例直接决定数据库和库存的最低需求，不能依靠提高公开内容命中率来掩盖写入容量不足。
把每个关键假设连接到验证证据。流量预测对应业务活动计划和历史曲线，实例安全容量对应相同接口组合的压测，命中率对应分接口与分片统计，故障能力对应可用区演练。证据还应带日期、环境和版本，因为容量会随程序、数据规模和索引变化。没有证据的数字可以作为待验证假设存在，但应明确它尚不能支撑正式承诺。
风险表应体现触发条件与动作。例如预测峰值高于每秒 12000 时重新评估应用余量；命中率下降使数据库等效负载接近每秒 3200 时启动保护；热点分片接近安全预算时启用热点策略；库存响应持续变慢时限制创建并提示明确状态。每项动作应指定负责人、观测指标和恢复条件，避免只有“加强监控”“及时扩容”这类无法执行的描述。
高可用部分再单列故障矩阵。应用可用区退出、缓存分片失效、数据库切换、库存超时分别影响不同路径，需要不同演练。恢复时间目标描述多久恢复业务，数据恢复点目标描述最多允许丢失多长时间的数据；对已确认订单，目标应是不能静默丢失，实际能力要由持久化与切换机制支持。跨可用区部署主要处理区域内部故障，不能自然覆盖整个区域不可用。
最后把选择、成本和风险连起来。若为了节省费用减少常驻实例，就要明确突然增长时可接受多少拒绝；若为了体验增加热点副本，就要承担数据失效管理；若要求某个可用区退出后仍承接峰值，就要保留剩余容量。方案不是把这些矛盾消除，而是让选择可见、承诺有依据、超出边界时有动作。评审可以据此讨论是否调整需求，而不是争论哪个组件名字更先进。
9 从互联网行业方案走向电商与大促方案（P23）
到这里，互联网行业方案已经形成闭环：先描述订单 API 的访问与体验要求，再区分公开内容和业务路径，安排弹性与热点保护，用压测和故障证据校正容量，最后用 ADR、成本表和风险表留下选择依据。这个框架适合公开访问入口较多的业务，但并不意味着只要入口稳定，交易业务就已经完成。用户能够快速访问，与用户能够正确完成购买，是需要分别证明的结果。
进入电商与大促场景后，订单创建占比可能突然变化，流量会集中到少数商品，库存预留与支付结果也会成为核心约束。本课每秒 2400 次创建只是当前输入，不是后续章节永远适用的定值。若查询占比下降而创建占比上升，即使总请求量仍为每秒 12000，依赖工作量也会增加。后续调整必须更新假设表和容量预算，不能沿用旧压测结论。
订单案例的业务语义则保持一致：用户发起某次创建意图，系统以幂等标识识别重试，成功意味着达到已约定的持久化和库存预留条件，结果不明确时可以继续查询。接入队列、增加缓存或分拆服务，都不能改变这些状态的含义。P23 将在这个基础上继续讨论库存约束、活动节奏、交易链路保护，以及如何在大量同时下单时给出清楚的处理结果。
带入后续课程的材料应包括当前入口图、读写比例、热点分布、正常与故障容量、ADR 和未解决风险。尤其要保留“数据库等效工作单位”的简化说明，避免将教学公式直接当作真实事务成本。库存调用目前只有接口预算与超时边界，后续还需要结合库存数据和业务流程验证。承认这部分尚未展开，有助于保持每章的讨论范围清晰。
可以用 3 个问题检查自己是否掌握本课：图片命中率升高为什么不能证明订单写入有余量；总缓存容量足够为什么还会出现热点故障；应用可用区演练通过为什么不能替代数据库切换演练。回答时应指出具体路径、容量单位和证据，而不是只说“存在瓶颈”。能沿着同一个订单请求说明这些关系，就具备进入电商与大促方案练习的基础。
放进方案里
本方案面向零售订单 API，覆盖订单查询与创建入口，公开图片和活动内容通过内容分发路径提供。业务入口平时每秒接收 3000 个请求，预计峰值每秒 12000 个，持续 15 分钟，查询与创建分别占 80% 和 20%。正常峰值的查询 p95 目标为 200 毫秒，创建 p95 目标为 500 毫秒；主动限流、业务拒绝与服务错误分别统计。个人订单执行身份和归属校验，创建采用幂等标识，结果不明时提供订单查询。
应用平时在 3 个可用区部署 6 个实例，活动前提前 5 分钟扩至 18 个。每实例安全容量暂按每秒 1000 个请求计算，单个可用区退出后剩余容量覆盖预计峰值。该结论待同业务组合压测及可用区演练确认。ADR 选择预扩容与自动扩容结合，接受基础余量成本，并记录资源准备约 120 秒的约束；活动不可预测时重新评估常驻容量。
查询缓存命中率按 95% 估算，峰值数据库需求约每秒 2880 个等效工作单位，安全预算为 4000，保护预警线为 3200，实际读写权重待压测校正。热点公开信息允许最多 3 秒陈旧，采用受控副本与合并刷新；个人订单按独立隔离和时效规则处理。缓存异常时限制回源，优先保留创建预算，超过容量则明确限流，禁止把未确认结果返回为成功。
成本按应用资源小时、内容传输、入口、缓存、数据库、日志及跨区通信核算，并同时报告成功订单量。风险覆盖突发流量、热点分片、缓存回源、数据库切换与库存超时，各项列明负责人和恢复条件。上线前提交入口路径记录、容量报告、幂等核对与故障演练结果；达不到承诺时调整保护参数或业务目标，再进入评审。
10 小结：下一步电商与大促方案（P23）
互联网行业方案把流量假设、访问路径、依赖容量和用户体验连接起来。内容分发减少公开内容回源，弹性伸缩增加应用能力，热点保护与依赖预算限制故障扩散；这些能力要通过相同业务组合的证据共同验证。
下一步进入 P23，继续使用零售订单 API，把注意力推进到集中下单、库存约束与交易结果。保留本课的幂等语义、容量口径和决策记录，按新的业务假设更新方案。