1 音视频与游戏方案要回答什么
零售订单 API 已经能够查询商品、创建订单和返回支付状态。现在业务希望加入直播讲解、买卖双方语音咨询，以及促销期间的多人互动小游戏。用户可以边看直播边下单，也可以在小游戏结束后领取优惠券。这些功能共用用户身份，却有不同的时间要求。订单晚返回时仍须防止重复扣款；直播中的旧画面即使完整到达，也可能已经失去观看价值。方案首先要说明哪些信息必须正确保存，哪些信息必须及时到达。
把需求拆成体验目标，比直接选择传输协议更有用。直播要问观众能接受多长的观看延迟、切入直播需要多久、低网速时是否允许降低清晰度；语音咨询要问双方能否自然接话、断线后是否能够重连；游戏要问玩家规模、动作频率、胜负由谁裁定。这里的“实时”不是统一指标。商品展示允许较长缓冲，双向交谈通常更在意延迟，竞技动作则更在意状态的新鲜度和不同玩家之间的公平性。
本课使用同 1 个零售案例：已有订单 API，新增商品直播、客服连麦和促销互动房间。示例假设高峰有 3000 名直播观众、200 路同时上行的视频，以及 100 个互动房间，每个房间最多 8 名玩家。数字只用于练习估算，不代表容量承诺。正式方案还需要明确观看时长、地域分布、终端能力、网络条件和增长窗口，否则“支持高峰”没有可以检查的边界。
架构中先分清控制面与数据面。控制面处理登录、加入房间、分配媒体节点和权限；数据面传送连续的声音、画面或游戏状态。订单 API 继续承担价格确认、库存校验、订单幂等和支付结果处理。媒体服务可以展示订单状态，却不能把某个画面出现过“支付成功”当成交易依据。游戏发放优惠券也应经过可信的业务接口，使用可追踪的领取标识防止重复领取。
候选方案要围绕不同用途展开。大规模商品直播可以优先考虑带缓冲的分发路径；客服连麦可以考虑交互式实时传输；小游戏先采用房间服务器维护权威状态。它们可以组合存在，无须为了统一技术栈而共享所有链路。评审时重点比较体验、故障影响、建设成本与运维难度，而不是比较协议名称的数量。
还要提前记录失效时的体验。直播暂时卡住时，商品详情和订单按钮是否还能使用；连麦失败时是否退回文字咨询；游戏房间不可用时是否暂停该轮活动。降级要让用户知道当前发生了什么，并保留交易结果的可信来源。这些约定会直接影响服务依赖、页面交互与验收方式，是媒体方案的组成部分。
2 实时传输、缓冲与编码边界
摄像头采集的画面不会原样经过网络。终端先把画面编码成适合传输的数据，再分包发送；接收端收包、暂存、解码，最后交给屏幕呈现。声音也有相似路径。编码降低了带宽需求，却引入处理时间，并使部分画面依赖此前的信息。入门阶段先掌握这些边界，不必深入编码器内部的预测算法。出现卡顿时，要能分清数据没到、数据不能解码，还是已经解码却没有及时显示。
端到端延迟可以拆为采集、编码、发送排队、网络传送、接收缓冲、解码与显示等待。多个环节可能流水处理，测量时应围绕同 1 段内容的时间线，避免把不同片段的耗时机械相加。示例预算可以给采集与编码 60 ms、网络与发送排队 90 ms、接收缓冲 80 ms、解码显示 40 ms，总计 270 ms。这只是目标分配，测量结果仍可能因为设备过热或无线网络波动而超过预算。
缓冲是在“等完整”和“赶时间”之间做选择。接收端稍等片刻，可以把乱序到达的数据重新整理，也能吸收短暂的到达时间波动；等待越久，播放通常越稳定，交谈中的接话却越不自然。抖动指到达时间的变化，不等同于固定的网络延迟。稳定但较慢的链路与时快时慢的链路，需要不同的处理方式。只看平均带宽，无法决定应保留多大的缓冲。
关键帧提供重新开始解码的重要参考，其他帧可能依赖已经解码的画面。关键帧丢失时，即使后续数据仍在到达，也可能暂时得不到可用画面。关键帧通常比普通帧更大，生成过于频繁会抬高码率与瞬时负载；间隔过长又可能拉长入会与错误恢复时间。方案需要同时记录恢复目标和带宽代价，不能只写“提高关键帧频率解决卡顿”。
传输方式也有不同取舍。交互媒体通常重视按时交付，过时的数据可以丢弃；文件与订单事件通常更在意可靠到达。WebRTC 是适合讨论交互音视频的公开技术体系，HTTP 分段分发则常用于带缓冲的视频观看。不能简单把前者理解成永不重传，或把后者理解成必然无法低延迟。具体实现会组合反馈、恢复与缓冲策略，方案应说明选择依据与适用场景。
媒体加密、用户鉴权和房间权限同样需要划清边界。登录成功不代表可以收看任意直播，也不代表可以向任意房间发布声音。加入凭证应限定房间、角色和有效期，服务端检查发布与订阅权限。网络路径还可能包含中继，中继既影响费用也影响延迟。这里先在路径图中把这些节点标出，具体协商协议和加密细节留给后续专题。
3 匹配、房间与状态同步
直播观众、语音参与者和游戏玩家都可能使用“房间”，但房间承担的职责不同。直播房间主要管理发布者、订阅者和权限；语音房间还要维护发言身份与成员变化；游戏房间必须维护一局活动的状态和结果。把房间理解成有生命周期的业务对象，可以避免只按连接数量建模，却遗漏开始、结束、退出、超时和重连等状态。
匹配的输出是允许进入某个房间的资格，而不是最终建立好的通信链路。对于零售促销小游戏，初期可以按活动、地域和房间余量分组，不必直接采用复杂的竞技评分模型。匹配服务应返回房间标识、连接入口和短期凭证，并限制同 1 名用户重复占用席位。等待过久时，要明确继续等待、加入较远地域的房间，还是退出匹配；这些选项需要产品规则支持。
游戏状态先采用服务器权威模型：客户端上报操作，房间服务器检查规则并更新状态，再将结果发给玩家。客户端显示“已点击”可以很快，是否命中和是否获胜仍由服务器决定。这样能把优惠券发放关联到可信结果。不能直接相信客户端提交的分数，也不能让客户端通过修改本地时钟延长活动时间。活动结果进入订单相关业务时，还要使用幂等标识防止重复处理。
状态同步需要区分完整快照与增量更新。快照包含恢复界面所需的当前状态，增量只描述变化，通常更节约带宽。增量带有序号和对应版本，客户端发现缺口后可以请求新快照。断线重连不能盲目回放所有旧操作，否则玩家可能重新触发已结束的领取动作。对于本课的简单促销玩法，优先保证当前状态可恢复，复杂预测与回滚机制暂不展开。
连接身份也不能直接等于玩家身份。手机切换网络后可能建立新连接，旧连接尚未完全关闭；房间要知道哪个会话可以继续提交操作，以及何时回收旧会话。需要限制操作频率，对重复操作返回一致结果，并在房间结束后拒绝迟到操作。跨节点恢复时，旧节点失联不代表它已经停止工作，应通过所有权版本等机制拒绝旧实例继续提交结果。
房间有状态，因此扩容与故障切换要区别于普通订单 API 的无状态副本扩容。新增节点通常先接收新房间，已有房间能否迁移取决于状态保存与连接恢复设计。初期可以选择故障后结束当前小游戏、保留可核对的已确认结果，再安排下一轮；如果业务要求中途无感恢复，就必须增加状态复制、恢复验证和费用预算。高可用承诺应写明恢复范围，避免把“节点有副本”当成“对局没有中断”。
4 动手：画一条音视频上行路径
现在为客服连麦画图。起点是顾客手机的麦克风与摄像头，终点是客服终端播放。先把身份与媒体分开画：手机调用业务接口获取房间权限，通过信令交换建立连接所需的信息，再把媒体发送给适合该会话的媒体节点。信令负责协商与控制，不应被误画成承载全部音视频内容的订单 API。图上应让评审者看出哪些请求是短请求，哪些连接会持续占用资源。
在路径上依次填写采集、编码、终端发送队列、公网接入、媒体转发、客服接收缓冲、解码与呈现。直连与中继路径可能不同，练习时明确采用经过媒体转发节点的路径，并把中继作为网络受限时的候选路径。不要默认所有用户都能走同 1 条最短路线。路径变化应反映到连接建立耗时、往返时间与转发费用中。
给每个边界标注可以观察的事件。终端记录开始采集与首个有效画面，业务服务记录凭证签发与加入结果，媒体节点记录收到上行与开始转发，客服端记录收到数据与首次呈现。事件应关联会话、房间、流和角色；订单号只在确有业务关联的事件中使用。日志不需要保存媒体内容，排障优先使用时序、计数、错误原因与必要的设备网络信息。
时间测量需要说明时钟来源。同 1 个终端内的阶段耗时可使用单调时钟；不同机器的时间戳直接相减会受到时钟偏差影响。应用层探测、经过校准的时间戳或拍摄可识别时间标记，都可以作为测量手段，但精度和适用范围要写清。网络往返时间除以 2 只能作近似推断，路径不对称时不能把它当成真实单向延迟。
接着模拟 3 类条件：正常网络、短暂带宽下降、连续丢包。每类都记录加入耗时、端到端呈现延迟、音频中断、视频冻结和恢复时间，再观察订单 API 是否仍可操作。练习不是追求某个漂亮数字，而是检查图上的每段是否有证据，以及媒体异常是否会拖累交易。测试涉及弱网时，应使用受控测试环境和测试账号，防止把生产顾客当成实验流量。
最后将路径图转成责任清单。终端团队负责采集和播放指标，媒体团队负责转发与恢复策略，业务团队负责权限与订单边界，运维负责容量和告警。对每个异常明确先看哪个指标、由谁判断和怎样回退。完成后，任何没有参与设计的人也应该能沿着图解释“声音正常但画面不动”会经过哪些检查点。
5 延迟与画质取舍
画质由分辨率、帧率、编码策略和可用码率共同影响。提高分辨率但不给足码率，画面可能只是更大的模糊块；提高帧率会增加处理与传输压力，在较弱终端上还可能让编码耗时上升。选择档位要围绕内容：商品细节展示更在意静态清晰度，快速互动更在意动作连续性，语音咨询则需要先保证声音可以理解。没有适用于全部业务的最高画质配置。
先用简单模型理解排队。如果编码输出长期高于链路实际可用吞吐，发送队列就会增长，画面逐渐变旧。假设持续输出 3 Mbps，而可用吞吐只有 2 Mbps，忽略协议开销和反馈调整，每经过 1 s 就可能多积压约 1 Mb 数据。此时增加接收缓冲不能消除上游积压。应考虑降低码率、减少视频负担，或丢弃已经失去时效价值的数据。
交互中的数值是教学模型，不是生产推荐值。调大缓冲，可以在模型里吸收更多到达抖动，却会直接增加播放等待；提高码率，如果超过可用吞吐，会在观察窗口内形成额外队列。实际系统还受到拥塞反馈、编码器变化、瞬时关键帧和协议开销影响，因此不能凭滑块结果制定承诺。它的作用是帮助解释取舍方向，并发现“带宽不足时继续加画质”的矛盾。
媒体节点也有资源边界。简单转发主要消耗网络与连接资源，转码或混流还可能消耗大量计算。方案必须说明选的是哪种处理模式，不能把转发节点的压测结果用于推算转码容量。多档直播可以由上行端产生多个档位，也可以在服务端生成，前者增加上行与终端负担，后者增加服务端处理。对初期零售业务，先验证终端能力与观看需求，再决定建设范围。
费用估算从“谁向谁发送多少数据”开始。3000 名观众按平均 1.5 Mbps 观看 1 h，观众侧有效视频数据约为 2025 GB，采用十进制单位，尚未计入音频、封装、重传和其他流量。这个数不等于自建源站必然承担的流量，也不等于账单金额，缓存分发和计费边界会改变结算方式。应分别列出上行、分发出口、跨地域、中继、计算、存储和监控费用。
保留录像还要增加保存期限、访问权限和删除机制。只为故障排查时，不一定需要长期保存全部媒体内容；可以先利用质量指标与抽样诊断信息。成本表应同时列出基准、峰值和异常恢复场景，尤其关注大规模重连造成的瞬时连接与关键帧负载。预算不足时先缩小非核心功能的范围，并清楚记录体验变化，避免让交易链路承担媒体成本失控的后果。
6 常见坑：把平均延迟当尾延迟
平均延迟把所有样本压缩成 1 个数，可能掩盖少数用户长时间等待的事实。假设 100 次测量中，95 次为 200 ms，5 次为 4000 ms，平均值为 390 ms。平均值看起来仍在较低范围，但受影响的用户已经无法正常交谈。P95、P99 等分位数帮助描述分布尾部，不过不同统计实现的分位数算法可能有差异，评审中要统一口径。
尾延迟不只来自网络。关键帧等待、设备过热、应用切到后台、垃圾回收暂停、跨地域绕路和媒体节点排队都可能让少部分会话异常。先按地域、设备、网络类型、版本与媒体路径划分，再观察分位数，往往比只看全站曲线更有帮助。聚合时还要区分每帧样本与每会话样本：高帧率的长会话可能贡献大量正常样本，掩盖少量完全无法加入的用户。
失败会话不能从统计中消失。如果只计算成功播放用户的首帧时间，完全没有画面的会话就被排除，结果反而显得更好。应同时报告加入成功率、首帧时间分布、超时比例与测量覆盖率。对已经播放的会话，再统计冻结时长占比、音频中断和恢复时间。尚未发生的首帧不能简单记为 0，也不能为了绘图方便给所有超时填入同 1 个正常值。
监控窗口也会影响结论。按 1 h 聚合可能看不见持续 30 s 的断流，而过短窗口又可能因为样本太少出现剧烈跳动。方案应写出采样对象、统计周期、最小样本量和告警持续条件。不要把每分钟的 P99 再取平均并称为全天 P99；应使用原始样本或可合并的分布统计。小样本群体可以报告具体失败数与现象，避免制造精确但没有意义的分位数。
告警要联系用户体验和服务负载。例如某地域首帧超时增加，同时关键帧请求与出口队列上升，就需要检查恢复放大；如果网络指标正常而低端设备解码耗时增加，则优先检查编码档位与客户端版本。单个丢包率阈值不足以判定体验，因为恢复机制、声音与画面的敏感度并不相同。指标要能引出行动，不能只用于展示曲线。
零售场景还应单独观察订单 API 的成功率、尾延迟、依赖超时和连接池压力。媒体故障发生时，订单数据仍然正确只是底线，用户也必须能够查到可信状态。演练中需要核对“视频冻结但订单成功”的页面提示，以及重复点击是否仍满足幂等规则。把交易与媒体分开统计，才能判断降级是否真正保住了核心购买流程。
7 案例：关键帧丢失导致卡顿雪崩
某次商品直播活动开始后，部分观众出现画面冻结，声音仍然持续。最初只有少量弱网用户受影响，随后同 1 个媒体节点上的更多观众也开始卡顿。订单 API 的请求延迟没有明显变化。这个现象不能直接证明根因是关键帧，因为解码器异常或档位切换也可能有类似表现；排查先保存会话时间线、节点负载和版本信息，避免在没有证据时反复重启。
时间线显示，发布端刚产生较大的关键帧时，上行出现突发丢包，节点转发的这一段画面不完整。部分观众无法继续解码，开始请求刷新关键帧。实现中缺少请求合并与频率限制，大量请求同时传到发布端，发布端连续生成关键帧，瞬时码率明显提高。发送队列随后增长，更多数据迟到或丢失，又引出更多刷新请求，形成恢复动作放大故障的反馈循环。
确认这个解释需要多段证据相互对应。先看到上行丢包与首批冻结，再看到请求频率与关键帧生成次数上升，最后看到队列和更广泛的冻结增长。还要检查带宽容量、发送端编码耗时与节点出口，排除只是观众增加导致容量不足。能够复现同样的先后关系，并在加入请求合并后明显减轻放大，才足以支持改动方向，相关性本身不能替代验证。
短期缓解先控制放大源。按流合并刷新请求，设置合理的最小间隔，避免每名观众独立触发同等昂贵的恢复动作；同时降低视频档位，控制重连速率，优先保住声音。对不能恢复的会话给出明确提示与受控重试入口。任何限流都可能延长个别用户等待，因此需要观察恢复时间分布，不能只因为服务器负载下降就宣布体验恢复。
长期修复还包括给发送队列设置时效边界、验证弱网下的编码调整，以及检查新观众进入时是否集中请求关键帧。已有缓存的关键帧也不一定可以直接交给任意新观众，它必须与后续数据和当前编码配置匹配。入门方案只需写清这些约束与验证责任，不必实现完整媒体缓存协议。关键原则是恢复机制必须有容量预算、合并边界和可观测结果。
恢复后先让少量会话使用新策略，再逐步扩大范围，比较同类网络条件下的冻结、首帧和恢复指标。复盘应记录触发条件、扩大因素、有效缓解、未解决风险及负责人。订单链路虽然这次未受影响，仍需检查共享出口、鉴权与日志系统是否存在下一次被拖累的可能，并通过隔离与配额验证边界。
8 把实时性目标写进媒体方案
方案中的目标应包含对象、口径、条件和观察窗口。例如在约定地域、支持设备及指定网络测试条件下，客服连麦加入成功率达到 99.5%，已成功加入会话的首帧时间 P95 不超过 2 s，双向音视频呈现延迟 P95 不超过 400 ms。这里的值是练习目标，需要通过实测确认可行性。超时会话另报比例，不能因为首帧指标限定成功会话就忽略失败用户。
直播与游戏应使用各自的目标。商品直播可以记录起播、稳定观看延迟、冻结占比与档位分布；游戏记录匹配等待、操作到权威结果的延迟、状态版本落后程度与重连成功率。媒体服务可用不意味着优惠券业务成功，游戏结果还需与可信发放记录对账。目标表旁边应写出用户受影响时的降级行为，以及由谁决定暂停活动或切换方案。
架构决策记录 ADR 要写出背景、候选项、决定、理由与代价。示例决定是：商品直播采用可扩展的分发路径，客服连麦采用交互媒体路径，促销游戏采用权威房间服务器；交易继续通过订单 API。理由包括观看规模、双向交互需求和奖励可信性。代价则是需要管理多类连接与监控，并维护从实时展示到交易结果之间的业务关联。
高可用按故障域逐项说明。无状态的鉴权与分配服务可以部署多个副本；媒体节点故障需要客户端重新连接和重新获得可解码画面；房间节点故障则依赖状态恢复或明确结束当前活动。节点失效后可能丢失尚未确认的实时动作，即使采用持久化也应定义确认边界。用恢复时间目标和允许丢失的状态范围描述承诺，比笼统写“自动切换”更可验收。
容量表至少包含并发观看、上行数量、房间数量、平均与峰值码率、节点安全水位和故障预留。3000 名观众与 200 路上行不应简单相加成同一种连接负载，转发关系决定出口规模。故障预留也不能只看集群平均利用率，需要验证失去某个节点或可用区后，剩余资源是否能接住重连高峰。资源充足仍须测试分配、凭证与依赖服务的瞬时压力。
风险清单要把现象、影响、缓解和验证对应起来。带宽抖动对应自适应与队列边界，关键帧风暴对应合并与限流，房间分裂对应所有权校验，奖励重复对应幂等发放，权限泄漏对应短期凭证与撤销策略。每项都应有负责人和检查方法。这里只要求能够解释机制和验证方向，复杂拥塞控制、全球调度与分布式一致性的内部实现留给后续课程。
9 从音视频与游戏方案走向训练技巧（A21）
这次练习留下的核心产物不是协议清单，而是可以反复推演的方案证据：需求表、路径图、延迟预算、状态边界、ADR、费用模型和故障时间线。进入训练技巧（A21）时，可以用这些材料练习如何在有限时间内提出假设、寻找证据和修订决定。每轮只改变明确的条件，才知道方案为什么改善，哪些结论仍受当前样本限制。
第 1 轮训练只解释正常路径。用简短语言说清顾客如何进入直播、如何与客服连麦、如何在游戏结束后领取优惠券，以及订单 API 在哪里确认交易。听者应能沿图追踪每个动作，并指出哪个服务有权给出最终结果。解释中如果出现“系统自动处理”，就继续补全处理者、输入、输出和失败返回，直到责任边界能够落到具体节点。
第 2 轮训练加入单个故障条件，例如可用吞吐下降、媒体节点退出或房间连接中断。先预测用户会看到什么，再列出可以支持或推翻预测的指标，最后设计受控实验。不要同时改码率、缓冲、路由和关键帧间隔，否则即使结果改善，也很难归因。每轮记录起始配置、变更、环境与结果，使下一名同学能够复现同样的问题。
第 3 轮训练约束成本与可用性。保持 3000 名观众、200 路上行、100 个房间和每房间最多 8 名玩家的基准条件，分别讨论观看时长增加、弱网用户增多和某个故障域不可用。允许调整方案，但要同步修改费用、容量和体验承诺。不能在成本页假设低码率，在体验页假设最高画质，又在高可用页假设所有备用资源免费。
同伴评审可以围绕具体追问展开：首帧超时是否计入失败；声画不同步如何发现；关键帧请求如何避免放大；旧房间节点为什么不能继续发奖；媒体中断时订单结果从哪里查询。回答不足时，回到图、事件和业务规则补充证据。对于尚未测量的结论，写成待验证假设，并说明测量计划，避免把期望表现当成已经具备的能力。
训练还要保留停止条件。候选方案已经满足入门目标、风险有明确处理路径、预算覆盖峰值且核心交易边界清楚时，就应形成当前版本的决定。不是每个问题都需要追加高级机制。后续训练可以研究预测补偿、精细拥塞控制和跨地域恢复，但应先带着本课暴露的具体问题进入，而不是为使用某项技术寻找场景。
放进方案里
本零售方案保留订单 API 作为交易事实入口，新增商品直播、客服连麦和促销游戏。基准容量为 3000 名直播观众、200 路同时上行视频、100 个游戏房间，每房间最多 8 名玩家。身份服务签发限定房间与角色的短期凭证；媒体连接与订单请求分别设置资源配额，防止直播异常占满交易入口。
ADR 选择商品直播使用带缓冲的分发路径、客服连麦使用交互媒体路径、游戏使用服务器权威房间。直播侧重观看稳定性，连麦侧重接话延迟，游戏奖励以服务端结果为准，并通过幂等接口发放优惠券。候选路径的理由、额外运维负担和终端兼容条件随决定共同保存。
练习验收目标为：约定测试条件下连麦加入成功率达到 99.5%，成功会话首帧 P95 不超过 2 s，呈现延迟 P95 不超过 400 ms；超时比例、视频冻结与恢复时间另行报告。按地域、网络和设备分组验证，指标必须写明窗口、样本与时钟口径，正式承诺以试点测量结果为依据。声画同步使用同源拍手测试片段，核对接收端拍手画面与声音的时间差；验收前约定允许偏差，保留弱网恢复和档位切换前后的测量记录，避免单独达标的音频、视频延迟掩盖不同步。
成本按观看时长、实际分发码率、中继占比、计算模式和录像保留期估算，并覆盖峰值与恢复流量。3000 名观众以平均 1.5 Mbps 观看 1 h，对应约 2025 GB 有效视频数据，另计协议等开销，再按具体计费边界换算费用。
风险控制包括关键帧请求合并、队列时效限制、重连限速和房间所有权校验。鉴权与分配服务跨故障域部署，媒体故障通过重连恢复；房间故障按已确认状态恢复或结束本轮活动。演练同时核对订单幂等、奖励记录与页面提示，证明降级时顾客仍能查到可信交易结果。
10 小结：下一步训练技巧（A21）
音视频与游戏方案需要同时回答及时性、状态可信度和资源边界。缓冲、码率、关键帧与恢复动作都可能改变尾延迟；媒体恢复与房间恢复也有不同的状态要求。订单 API 继续承担交易事实，实时界面围绕可信结果提供交互体验。
进入 A21 前，先用自己的路径图解释 3 件事：为什么加缓冲可能让连麦更难接话，为什么数据仍在到达却没有画面，为什么房间重连成功不代表奖励可以再次发放。能够给出对应证据与验收方法，再进行下一轮方案训练。