海量流量系统容量规划：从带宽QPS到接入分发与成本压测

1. 先把“海量”变成数字容量口径怎么定做容量评审最怕听到一句话我们要承载海量流量。海量是多少没人说得清。我参加过几次类似的评审会业务方说“日活过亿”架构方说“按十万级QPS设计”两边其实都没错但完全不在同一个坐标系里。真正能落到设计文档里的必须是一组带单位的数字而不是形容词。这一节不讲具体技术只讲一件事怎么把“海量流量”翻译成带宽、QPS、连接数、存储这四个可以算的指标以及为什么这四个指标的计算方式各不相同。很多人一上来就问“你们QPS多少”这个问法在短视频场景里其实是最没用的一个。1.1 四个必须算清楚的量带宽、QPS、连接数、存储先说带宽。短视频平台的最大成本项和最大瓶颈项都是带宽不是CPU也不是数据库。带宽的口径是“播放时长 × 平均码率”跟请求数没关系。一个用户刷十条视频可能是十个HTTP请求也可能是一个长连接里的十次分片拉取请求数的差别能到几十倍但消耗的带宽是恒定的。所以算容量时带宽永远优先算。我习惯用这个粗糙公式做第一版估算日均出流量 日活 × 人均日观看时长(秒) × 平均码率(bit/s) ÷ 8 均值带宽 日均出流量 × 8 ÷ 86400 峰值带宽 均值带宽 × 峰值系数短视频通常取 2.5 ~ 3.5举个例子按某类超大规模短视频产品的公开量级做一次粗算日活 6 亿人均日观看时长 1.5 小时平均码率按 1.5 Mbps 计移动端混排了 720P 和 1080P平均值会明显低于标称码率。人均观看秒数1.5 × 3600 5400 秒总观看秒数6 亿 × 5400 3.24 × 10¹² 秒日均出流量3.24 × 10¹² × 1.5 × 10⁶ ÷ 8 ≈ 6.1 × 10¹⁷ 字节约 610 PB均值带宽6.1 × 10¹⁷ × 8 ÷ 86400 ≈ 5.6 × 10¹³ bit/s约 56 Tbps峰值带宽按 3 倍系数约 170 Tbps这个数字不用太精确误差 30% 都不影响架构决策因为架构上 100 Tbps 和 170 Tbps 的解法是一样的必须靠多级分发而不是靠堆源站。但如果有人告诉你某个日活过亿的产品峰值带宽只有 20 Gbps那基本可以判断他把码率或者观看时长算错了一个数量级。再说QPS。QPS分好几类混在一起谈没有意义。我会把它们拆成API请求、视频分片请求、心跳请求、写请求。这四类在系统里的处理路径完全不同混在一个数字里做压测压出来的结论一定是假的。指标类型典型量级关系主要影响因素对应瓶颈资源API请求QPS基准1x页面刷新频率、预加载策略无状态服务、DB读视频分片QPS10x ~ 50x分片时长、拖拽行为、CDN回源率边缘节点、回源带宽长连接心跳与在线数同阶心跳间隔、连接复用率网关内存、文件描述符写请求QPS0.01x ~ 0.1x发布量、互动量消息队列、存储写入这张表最容易被忽略的是第二行视频分片请求量往往是 API 请求量的十几到几十倍。如果按 API 的 QPS 去评估 CDN 承载能力上线当天就会被打穿。连接数是另一个独立维度。短视频产品的在线连接数大致等于同时在线用户数峰值可能到日活的 15% 到 25%。六亿日活对应峰值八百万到一千五百万个长连接分布到单机上一台网关按五万连接算需要两三百台再乘以冗余系数就是实际部署量。这个数字决定了网关层能不能用常规的“无状态扩缩容”思路来做——长连接是有状态的扩容时新连接能分走老连接不会自己迁移这是个天然的不均衡问题。存储则是四个指标里最容易被低估的。视频原始文件、转码后的多码率副本、封面图、审核截图、日志、特征样本这些加起来才是真实存储量。一个日上传千万条视频的平台按单条原始文件 30 MB 算一天就是 300 TB 原始数据加上三到五档码率的转码副本实际落盘量是原始量的两到三倍。1.2 峰值形态不止一种晚高峰、突发热点、活动脉冲把均值乘一个系数就当成峰值这个做法只对“晚高峰”这一类有效。实际系统要面对至少四种形态完全不同的峰值它们的应对手段也不一样。第一种是周期性晚高峰。晚上八点到十一点流量大约是均值的两到三倍曲线平滑可预测。这类峰值靠容量预留和弹性扩容就能覆盖是最“友好”的峰值。第二种是突发热点。某条内容突然爆了短时间内同一个视频的分片请求暴涨几个数量级。这类峰值的总量可能不大但集中度极高——所有请求都指向同一个对象。这时候 CDN 的边缘缓存命中率会瞬间冲到 99%看起来很美好但源站和缓存层的“热点key”问题会同时爆发单个节点的网卡打满其他节点却很闲。第三种是活动脉冲。整点开抢、倒计时开播、红包雨这些是人为制造的、几乎垂直的流量墙。一秒内请求量涨十倍持续三十秒又掉回去。这类场景的难点不在峰值本身而在“扩容来不及、缩容又浪费”。应对方式只能是提前扩容加排队削峰绝对不能靠自动扩缩容因为容器启动时间根本追不上。第四种是故障转移型峰值。某个可用区或某个 CDN 厂商节点出问题流量瞬间压到剩余节点上。这时候剩余节点承受的不是正常峰值而是“正常峰值 × 故障域占比 ÷ 剩余容量占比”很容易超过 100%。这类峰值最危险因为它往往和其他问题同时发生。提示做容量规划时我一般会要求业务方给出四条曲线而不是一个数字日常曲线、大促曲线、热点事件曲线、单点故障后的曲线。缺一条容量结论就是不可信的。1.3 一套能落到PRD里的粗算模板说了这么多落到文档上要能一眼看懂。我给团队用的模板大致是这样写进需求文档的“容量评估”章节评审时逐项过一、用户侧假设 日活 / 月活 人均日使用时长 人均日播放条数 峰值同时在线占比 二、流量侧推导 均值带宽 / 峰值带宽 峰值API QPS / 峰值分片QPS 峰值长连接数 日新增内容量 / 日新增存储量 三、成本侧推导 带宽月成本按单价×流量 存储月成本 计算资源月成本 单用户月均基础设施成本 四、冗余与SLA 单可用区故障后剩余容量占比 目标可用性 允许的最大降级范围这张表最有价值的是第三部分的最后一行单用户月均基础设施成本。很多团队算容量只算技术指标不算钱结果架构方案做得很漂亮一算账发现商业模式根本撑不住。短视频这类产品带宽成本往往占到基础设施总成本的六七成这个比例决定了后面所有的技术选型——为什么一定要做多码率、为什么一定要做热度分级缓存、为什么一定要抠那 5% 的编码效率答案都在这个比例里。我在一个中等规模的项目上踩过一次坑早期为了画质全量上了高码率日活涨到三百万的时候带宽账单直接超过了当月全部服务器成本的总和。后来做了码率自适应把移动网络下的默认档位降了一档画质投诉率只涨了 0.3%带宽降了 40%。这个教训让我此后所有项目的第一版容量文档里都必须带上成本列。2. 接入层第一波冲击挡在离用户最近的地方用户点开应用的那一瞬间请求其实经过了至少四层DNS 解析、边缘接入、七层网关、业务服务。绝大多数架构文章直接从微服务讲起把这四层当成“基础设施默认存在”。但在海量流量场景下这四层恰恰是决定生死的部分——源站再强接入层扛不住就是全网不可用。接入层的核心矛盾是它必须极其简单简单到几乎不可能出bug同时又必须承担最多的流量。这个矛盾决定了接入层的设计哲学和业务层完全相反。2.1 调度决定生死就近接入与故障摘除调度这件事很多人以为就是“DNS 解析到最近的机房”。实际远比这个复杂因为“最近”不等于“最优”。一个用户物理上离A机房三十公里但A机房到用户所属运营商的链路绕了一圈实际延迟反而比一百公里外的B机房高。所以现代调度系统基本不看地理距离看的是探测出来的真实网络质量。我见过的调度策略大致分三代第一代是基于地理位置的静态调度简单粗暴配置在DNS里。优点是几乎不会出错缺点是完全没有弹性某个机房挂了要等DNS TTL过期才能切走那几分钟就是纯故障时间。第二代是基于探测的动态调度各地部署探测点定期测量到各机房的延迟和丢包生成调度表下发到权威DNS。这一代的问题是探测频率和调度稳定性之间有矛盾——探测太频繁调度表抖动用户会感觉“一会儿快一会儿慢”。第三代是接入层和调度层联动。边缘节点自己上报健康度和负载调度中心结合实时容量做加权分配出现故障时不仅摘除节点还会把流量按剩余容量比例重新分配。这一代的关键是“加权”不是简单的“能用/不能用”二元判断。因为一个机房的容量是有限的如果故障转移时把全部流量都指过去本来健康的机房会被打挂故障就从单点变成全局。这里有个经验值可以参考单机房故障转移时转入机房的瞬时流量不应超过其设计容量的 60%留出的 40% 是给突发和重试的余量。如果算下来超标那就说明容量冗余不够得提前扩而不是指望调度算法更聪明。2.2 长连接网关的心跳与内存账短视频产品几乎都有长连接用来做消息推送、直播状态同步、在线状态维护。长连接网关和普通无状态服务最大的区别是它是有状态的而且状态占内存。一台网关机器能撑多少连接取决于三件事文件描述符上限、单连接内存占用、心跳带来的包处理压力。前两个是硬限制第三个是软限制。先说内存。一个长连接对象如果实现得粗糙塞了一堆业务字段单个连接占几 KB 很常见一台 64 GB 的机器算下来也就撑十几万连接还要留一半给堆外和系统。优化方式是把连接状态压缩成最小集合连接ID、用户ID、最后心跳时间、协议版本前三个是必须的其余能放外部存储就放外部。压缩到几百字节单机承载量能翻好几倍。再说心跳。心跳间隔的设计是个权衡间隔短能快速发现断连但包处理压力大间隔长压力小但故障发现慢。移动端场景还有个额外因素——手机休眠会中断连接唤醒后要重连如果心跳间隔和系统休眠策略冲突会出现大量“假在线”连接看着连接数很高实际推消息全失败。我踩过的一个坑是心跳和负载均衡的超时时间不匹配。网关的超时设成了 300 秒心跳间隔 60 秒看起来没问题。但负载均衡器那一层的空闲超时默认是 60 秒结果大量连接在负载均衡器上被静默断开客户端却以为还连着直到下一次发消息才发现。这类问题的排查特别费劲因为应用层日志里一切正常只有抓包才能看到中间层发了 RST。参数常见取值设置依据踩坑点心跳间隔30 ~ 60 秒移动端休眠策略、电量消耗太长会导致假在线连接空闲超时心跳间隔 × 2 缓冲容忍一次心跳丢失必须大于心跳间隔负载均衡空闲超时大于网关超时避免中间层先断默认值经常是60秒单机连接上限按内存倒推单连接内存 × 数量 可用内存70%忽略堆外内存注意所有和“超时”相关的参数必须从外到内逐层递增任何一层比内层短都会造成莫名其妙的断连。这个原则在接入层比在任何地方都重要。2.3 限流不是限死分层限流与降级开关限流这件事最大的误区是“在入口做一次就够了”。实际上限流必须分层每层的粒度和目的都不一样。最外层是接入层限流按 IP、按地域、按连接数做粗粒度限制目的是挡住明显的异常流量比如单IP发起海量连接。这一层的阈值应该设得很宽松只拦截明显异常不能误伤正常用户。中间层是网关层限流按用户、按接口做细粒度限制。这一层的核心是保护后端阈值要结合后端实际处理能力来定而且必须是动态的——后端扩容了阈值要跟着调。最内层是服务层限流按依赖做隔离。这一层最关键因为真正的雪崩往往发生在这里某个下游服务变慢上游线程池被占满然后连锁反应。这一层的限流必须配合熔断只限流不熔断请求还是会在队列里堆积。降级开关的设计比限流更考验经验。我的原则是每个开关都必须能被独立关闭且关闭后系统仍能提供降级但可用的服务。见过太多团队的降级开关是“一键关全部”真出问题的时候没人敢按——按下去等于全站不可用谁敢背这个责任。正确的做法是把开关切成小块关推荐、关评论、关个性化排序、关高清码率每一块的业务影响是可控的、可预期的。降级还有一个隐藏问题降级后的容量是否够。推荐服务关掉之后回落到默认排序这个默认排序的缓存能不能扛住全量流量如果没有验证过降级等于换个姿势崩。所以降级方案必须定期演练不能只写在文档里。3. 视频链路真正的成本大头在分发侧前面算过账带宽成本占基础设施成本的大头。这一节就拆这条链路从上传到播放中间的每一步是怎么把成本和体验同时按住的。这条链路上有很多反直觉的地方比如“提高压缩率不一定省钱”、“缓存命中率不是越高越好”。3.1 上传与转码为什么必须做多码率先说一个基础事实同一个视频不同终端的解码能力、屏幕分辨率、可用带宽完全不同。给一个 4G 网络下的中端手机推 4K 原片结果只能是卡死。所以转码不是“优化”是“必须”。转码的核心是码率阶梯的设计。太密存储和转码算力浪费太疏自适应切换时画质跳变明显。行业里常见的做法是四到六档从 360P 到 1080PH.264 和 H.265 双编码。这里有个容易被忽略的点阶梯的间隔应该在对数尺度上均匀而不是线性均匀。因为人眼对码率的感知是对数的从 500 Kbps 到 800 Kbps 的感知差异和从 5 Mbps 到 8 Mbps 的感知差异差不多所以线性分档会导致低码率档太稀、高码率档太密。编码格式的选择是个纯粹的算术题。H.265 相比 H.264同画质下码率能降 30% 到 50%但编码复杂度高好几倍解码兼容性在低端设备上有问题。所以实际策略是分设备下发新设备、高端设备给 H.265老设备回落 H.264。这需要客户端上报解码能力服务端按能力适配清单。转码的算力成本也不能忽略。一个日上传千万条视频的平台如果每条都实时转五档算力开销惊人。所以通常是“先转一档可播其余按需异步转”。这个策略的关键是判断哪些内容会火——如果判断错了热门视频的转码任务会在热点爆发后才排队用户看到的就是低清版本。这里就体现出推荐系统和转码系统的耦合推荐系统有热度预测能力转码调度应该消费这个信号。提示转码任务队列一定要做优先级分层。头部内容、大V发布、实时热点这三类必须走高优先级队列其余走普通队列。纯粹按提交时间排队的队列在热点爆发时必然堵死。3.2 分发分层热度决定缓存位置CDN 的本质是“用存储和带宽换距离”但在海量流量下真正的技巧是分层。一个典型的分层结构是三层边缘节点离用户最近数量最多单节点存储最小、中间层区域汇聚数量中等、源站中心存储。请求进来先查边缘没有就回中间层再没有才回源。这个结构的关键参数是每一层的缓存命中率目标。如果边缘命中率目标是 95%意味着 5% 的请求要回中间层中间层再命中 90%剩下 0.5% 回源。这个数字看起来很小但乘以总请求量就很可观了。命中率不是越高越好这点很多人不理解。提升命中率的手段是延长缓存时间和增加单节点存储代价是存储成本和内容新鲜度。一个内容在边缘节点多存一天可能只多服务了几十次请求但占用的存储是实打实的。所以正确的做法是按热度分级设置缓存策略热度分级判定依据边缘缓存时长存储位置回源策略极热播放量Top 0.1%数天全量边缘节点几乎不回源热Top 1% ~ 10%数小时部分边缘中间层低频回源温长尾中的活跃部分数十分钟中间层中等回源冷长尾极短或不缓存源站直出高回源这张表背后是“缓存该存什么”的判断。一个常见的错误做法是给所有内容设置相同的缓存时长结果极热内容频繁过期回源冷内容占着存储没人看。分级策略必须由数据驱动热度信号从播放日志里实时算出来下发给 CDN 配置系统。还有一个细节是回源收敛。当极热内容在边缘过期时如果所有边缘节点同时回源源站会瞬间被打穿。解决办法是加一层“回源锁”或“合并回源”——同一个内容在同一时刻只允许一个回源请求其余请求等待结果。这个机制在正常流量下几乎无感但在热点爆发时就是救命的那一下。3.3 秒开与卡顿的取舍函数播放体验有两个核心指标首帧时间秒开率和卡顿率。这两个指标是矛盾的——预加载越多秒开越快但带宽浪费越多卡顿反而可能因为带宽竞争而上升。大多数团队的初始策略是“尽可能快”结果带宽成本飙升。正确的做法是建立一个成本函数把三个量放一起算总体验成本 带宽成本 × 浪费系数 卡顿惩罚 × 卡顿率 首帧惩罚 × 首帧时长这个函数里的权重需要业务定。资讯类内容用户容忍度高可以牺牲一点首帧直播场景卡顿惩罚极高宁可多花带宽。我见过一个团队把这个函数做成可配置的不同业务线用不同权重效果比统一策略好很多。预加载策略的细节也值得说。常见的做法是“播放当前视频时预加载下一条的前几秒”。预加载多少我的经验是按“用户划走概率”来定如果用户在 3 秒内划走的概率是 40%那预加载 3 秒以上的内容有 40% 是浪费的。所以预加载时长应该跟着用户行为分布走而不是拍脑袋定 5 秒。还有一个容易被忽略的点是多码率切换的时机。频繁切换码率会让画质忽高忽低观感很差切换太迟钝又会导致卡顿。通常的做法是加一个“迟滞窗口”带宽下降时立即降档带宽上升时要持续稳定一段时间才升档。这个不对称设计很重要因为用户对“清晰度下降”的容忍度远高于“卡顿”。4. 元数据与存储小对象、大表、缓存的三角关系视频文件是“大对象”但支撑整个产品的其实是“小对象”和“元数据”用户信息、视频信息、互动关系、评论、推荐特征。这些数据的特征是单条很小、总量极大、访问极度不均匀。这个特征决定了存储方案不能只有一种。4.1 对象存储的分层与生命周期视频文件放对象存储这是共识。但对象存储内部也有分层而且分层策略直接影响成本。常见分层是标准存储频繁访问、低频存储偶尔访问、归档存储几乎不访问。价格差异可以达到数倍。关键在于如何判断一个对象该在哪一层以及迁移的时机。我的做法是按内容年龄和访问热度双维度判断。新发布的内容进标准层30 天无访问的转低频180 天无访问的转归档。但这个规则有个坑归档层的读取是有延迟的如果一条老内容突然被推荐系统捞出来推给用户用户点开要等几秒甚至几分钟体验直接崩。所以归档策略必须和推荐系统打通。推荐系统在给老内容分配流量之前要先发一个“预热”信号把对象从归档层拉回标准层。这个预热是异步的通常提前几分钟到几小时。如果没有这个机制纯粹按时间归档迟早会出事。另一个细节是删除。用户删除视频不能立即物理删除因为可能有审核、申诉、法务留存的需求。通常是标记删除加延迟物理删除。但延迟删除期间对象还在占存储、还在被CDN缓存命中。所以要有一套“逻辑删除 → 缓存失效 → 物理删除”的完整链路任何一环缺失都会导致“删了还能播”的诡异问题。4.2 分库分表之后一致性去哪了元数据的量级决定了单库单表撑不住。一个日活过亿的产品视频表轻松过百亿行必须分库分表。分片键的选择是第一道难关。按用户ID分片查询“某个用户的视频列表”很高效但查询“某个视频的详情”就要扫全部分片。按视频ID分片则相反。短视频产品的读放大头是“刷feed”本质是按用户维度取一批视频所以通常按用户ID分片视频详情走另一套索引或者缓存。分片之后一致性就成了绕不开的问题。举几个真实场景用户发了一条视频写入了分片A但关注他的用户分布在几百个分片上。粉丝的feed流里要出现这条视频靠的是“写扩散”还是“读扩散”写扩散是把视频ID推到每个粉丝的收件箱写入量巨大但读取快读扩散是读取时实时聚合写入轻但读取重。大规模场景通常是混合普通用户用读扩散大V用写扩散。这个混合策略带来的一致性问题很微妙大V发视频后粉丝可能几秒内就能看到普通用户发视频粉丝可能要刷新才看到。这个差异用户是能感知的所以产品侧要设计相应的提示比如“已发布正在分发中”。还有一个经典问题是计数一致性。点赞数、评论数、播放数这些数字的量级极高每秒可能几十万次更新。如果每次都去更新数据库的计数字段行锁竞争会直接把库打挂。所以实际方案是计数先写缓存或消息队列异步聚合后批量落库前端展示读缓存。这样做的代价是数字有延迟且缓存和库之间可能不一致。解决办法是定期做一次全量校准把偏差修正回来。数据类型一致性要求实现方式可接受延迟账号与认证强一致同步写主库无视频元信息最终一致写库缓存失效秒级互动计数最终一致消息队列异步聚合十秒级播放量统计弱一致日志采集离线/近线计算分钟到小时级交易与账务强一致分布式事务/对账无这张表的意义在于大部分人一上来就追求全链路强一致结果系统又慢又复杂。把一致性要求分级只在真正需要的地方花代价这才是工程判断。4.3 缓存击穿这件事预案比方案重要缓存问题被讲烂了但真正出事故的时候往往不是不知道原理而是预案没做。缓存击穿的典型场景某个热点key过期瞬间大量请求穿透到数据库。解决方案大家都知道——加互斥锁或者永不过期加后台刷新。但实际系统里问题出在“哪个key会变成热点”是不可预测的。我处理过一次事故起因是一个很普通的配置项缓存。正常情况下这个key每秒只有几十次读取某次运营配置了一个全站生效的活动开关瞬间变成每秒几十万次读取正好撞上缓存过期的时刻数据库连接池瞬间打满连锁导致整个服务不可用。事后复盘互斥锁是加了的但锁的粒度是“单key”而这个key是全局单例所有请求抢同一把锁等于变相串行化吞吐直接掉到零。所以更稳的做法是逻辑过期缓存里存的不是数据本身而是数据加一个过期时间戳。读取时如果发现逻辑过期不阻塞等待而是先返回旧数据同时异步触发刷新。这样任何时刻都有数据可返回只是可能短暂不新鲜。这套方案对短视频这类场景完全够用因为多展示几秒旧数据没人会发现。对于绝对不能旧的数据比如余额、库存那就必须走强一致路径加锁等待但要配上限流和超时避免锁等待把线程池占满。这里的原则是宁可让少量请求失败不能让线程池耗尽。5. 推荐系统流量分发的“看不见的手”也有技术账前面讲的都是“流量怎么送出去”但真正决定哪个视频被看到的是推荐系统。它既是流量分发的核心也是资源消耗的大户同时还是商业模式的直接承载者——广告和内容的排序其实是同一套逻辑的两面。5.1 一次刷新的延迟预算拆解用户下拉刷新从触屏到内容出现整个过程有严格的延迟预算。行业经验是 200 毫秒内用户感觉“即时”超过 500 毫秒开始明显感知等待。这个预算怎么分配一次典型的刷新链路大致是网络往返30~80 ms→ 网关鉴权与路由5~10 ms→ 推荐服务召回20~50 ms→ 排序模型推理10~30 ms→ 重排与多样性打散5~10 ms→ 素材组装10~20 ms→ 返回渲染。留给服务端的只有 100 毫秒左右。这个预算里召回和排序是两个大头。召回要从几千万候选里筛出几百个通常用多路并行召回向量检索、协同过滤、热度、关注、地域每路都有自己的超时任何一路超时都不能拖垮整体所以要并行加超时兜底。排序模型推理的预算更紧。深度模型效果好但耗时长所以实际系统是“粗排精排”两级粗排用轻量模型从几百筛到几十精排用重模型对这几十打分。粗排的模型必须够轻通常是双塔结构用户侧和物品侧向量可以离线算好在线只做内积。这样单次推理能压到几毫秒。还有一个经常被忽略的成本特征拉取。一个精排模型可能需要几百个特征分布在多个特征存储里。如果串行拉取光网络往返就要几十毫秒。所以必须做批量拉取加本地缓存且缓存要预热。5.2 特征与样本离线在线一致性推荐系统最经典的工程难题是“训练- serving 偏差”training-serving skew离线训练用的特征和在线推理用的特征对不上。表现有很多种离线算的是“过去7天平均播放时长”在线算的是“过去7天平均播放时长但T1更新”时间窗口错位离线用整数除法在线用浮点离线某个特征缺失填 0在线填 -1。这些差异单个看都很小累加起来会让线上效果明显低于离线评估。解决方式说起来简单特征定义统一管理离线和在线共用同一份计算逻辑。实际操作中很难因为离线和在线的计算引擎不同。可行的做法是把特征计算逻辑抽象成配置或DSL由平台分别编译成批处理任务和实时计算任务保证语义一致。同时建立特征监控对比同一批样本在离线和在线的特征值分布偏差超过阈值就告警。样本这块也有个坑负样本的选取。短视频场景里用户没点击的内容不一定是负样本可能是没曝光。把“未曝光”当成“负样本”会让模型学到错误信号。正确做法是只把“曝光但未点击”作为负样本且要做法定的曝光日志采集。这个细节如果一开始没设计好后期补数据非常困难。5.3 降级预案推荐挂了怎么办推荐服务是整个产品最复杂的部分也是故障概率最高的部分。必须有明确的降级阶梯一级降级是关闭部分召回路径。比如向量召回超时就只用热度召回和关注召回效果会下降但不影响可用。二级降级是跳过精排。直接用粗排分数输出或者用规则排序。这时候个性化程度大幅下降但延迟能降一半以上。三级降级是完全回落到静态列表。按热度或者时间排序用预生成的缓存直接返回。这是最后的兜底效果最差但最稳。关键设计是降级必须自动触发且可自动恢复。人工按开关的方式在凌晨三点没人值班的时候就是灾难。触发条件建议用“错误率 延迟”双指标且要有防抖避免指标抖动导致频繁切换。还有一点降级后的流量会打到备用路径上备用路径的容量必须提前验证。我见过推荐降级后回落到数据库直查结果数据库被查挂的案例。降级路径也要纳入压测范围。6. 流量变收入商业模式对架构的反向约束技术架构和商业模式不是单向的“技术支撑业务”而是双向约束。广告要实时竞价就给系统加了毫秒级延迟要求电商要下单不超卖就给库存系统加了强一致要求。理解这些约束才能理解为什么某些技术选型是“不得不”。6.1 广告链路填充率与eCPM背后的系统要求信息流广告的技术链路是请求广告位 → 召回候选广告 → 预估点击率和转化率 → 竞价排序 → 返回素材。这条链路对延迟极其敏感。因为广告请求和内容请求是并行发出的如果广告返回慢了要么等影响整体延迟要么不等广告位空着浪费流量。所以广告的超时预算通常比内容更短100 毫秒左右。这就带来一个取舍多召回一些候选能提升eCPM但会增加延迟。实际系统的做法是分级召回先快速召回一批够用就返回如果时间还富裕再补充召回。这种“随时可截断”的设计在广告系统里很常见。另一个技术点是计费与曝光的精确性。广告按曝光计费曝光上报必须准确多了广告主不认少了平台亏钱。所以曝光上报要有一套去重和补偿机制客户端上报、服务端校验、离线对账三方数据要对得上。这个链路的设计难度在于它要求“至少一次”投递加幂等去重而不是简单的发出去就完事。填充率是另一个指标。广告位请求出去没有广告可投就是空窗。提升填充率的手段之一是接入多个广告源做 waterfall 或头部竞价。这又带来新的复杂度多个源的超时管理、竞价结果的公平性、素材审核的一致性。6.2 直播电商交易链路的强一致与削峰直播场景的流量特征和点播完全不同极强的瞬时性。一场大场直播开场瞬间几十万人涌入峰值并发可能是平时的几十倍主播喊“上链接”几万人在几秒内同时下单。技术上的应对分两段观看侧和交易侧。观看侧靠的是前面讲的分发分层。大场直播必须提前做容量预留和预热把流推到离用户最近的节点。这里有个细节直播流的“热点”是随时间变化的同一直播间所有观众看的是同一个流所以缓存效率极高但单节点压力也极大。通常的做法是对超热直播间做“多路分发”把观众打散到多个边缘节点避免单节点网卡打满。交易侧靠的是削峰和强一致。库存扣减绝对不能超卖所以必须走强一致路径。但强一致意味着串行扛不住瞬时高并发。解决办法是库存分段把 1000 件库存拆成 100 段每段 10 件不同请求打到不同段减少锁竞争。代价是可能出现“整体还有库存但某一段卖完了”的情况需要做段间调剂。下单链路的另一个关键是幂等。用户手抖点两次、网络重试、消息重投都会产生重复请求。订单号必须是客户端生成的或者服务端用唯一键去重不能靠“先查再插”因为并发下查和插之间有窗口。6.3 虚拟礼物与账务幂等是生命线虚拟礼物、打赏、会员这类业务本质是账务系统。账务系统的第一原则是每一笔变动都必须有据可查、可对账、可回滚。技术上的核心是“流水 余额”双写且必须在一个事务里完成。高并发下这会成为瓶颈所以常见的优化是把“热点账户”拆开——比如某个大主播的收礼账户每秒可能几千笔入账单行锁扛不住。做法是给账户建多个子账户入账时随机或按用户哈希打到子账户查询时汇总。这个方案的问题是对账变复杂了且“余额查询”要汇总多个子账户。所以通常配合一个异步的“汇总任务”定期把子账户余额归集到主账户。还有一个必须提前设计的点退款和撤销。用户充值后要求退款钱已经花掉了怎么办礼物已经送出去了怎么退这些业务规则最终都要落到数据模型上如果模型里没有“可退余额”和“已消费金额”的区分后期改起来极其痛苦。提示所有涉及钱的表字段设计一定要留出“状态机”的空间。不要用布尔值表示状态用枚举且枚举值只增不改。这个习惯能省掉未来无数次数据迁移。7. 成本账本Tbps背后每一分钱花在哪前面反复提到成本这一节专门拆。做海量流量的系统技术决策和成本决策基本是同一件事。一个方案如果技术上可行但成本翻倍那它大概率不会被采纳。7.1 单位成本模型怎么拆我习惯把基础设施成本拆成四个池子带宽、存储、计算、其他数据库、中间件、日志等。然后算三个单位成本指标单用户月成本 总成本 ÷ 月活单次播放成本 带宽成本 ÷ 播放次数单条内容存储成本 存储成本 ÷ 内容总量这三个指标的价值在于横向对比和纵向趋势。比如单次播放成本突然上升可能是码率策略变了也可能是缓存命中率下降了。单条内容存储成本上升可能是归档策略失效了。带宽成本的拆解要更细因为它占大头带宽总成本 边缘节点出流量 × 边缘单价 中间层回源流量 × 中间层单价 源站出流量 × 源站单价 总流量 × [命中率加权后的综合单价]这个公式说明一件事提升边缘命中率是降本最直接的手段。命中率从 90% 提到 95%回源流量直接减半。所以前面讲的缓存分级策略本质上是个成本优化手段不只是技术优化。7.2 降本优先级编码、命中率、冗余降本手段很多但收益和成本差别很大。我按“投入产出比”排了个序手段典型降本幅度实施成本风险提升边缘缓存命中率15% ~ 30%中内容新鲜度下降编码效率优化H.265/AV120% ~ 40%高兼容性、算力成本码率阶梯优化10% ~ 20%低画质投诉减少预加载浪费5% ~ 10%低秒开率下降存储分层与生命周期20% ~ 40%存储部分低冷内容读取延迟计算资源混部与弹性10% ~ 25%计算部分中稳定性风险按这张表性价比最高的其实是“码率阶梯优化”和“存储分层”投入小见效快。但很多团队一上来就搞编码升级投入半年人力收益还不如把缓存策略调一调。这个判断很重要因为工程资源是有限的。编码升级的真实成本经常被低估。换 H.265 不只是编码器的事还涉及客户端解码兼容性测试、老设备降级策略、转码集群的算力扩容H.265 编码慢好几倍、存量内容的灰度重转。这一套下来往往是半年以上的工程。所以正确顺序是先把低垂果实摘完再动编码。7.3 弹性与预留的配比最后一个成本话题是资源配比。云上的资源有两种买法按量付费弹性贵和预留便宜但闲置也付费。配比怎么定我的经验是按“基线 峰值”来分。日常流量的基线部分用预留因为这部分是稳定可预测的峰值部分用弹性因为一天只有几个小时。比例大致是预留覆盖日均流量的 60% 到 70%弹性覆盖剩余。这个比例不是固定的要看业务的波动系数——波动越大弹性比例越高。但弹性的问题在于启动速度。容器冷启动几十秒虚拟机几分钟。对于晚高峰这种可预测的峰值可以定时扩容提前半小时拉起来对于突发热点弹性根本来不及只能靠预留冗余。所以准确的说法是可预测的峰值靠弹性不可预测的峰值靠冗余。冗余是成本但它是保险费。8. 压测与复盘几个能直接抄的经验前面七节讲的都是“应该怎么设计”但真实系统的问题往往出在“设计和现实不一致”的地方。这一节讲几个我实际踩过的坑以及从中总结出的可操作经验。8.1 压测最容易失效的三种情况压测做了但没效果通常是因为下面三种情况。第一种是压测流量和真实流量的分布不一致。用统一的请求打测出来的QPS很好看但真实场景里 90% 的请求集中在 10% 的热点内容上缓存行为完全不同。压测必须带真实的请求分布最好是回放真实流量。第二种是压测环境的数据量不对。测试库只有几万条数据索引全在内存里查询飞快生产库几十亿条索引命中率完全不同。压测环境的数据量至少要达到生产的一个可比的量级否则结论不可信。第三种是只压主链路不压依赖。主服务压得很充分但它依赖的配置中心、鉴权服务、消息队列没压过真上量的时候这些先挂。压测应该做全链路压测从入口一直压到最底层的存储。还有一个隐蔽的问题压测本身会污染监控数据。压测流量和真实流量混在一起告警阈值被拉高真实故障时告警不响。所以压测流量必须打标监控要能区分。8.2 一次雪崩的完整排查链路讲一个我经历的典型故障过程很有代表性。现象晚上九点部分用户反馈首页刷不出内容比例大概 5%间歇性。第一步看监控大盘整体QPS正常错误率略升但不明显。这时候如果只看聚合指标很容易判断“没问题”。第二步看分维度指标发现错误集中在某几个机房且这几个机房的某个下游服务的延迟明显升高。第三步看那个下游服务的日志发现大量“连接超时”。再看它的下游是一个缓存集群缓存集群的CPU不高但网络连接数异常高。第四步发现连接数高的原因是客户端在频繁建连。为什么频繁建连因为连接池的“最大空闲时间”设置得比缓存的“服务端空闲超时”短连接被服务端先关了客户端还以为可用拿到一个死连接超时后重试重试又拿到死连接恶性循环。根因两个超时参数不匹配。修复很简单把客户端空闲时间调到服务端超时以下。但排查花了两个多小时因为链路上有三层每层的指标都“看起来正常”。这个案例的教训聚合指标会掩盖局部问题必须做分维度下钻超时参数的匹配关系必须文档化不能靠人记连接池的健康检查要开启不能只依赖超时8.3 中小规模团队能借鉴的三件事最后说点务实的。上面讲的是超大规模场景绝大多数团队用不上。但有三件事是任何规模都值得做的。第一件把容量数字写进文档。不管你的日活是一万还是一百万都要能算出带宽、QPS、存储的量级并且定期更新。这件事的成本是一张表格收益是避免“拍脑袋扩容”和“拍脑袋不扩容”。第二件给每个降级开关配一个容量验证。降级方案写出来只是第一步真正要做的是验证降级后的路径扛不扛得住。方法很简单在测试环境把开关关掉压一遍。十分钟的事能避免事故时的二次伤害。第三件建立超时参数的检查清单。我前面讲了三次超时问题因为这是最常见也最难查的一类故障。做法是把所有跨进程调用的超时列出来从外到内检查是否递增。这个清单可以在每次架构评审时过一遍成本极低。我个人在实际操作中的体会是海量流量系统的复杂度八成来自“组件之间的交互”而不是单个组件本身。单个服务做高并发不难难的是几十个服务串起来之后任何一个参数配错都能引发全局问题。所以比起追新技术把参数、超时、降级、容量这些“老话题”管住收益要大得多。