容量估算、可观测性、灰度与容灾：把设计变成可检查的预算
6000 任务/秒 × 0.5 秒 → 稳态在途 3000——设计从工作负载推导预算，而不是从机器数量倒推。容量与排队的通用方法见工作负载的形状；SLO 与告警语义见SLI、SLO 与预算与从遥测语义到可操作告警；恢复目标见故障域、RTORPO 和切换。本页把它们组装成一个综合设计算例。
所有输入均为教学假设。容量计算用于暴露瓶颈，不代替在指定硬件、版本和故障条件下的压测。时间、请求、容量与成本必须使用匹配的窗口。
从工作负载而不是机器数量开始
假设接入峰值2000个内容/秒，每个扇出3个模型任务；每个模型任务平均等待0.5秒、本地CPU消耗5ms；每内容写入2KiB元数据；P99接收响应目标200ms，异步审核99%在30秒内完成。接收接口和异步完成是两个不同SLI，不能把HTTP 202成功率当作业务完成率。
平均、峰值、突发持续时间、payload分布、热点键、重试与后台回填都要单独记录。一个持续5分钟的峰值与一个100ms突发需要不同队列；使用恒定到达率压测容易遗漏协调遗漏：系统慢时客户端也慢，观测到的负载反而下降。应声明开环/闭环发生器、超时统计和丢弃请求的计数方式。
算一遍正常容量
模型任务到达率6000/秒，平均外部等待0.5秒，稳态外部在途约3000。这个估算使用L=λW，需有稳定边界和匹配统计；不能将P99耗时直接代入当作平均并发，更不能由平均并发推导尾延迟。
本地CPU需求约6000×0.005=30核秒/秒。目标CPU利用率60%，等价CPU容量约50核；若每实例4核，至少13个实例。该结果尚未包含网络解析、GC、调度、突发和故障余量，必须用真实CPU profile与压测确认模型。
元数据写入约2000×2KiB=3.91MiB/秒，全天若持续则约329.6GiB；峰值并不代表全天负载，应另用日工作量求日存储。复制、索引、binlog、备份与重试另计。网络容量要区分单副本入口与跨节点复制，附件不能按元数据大小估算。
单可用区失效与队列预算
三可用区均匀部署13个实例，失去最大一区5个后只余8个；按每实例2.4核可用CPU只有19.2核，小于30核需求。不能把“跨三区部署”直接写成可承受任一区故障。若要求失一区仍承载峰值，需重新求N减去最大区数量后的能力，并考虑故障时缓存未热与连接重建。
假设故障期间总处理能力降到4000任务/秒，仍进6000/秒，持续180秒，积压36万。恢复后处理8000/秒，在线到达6000/秒，理想净清理能力2000/秒，需180秒。若任务期限30秒，积压即使最终清完也已违反SLO，应入口降载、跳过可选模型、优先处理仍有效任务，不能只报告“无丢消息”。
队列上限与内存：若排队对象平均2KiB，36万约703MiB逻辑payload，尚未含对象头、索引与复制。队列必须有容量、TTL、优先级与拒绝语义。拒绝新请求、延迟接受和降级各会改变业务保证，需要明确对用户可见的结果。
延迟预算与测量
接收200ms预算可先分为鉴权20、业务与序列化20、数据库80、网络30、排队及余量50ms，这是初始设计假设，不是这些组件的P99相加后必等于端到端P99。并发分支依完成条件取最大或部分结果，跨阶段相关性会放大尾部。
指标至少分接入成功率/延迟、审核期限违约率、最老有效任务年龄、UNKNOWN数量与年龄、数据库锁等待、模型拒绝与剩余额度。直方图应按桶累计合并，不能平均实例P99；标签不含content_id、user_id等无界维度。用户相关SLI的定义可对照Google SRE服务目标；这里的具体窗口和预算是本题自定设计。
错误预算与可操作告警
假设30天有1亿次有效提交，目标99.9%及时完成，允许违约10万次。若5分钟有10万次提交且违约1万，局部错误率10%，相对0.1%目标的消耗速度为100倍。短窗口用于发现急性问题，长窗口确认持续消耗；低流量时需最小事件数或业务计数防噪声。
多窗口告警应绑定具体动作：模型限流时停止重试、切可选降级；主库锁等待时先看热点与事务，不盲目扩worker。参考Google SRE基于SLO告警，阈值应由本系统预算与响应时间推导，而不是照搬书中的数字。告警消息给业务影响、起始时间、相关变更、操作入口和责任角色。
灰度与回滚协议
先定义灰度单元：按租户、内容ID稳定分桶或小区流量，保证同一逻辑流程的版本兼容。灰度前验证schema、消息字段和消费者兼容；发布二进制不代表旧worker和旧任务立即消失。
准备兼容读写与观测基线
→ 影子计算，不执行正式副作用
→ 1%受控业务灰度
→ 对比相同口径的错误、延迟、正确性与成本
→ 逐级放量，每级有停留和退出条件
→ 保持回滚窗口，最后清理旧字段与旧路径总体平均延迟变好可能只是灰度流量更轻，应按租户和任务类型对照。回滚触发不仅看HTTP错误，还看业务不变量、UNKNOWN与期限违约。代码回滚不撤销已提交账务、已发通知和已升级数据；不可逆步骤应隔离并有前向修复方案。
RTO、RPO与恢复时间线
RTO从业务不可用开始算到服务经验证恢复，包含发现、确认、隔离旧主、恢复数据、重建连接、预热与校验；RPO描述允许丢失的时间或数据范围，不是副本台数。备份存在不能证明可恢复，恢复吞吐、日志回放和校验都占时间。
算例：1TiB有效数据以200MiB/秒恢复，理论读写阶段约87.4分钟，尚未含日志回放。若RTO目标30分钟，需更快恢复策略、热副本或缩小关键服务恢复集。不能在文档写“每天备份，RPO=0”；如果日志只每5分钟归档，还需考虑归档延迟及最后一段日志丢失。
跨区切换先拒绝旧主继续写，再提升新主；DNS缓存、连接池和客户端重试会延长真实恢复。恢复后用版本水位、关键账户/流程核对和端到端探针验证，不能以端口通了就结案。
验证产物与边界
提交负载表、单机饱和曲线、实例失效后的利用率、队列年龄、一次灰度退出记录及恢复演练时间线。若只做纸面推导，明确尚未测得单机能力；本页所有数值就是这种模型输入，不能转写为已完成压测。本页算术推导（λW=3000、30核秒/秒→13实例、失区19.2核<30、积压36万与清理180秒、恢复87.4分钟、回源2500→5000）由 python3 labs/system-design/model_check.py 的 capacity_budgets 机器核对与正文一致，实跑记录见 evidence/u78-2026-10-25.json；它核对的是推导自洽，不是压测结果。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。
架构师进阶
把预算减半、最大租户占流量40%、模型接口相关故障同时加入题设。重新选择隔离单元和降级顺序，画出一个依赖故障如何传播到队列、连接池、数据库及用户SLO；说明何时扩容有效、何时扩容只放大下游压力。