有一次面试聊到最后，面试官问我上一段工作做什么。我说了技术栈和规模，没说业务。他追问了一句业务是什么，我答完，他点点头，说这个场景其实比大多数电商更考验架构。
那是我第一次意识到，尴尬来自措辞，不来自技术。
尴尬的是语言
这类平台的工程问题很具体：带宽成本、首帧时间、审核的吞吐、身份的隔离。这些放到任何一家流媒体公司都是同一批问题，甚至因为利润结构不同，约束还更紧一些。
难的是怎么在面试里描述它。说得太含糊，像是有所隐瞒；说得太具体，场面会变得奇怪。我的做法是把业务抽象成约束：日吞吐量、并发数、单位流量成本、可接受延迟、合规要求。这几个数字一摆出来，对话自然就回到了工程层面。
简历上也一样。不写「某类网站后端」，写「高并发内容分发平台」，后面跟规模和指标。这不是包装，是提高信息密度——对方关心的是系统长什么样，不是内容是什么。
措辞上我尽量不用「某行业」这类词，也不刻意模糊成「互联网公司」。前者像在回避，后者经不起追问。直接说平台类型，然后立刻转到规模和技术点，对话就不会停在原地。
面试官评估的是约束下的判断力，不是对行业的道德态度。
我一开始不太敢用这种写法，觉得像在藏。后来想明白，简历的作用是让人判断要不要聊下去，不是交代履历的全貌。真正需要说明的部分，留到面谈里讲，那时候有上下文，也有解释的机会。
背调也是个现实问题。这段经历在社保和合同上都有记录，藏不住，也没必要藏。真正需要准备的是怎么在一句话里说清楚它和别的流媒体平台的差别。
技术细节的准备反而简单。真正要练的是三句话之内把场景说清楚：规模多大、瓶颈在哪、做了什么取舍。超过三句，对方就开始走神了。
当然也有边界。如果对方明显只想聊猎奇的部分，那这个岗位大概不适合我，早点结束对双方都好。
协议选择是一道成本题
点播和直播是两套不同的约束。点播的核心是存储和带宽，长尾明显，缓存命中率决定成本；直播的核心是延迟，尤其是打赏这类互动，延迟超过一秒，付费意愿会明显下降。
HLS 便宜，因为它是 HTTP，能吃到现成的缓存体系，代价是延迟以秒计。WebRTC 延迟低，走 UDP，但它绕开了缓存，带宽和计算成本都更高。所以「选 HLS 还是 WebRTC」的答案取决于用户分层：浏览型流量用 HLS，付费互动用 WebRTC。同一场直播里也可以切，前几秒用低延迟链路起播，稳定之后切回便宜链路。
成本可以粗算：带宽单价乘以月流量，再乘以缓存未命中的比例。这个式子很粗，但它能让讨论从「哪个技术更好」变成「哪条线路在什么场景下更便宜」，后者才是这类岗位真正要回答的问题。
这个切换听着聪明，实现起来有一堆麻烦：切换点的对齐、播放器的兼容、失败回退。做得好没人注意，做不好就是黑屏。
切片时长是另一个常被追问的点。把六秒压到两秒，延迟下来了，但请求数上去了，缓冲变小之后抗抖动能力也变差。对百万级并发的平台，请求数翻三倍意味着边缘节点的连接数和源站的回源压力都要跟着翻。低延迟 HLS 用分块传输在两者之间找了个位置，代价是播放器和 CDN 都要支持，兼容性要单独测。
首帧时间是这类产品最实在的指标。用户是刷着看的，起播慢一秒，人已经划走了。做法不复杂：切片边界对齐关键帧，让播放器拿到第一个切片就能解码；热门内容提前推到边缘，别等用户点进来才回源。
预热这件事有个容易忽略的成本：热门是会变的。推得太早浪费带宽，推得太晚没有意义。我见过的做法是按小时级别的热度预测滚动更新，预测错了就退化成普通回源，不会更糟。
带宽账单最后会决定架构。这类平台的单位用户收入低，带宽是最大的单项成本，所以调度器不能只按性能选节点，还要按价格选。我理解的做法是加权：先保证一个基础体验阈值，比如卡顿率不超过某个值，在这个前提下优先走边际成本更低的线路。合同里的保底量要优先填满，因为那部分钱已经付了；高峰期的溢出流量再切给二线厂商，牺牲一点画质或者多几十毫秒延迟，换的是账单上的一截。
回源是另一个隐形成本。缓存命中率低的时候，请求会直接打到源站，源站的流出费用远高于边缘。冷门内容的长尾尤其麻烦，同一个冷门视频可能在几秒内被不同节点重复回源。把请求在边缘聚合一下，能省掉不少重复。
边缘鉴权也值得做。非法请求和爬虫如果能在边缘就拒掉，产生的带宽成本就是零，也不用占源站资源。这个优化不提升体验，只省钱，但省钱在这类产品里就是核心指标。
隐私的本质是关联
单看一条浏览记录，危害有限。真正的问题是把支付身份和浏览行为连起来。所以架构上的核心不是加密强度，是让这两个数据集不共用一个键。
比较彻底的做法是物理分库：账单库按支付合规的要求存身份信息，行为库只存匿名标识，两边通过一个加盐的临时映射通信。用户注销时销毁映射，即使两个库都被拖走，也没法把人和记录对上。
支付是最难的一块。既要满足合规的身份核验，又不能让身份和行为落在同一个库里。常见的做法是把核验外包给支付服务商，平台只留一个一次性的凭证号，凭证用完即弃。
删除也是同一类问题。软删除在电商里合理，在这里不合理。物理删除的成本在于备份，冷备里可能还留着。加密粉碎是个折中：每个用户一把密钥，删密钥等于让所有副本变成乱码。它不真的删除数据，但达到了不可读的效果。这个方案我一直觉得有点取巧，不过在没有更好的办法之前，它是成本和效果之间比较能接受的一个点。
这套设计的前提是数据最小化。注册时不需要的字段就别收，能拿到近似位置的场景不要精确坐标，日志里不写完整的用户标识。很多泄露事故的损失程度，取决于当初多收了哪些字段，而不取决于攻击者有多强。
内部工具容易漏。客服后台看到的信息应该是脱敏的，日志里不应该有身份字段。这些不是架构问题，是纪律问题，但出事往往出在这里。自动化扫描能挡掉一部分，挡不住的部分只能靠评审。
审计日志本身也是风险点。为了追责而记录的操作日志，如果包含敏感字段，等于又造了一个副本。记录「谁在什么时候查了哪条记录」就够了，不需要把记录内容也存一份。
审核流水线的本质是排队
内容审核听起来敏感，工程上是一道典型的漏斗题：怎么用最低的成本把大部分请求挡在前面。
第一层是去重。文件哈希只能抓完全相同的副本，感知哈希能抓转码、裁剪之后的变体。这一层成本极低，能挡掉相当一部分重复上传。
第二层是抽帧。逐帧推理不现实，按关键帧或者固定间隔采样，把计算量压下来。采样策略本身有讲究，开头和中间密度高一些，结尾可以稀一点，因为违规内容通常不会只出现在最后一秒。
第三层才是模型。模型一定有误判，所以阈值要分层：低分直接放行，高分直接拦，中间那段进人工。人工只处理边缘案例，这是这套系统能算得过账的原因。如果中间段占比太高，人力成本会失控，那时候要调的不是阈值，是模型。
自建还是买现成的，我倾向于先买。自建模型的隐性成本在标注和迭代，不在推理。等业务量足够大、通用模型明显不够用的时候再自建，那时候也有数据了。
流量突增靠解耦。上传和审核之间放队列，消费端按能力拉取，积压深了再扩实例。这套东西在别处也一样，只是这里的单位成本更敏感，扩实例的决策要更早。等队列积压到肉眼可见再扩，用户已经在上传页面上等着了。
队列的另一个好处是可以做优先级。新上传的内容先过一遍粗筛，能快速上线；已经被举报的进高优队列。这个设计不难，但它需要产品侧配合定义什么叫「可以先上」。
一个只能处理平均流量的审核系统，在高峰期等于没有。
我曾经把阈值调得很严，误杀率上去了，人工队列一周就爆了。后来把阈值放松，漏放的那部分靠抽检兜。这个平衡点没有通用答案，它取决于人工团队的规模，而那个数字每个季度都在变。
我在面试里被问过一个问题：为什么不换个行业。当时的回答不太好，大意是技术是通用的。现在我会说得更具体一点：这套系统的约束条件——极低的单位成本、极高的并发、零容忍的隐私——在别的行业很少同时出现。能在这组约束下把系统跑起来，本身就是可迁移的经验。
至于业务内容，它决定了监管环境和舆论风险，不决定架构难度。这两件事经常被混在一起，尤其是在简历筛选那一关。
所以我现在不太纠结这段经历该怎么「洗白」。它本来就不脏，只是需要被翻译成一套通用的语言。翻译得好不好，取决于对约束的理解够不够深，不取决于话术。
我也不是完全没有顾虑。有些岗位的合规边界比技术边界更模糊，那不是靠架构能解决的。所以面试的时候，我会把问题问得具体一些：内容审核的标准由谁定，出了事故谁负责。答案含糊的，我就不太想去了。
© Lu’s Blog · 版权所有
评论