今年在准备Java高级岗位面试时我明显感觉到面试风格变了面试官不再拿“微服务有哪些组件”“Spring Cloud和Dubbo怎么选”这种背八股就能过的题来开头而是直接给一个具体的业务场景让你现场做架构设计并接受连续追问。最让我印象深刻的一场是一道音视频题目。面试官说假设我们要做一个短视频后端用户上传、系统转码、内容审核、CDN分发、播放还有评论互动你来设计后端架构。AI能力应该放在哪个环节哪些服务会先扛不住消息队列会出现在哪里这几乎把Java、微服务、AI三个方向的所有核心考点一网打尽——从服务拆分原则、分布式事务、幂等消费到AI模型推理的异步编排和高并发治理全部在一个场景里串了起来。这篇文章就是那场面试的完整实录包括我当时的第一版回答、面试官连续追问的原文回忆以及我事后重新梳理过的正确答案和排查路径。如果你也正在准备Java或微服务方向的面试或者对音视频系统的工程化设计感兴趣这篇复盘应该能帮你少走不少弯路。1. 一场围绕“短视频后端怎么拆”的面试开场1.1 为什么音视频场景成了微服务面试的高频考题面试官选场景不是随便挑的。音视频业务和普通电商、后台管理系统最大的区别在于它的链路特别长而且每一段的负载特征完全不同。上传阶段是网络IO密集要处理大文件分片、断点续传和带宽占用转码阶段是CPU密集一次1080P转码可能要吃掉好几个核的算力耗时从几十秒到几分钟不等审核阶段要调用AI视觉模型和语音识别模型依赖GPU推理分发阶段要考虑CDN边缘节点和播放鉴权互动阶段又是典型的高并发写多读少场景。一个短视频后端几乎把分布式系统里所有的经典负载类型都装进去了。这就让“微服务拆分”这个老问题有了真正的深度。面试官想听的不是“按模块拆”“按功能拆”这种正确但没用的废话而是想确认你有没有想清楚哪些服务应该独立部署、独立扩缩容、独立承担故障。1.2 我第一版的服务拆分方案当时我在白板上画了一张草图大致长这样视频上传服务负责接收客户端分片上传、校验文件元信息、生成上传凭证。对象存储层保存原始视频和转码产物逻辑上独立。视频元数据服务保存标题、封面、时长、码率、上传者、状态等结构化信息。转码编排服务负责创建转码任务、管理任务状态机、调度工作节点。转码工作节点真正执行转码的Worker按CPU资源水平扩展。内容审核服务对接AI模型对画面、音频、文本做风险识别。视频分发服务负责写CDN配置、生成播放地址、处理缓存刷新。播放网关负责播放鉴权、防盗链、限流。互动评论服务独立服务因为读写模型和主链路差异很大。面试官看了这个拆分点了点头但立刻追问了一句“转码编排服务和工作节点拆成两个是不是过度设计了”我当时心里一顿然后回答编排服务是控制面工作节点是数据面。控制面需要管理任务状态、失败重试、优先级调度数据面执行引擎要做得尽量简单只负责拉取任务、执行转码、上报进度。这样编排服务可以做成无状态快速水平扩展工作节点也可以在流量高峰时动态扩容甚至在任务波动大的阶段用按量付费实例。控制面和数据面分离这个思路在转码这类任务型系统里是经典做法。1.3 重新审视服务边界、故障隔离与扩展维度面试回来后我把这个拆分重新复盘了一遍把判断逻辑浓缩成一张表服务主要负载类型扩展维度故障影响面上传服务网络IO、大文件带宽、连接数影响视频采集转码WorkerCPU密集型计算计算资源转码延迟变大内容审核服务GPU推理GPU资源合规风险上升元数据服务读写混合CPU、数据库主链路不可用播放网关网络IO、QPS带宽、网关数量播放体验下降拆分的核心逻辑是只在代码层拆分没有意义必须让故障隔离和弹性扩展两个维度都真正获益才值得拆成独立服务。如果拆完之后大家还是共用同一个数据库、同一套缓存、同一个集群那只是把单体代码搬到了多个进程里没解决任何实际问题。2. 转码任务状态一致性被连续追问的三级链路2.1 第一轮追问任务状态机和消息队列的可靠性拆完服务之后面试官顺着转码链路往下走问了一个看似基础的问题“上传完成之后转码任务你是怎么触发和跟踪的”我的回答是转码绝对不能同步执行因为耗时太长必须走异步任务。任务表放在独立的库或表中字段至少包含task_id、video_id、status、progress、retry_count、create_time、update_time。状态流转是PENDING到PROCESSING再流转到SUCCESS或FAILED失败后按最大次数重试。触发方式很清楚上传服务在文件上传成功后投递一条消息到MQ转码编排服务消费消息后创建任务记录再调度Worker执行。面试官马上追问“如果MQ挂了或者消息丢了怎么办”这个问题要讲的是消息的可靠投递链路缺一个环节都不够严谨生产端要开启发送确认消息发出去之后必须收到Broker的确认响应没确认就本地重试Broker端要开持久化保证进程重启后消息不丢消费端要做手动ack业务处理成功之后再提交offset避免处理到一半进程挂掉导致消息被误认为已消费。转码任务不是高吞吐低延迟的类型它有明显的可靠性要求所以这些设置牺牲一点吞吐量完全值得。2.2 第二轮追问重复消费怎么处理幂等设计怎么做面试官没停接着问“如果同一个任务被消费了两次你怎么办”真实的场景是消费端把任务处理完了业务数据已经更新但在提交offset之前进程挂了MQ会重新投递这条消息。这时候如果没有幂等保护同一个转码任务可能被创建两次Worker可能被重复调度最后结果就是资源浪费和状态错乱。幂等设计要分三层做。第一层处理前先查询任务状态如果已经是终态就直接跳过第二层在任务表对task_id或者video_id加唯一约束靠数据库拒绝重复插入第三层如果是更复杂的跨服务重复消费场景可以单独建一张消息消费记录表用消息ID做唯一索引。幂等的本质不是“消息只被投递一次”而是“重复处理业务数据时最终结果和一次处理完全一致”。这个回答面试官认可了但他又补了一个坑“幂等判断本身不是原子操作如果两个请求同时进来怎么办”我补充说查询状态和更新状态要放在同一个数据库事务里通过更新语句的行锁或者唯一索引冲突来保证只有一个请求能真正执行下去。2.3 第三轮追问分布式事务怎么取舍到这里难度明显上了一个台阶。面试官问“转码成功之后需要更新任务状态、更新视频可播放状态、写一条播放记录、发起审核任务。这些操作分布在不同的库甚至不同的服务里分布式事务怎么保证”我当时心里很清楚他主要想听的不是两阶段提交而是看你会不会在分布式场景下放弃强一致、拥抱最终一致性。我的回答是不要用强一致方案代价太大协调者的高可用和性能损耗在业务上完全不划算。用本地消息表加定时任务补偿的方案业务操作和消息发送放在同一个本地事务里事务提交后消息就一定存在了再通过一个定时任务扫描没有完成投递的消息重新投递给MQ。下游消费方负责幂等处理失败了靠重试收敛。还可以用支持事务消息能力的MQ来实现可靠投递它的原理和本地消息表类似区别是消息发送被封装进了Broker的事务机制里。选择哪个方案取决于现有中间件体系但核心思想都是把业务操作和消息投递的原子性保证住之后靠消息和重试把最终一致性做出来。2.4 设计中容易忽略的状态机细节有一点是面试时不会深究、但上线后一定会踩的坑状态机别设计成带环的。比如SUCCESS之后还能回到PENDING或者FAILED之后还能自动跳成PROCESSING这种设计会让补偿任务反复处理脏数据做调度的人会被搞疯。正确的做法是状态只能向前流转终态不可逆。失败重试要单独记录在retry_count里task表还要预留last_error字段。否则线上看到任务卡住你连它上次出错的原因都看不到排查成本会很高。提示异步任务系统设计的三个关键点就是可靠投递、幂等消费、最终收敛。能把这条链路讲顺分布式事务这道题基本就稳了。3. AI能力嵌入音视频微服务的三种典型落地方案3.1 独立内容审核服务同步接口加异步任务混合编排聊完转码面试官把话题引到了AI上“既然提到了审核你讲讲审核服务怎么设计”内容审核天然要调用AI模型抽帧做图像识别、OCR识别文字、音频转写后做语义识别。审核结果的时效性要求很有意思如果允许先发布后审核那审核是异步任务结果回来后再处理违规内容如果要求先审后发那审核就成了发布链路的前置依赖。我当时给出的方案是混合编排。审核服务对外提供一个同步接口实际上调用轻量级模型做快速判断业务后端在发布前调用一次明显违规的直接拦截深度审核则通过异步任务完成对画面和音频抽样后送模型结果通过状态回调或者业务轮询更新。这样既不会阻塞上传链路的整体吞吐也能在入口处挡住大部分明显问题。3.2 封面、字幕、标签生成必须拆成独立消费组的异步编排除了审核AI在音视频场景里还有很多产出型任务比如自动生成封面、自动字幕、智能分类打标签。这些任务有一个共同特点可以接受延迟用户上传完视频不会指望一秒内出封面几分钟内有结果就很合理。所以这类任务更适合走异步流水线上传完成投递MQ智能处理编排服务消费后分别把任务派发给封面生成、字幕识别、标签分类三个不同消费组。为什么要拆成独立消费组因为它们执行时间差异很大封面可能只要5秒字幕转写可能30秒标签分类可能10秒。如果共用同一个消费队列一个慢任务会拖慢整个链路。还可以给任务加优先级付费用户的视频优先处理。这种细节工程师在选型Review里经常会纠结但在面试里能主动提出来是一个比较加分的信号。3.3 冷启动和GPU资源管理的坑面试官在这里追问了一个很实际的问题“如果瞬间来了20个新视频20个审核任务同时进审核服务每个任务都触发模型加载会发生什么”答案是冷启动雪崩。GPU显存有限20个模型实例同时加载显存会直接打满模型加载本身要几秒到几十秒任务几乎全部超时超时后的重试又加重压力最终把审核服务整个拖垮。正确的做法我总结成三句话模型常驻内存绝对不能边推理边加载推理服务独立部署用队列控制并发把GPU当成一个有界资源池服务启动时完成模型预热并预留一定的显存buffer。如果是多种模型并存还要考虑模型分片或者按任务类型动态调度但面试阶段能把前三点讲清楚已经能体现很强的工程意识了。4. 直播与实时互动场景下的高并发治理4.1 大V开播瞬间的流量洪峰先落在哪一层第四部分面试官突然把场景移到了直播“假设产品里还有直播功能大V开播瞬间十万人同时进直播间哪个组件会最先扛不住”我第一反应是注册发现。服务扩容不是瞬时的但流量是瞬时的如果开播前没有提前扩容注册中心会瞬间涌入大量服务实例的注册请求下游消费者也要重新拉取服务列表可能把整个集群搞出抖动。治理手段要分层准备网关层做连接数限制和鉴权拦截挡住无效流量接入层用限流组件给每个直播间的进入加上阈值业务层提前配置熔断降级规则比如点赞数、评论数这类非核心链路在压力过大时降级写入事后再快速扩容。限流组件的规则最好是预先配置不要等故障发生了再去后台点鼠标那个时间窗口足够导致一次线上事故。4.2 播放地址、在线状态和热点Key的缓存设计面试官接着追问“聊聊Redis你在音视频场景里怎么用缓存”我举了播放地址的例子。CDN签名地址有效期比较短每次播放都要经过鉴权服务重新生成短视频场景的播放量又非常大所以播放地址是典型的缓存热点。但缓存和数据库的一致性问题躲不开这里要特别注意顺序先更新DB再删缓存而不是先删缓存再更新DB。原因是并发场景下先删缓存会导致旧数据在你删完缓存之后又被写回去形成长期的脏缓存。先更新DB再删缓存最坏的情况也只是删除前短暂读到旧值可以通过延迟双删和删除重试来兜底。更成熟的做法是订阅数据库的变更日志异步监听数据变更后主动清理对应缓存让缓存删除不再依赖业务代码。4.3 接口P99延迟突增的排查链路最后一道题是经典排查题“线上接口P99延迟从50ms涨到500ms你怎么查”我给的排查顺序是先看CPU和内存指标确认有没有GC抖动或线程池打满再看日志里的耗时分布定位是网络层、数据库还是下游依赖然后看慢SQL和数据库连接池是否打满再看下游服务的RT有没有异常最后用链路追踪工具看全链路耗时分布。面试官追问了一句“JVM为什么会导致接口变慢”我解释说Full GC会触发Stop The World暂停时间可能是几百毫秒接口自然超时。线程池打满后大量任务排队等待请求堆积也会导致延迟快速上升。真正出问题的时候不要急着调JVM参数先搞清楚卡顿是哪个原因造成的。如果是对象分配过多导致GC频繁优先改代码逻辑和对象复用而不是在启动参数上调堆内存。5. 面试复盘三个让我卡壳的追问与完整排查路径5.1 追问一缓存和数据库的一致性我答浅了播放地址那道题我只说了“先更新DB再删缓存”面试官立刻反问“删缓存失败了怎么办”我承认第一次回答不够深。正确做法是删除操作要有重试机制可以发一条延迟消息让消费者再删一次就是延迟双删的思路。更稳妥的是在更新DB后通过订阅机制异步清理让缓存删除不依赖业务代码的即时执行。回到面试现场面试官主要想听你能不能想到“删除动作也可能失败失败以后必须有兜底”这个层面。这个坑在工程上非常常见因为缓存删除经常被当成零成本操作。5.2 追问二一条审核任务卡在pending几小时怎么排查这道题当时我答得比较散重新整理成了完整链路排查节点检查项常用手段消息队列消费积压、死信看堆积曲线、消费者数量Worker日志超时、重试、异常看重试次数是否超过阈值GPU资源推理排队、显存看推理耗时与GPU利用率数据库状态锁、死锁看锁等待和死锁日志发布记录最近变更看上一次发版内容和时间正确的顺序是先看最近有没有代码发布线上异常大多由变更引起再看消息队列有没有积压积压说明消费端跟不上了排队看消费日志找到失败的具体原因然后看AI推理服务的耗时和GPU利用率确认是资源问题还是模型性能退化最后查数据库锁和阻塞。所有环节都查不到才考虑状态机被异常分支卡住这时候需要提供一个管理员手工修正终态的任务接口作为兜底。这个排查顺序是面试官最后认可的但“先查发布”那步是他点出来的我当时确实没往这个方向想。5.3 追问三十万人同时在线的互动直播整体架构怎么做最后一道是开放题面试官要求我口述一套完整方案。我的回答链路是接入层用网关支撑长连接比如WebSocket在线状态用Redis维护心跳状态变更后通过消息广播通知相关房间消息分发采用推拉结合弹幕延迟要求高用长连接推送离线礼物列表用轮询拉取。评论系统为了保证有序性每个房间维护一个单调递增的sequence用户发送的消息先分配序号再广播客户端按序号展示。面试官追问“读扩散和写扩散怎么选”我回答互动消息天然有写多读少的特点消息本体只保存一份但最近200条用Redis的List缓存进房间直接拉取最近消息不重复扩散。在十万人级别的实时场景下这个方案已经足够稳定。我个人在这场面试里踩过最大的坑就是太习惯把知识背成独立模块遇到具体场景时反而串不起来。经过这件事我整理了自己的面试准备方法不再背“微服务组件清单”而是抓住一个真实业务场景从服务拆分讲到状态一致性再讲到AI集成和高并发治理一条链路过到底。最后分享一个小技巧面试前准备一页自己画过的架构图手绘版本就行重要的不是画得多标准而是你必须能把每一个框、每一条线背后的设计理由讲出来。面试官要的从来不是标准答案而是你脑子里那套经过验证的判断逻辑。
Java高级面试实录：短视频后端架构设计与微服务拆分复盘
今年在准备Java高级岗位面试时我明显感觉到面试风格变了面试官不再拿“微服务有哪些组件”“Spring Cloud和Dubbo怎么选”这种背八股就能过的题来开头而是直接给一个具体的业务场景让你现场做架构设计并接受连续追问。最让我印象深刻的一场是一道音视频题目。面试官说假设我们要做一个短视频后端用户上传、系统转码、内容审核、CDN分发、播放还有评论互动你来设计后端架构。AI能力应该放在哪个环节哪些服务会先扛不住消息队列会出现在哪里这几乎把Java、微服务、AI三个方向的所有核心考点一网打尽——从服务拆分原则、分布式事务、幂等消费到AI模型推理的异步编排和高并发治理全部在一个场景里串了起来。这篇文章就是那场面试的完整实录包括我当时的第一版回答、面试官连续追问的原文回忆以及我事后重新梳理过的正确答案和排查路径。如果你也正在准备Java或微服务方向的面试或者对音视频系统的工程化设计感兴趣这篇复盘应该能帮你少走不少弯路。1. 一场围绕“短视频后端怎么拆”的面试开场1.1 为什么音视频场景成了微服务面试的高频考题面试官选场景不是随便挑的。音视频业务和普通电商、后台管理系统最大的区别在于它的链路特别长而且每一段的负载特征完全不同。上传阶段是网络IO密集要处理大文件分片、断点续传和带宽占用转码阶段是CPU密集一次1080P转码可能要吃掉好几个核的算力耗时从几十秒到几分钟不等审核阶段要调用AI视觉模型和语音识别模型依赖GPU推理分发阶段要考虑CDN边缘节点和播放鉴权互动阶段又是典型的高并发写多读少场景。一个短视频后端几乎把分布式系统里所有的经典负载类型都装进去了。这就让“微服务拆分”这个老问题有了真正的深度。面试官想听的不是“按模块拆”“按功能拆”这种正确但没用的废话而是想确认你有没有想清楚哪些服务应该独立部署、独立扩缩容、独立承担故障。1.2 我第一版的服务拆分方案当时我在白板上画了一张草图大致长这样视频上传服务负责接收客户端分片上传、校验文件元信息、生成上传凭证。对象存储层保存原始视频和转码产物逻辑上独立。视频元数据服务保存标题、封面、时长、码率、上传者、状态等结构化信息。转码编排服务负责创建转码任务、管理任务状态机、调度工作节点。转码工作节点真正执行转码的Worker按CPU资源水平扩展。内容审核服务对接AI模型对画面、音频、文本做风险识别。视频分发服务负责写CDN配置、生成播放地址、处理缓存刷新。播放网关负责播放鉴权、防盗链、限流。互动评论服务独立服务因为读写模型和主链路差异很大。面试官看了这个拆分点了点头但立刻追问了一句“转码编排服务和工作节点拆成两个是不是过度设计了”我当时心里一顿然后回答编排服务是控制面工作节点是数据面。控制面需要管理任务状态、失败重试、优先级调度数据面执行引擎要做得尽量简单只负责拉取任务、执行转码、上报进度。这样编排服务可以做成无状态快速水平扩展工作节点也可以在流量高峰时动态扩容甚至在任务波动大的阶段用按量付费实例。控制面和数据面分离这个思路在转码这类任务型系统里是经典做法。1.3 重新审视服务边界、故障隔离与扩展维度面试回来后我把这个拆分重新复盘了一遍把判断逻辑浓缩成一张表服务主要负载类型扩展维度故障影响面上传服务网络IO、大文件带宽、连接数影响视频采集转码WorkerCPU密集型计算计算资源转码延迟变大内容审核服务GPU推理GPU资源合规风险上升元数据服务读写混合CPU、数据库主链路不可用播放网关网络IO、QPS带宽、网关数量播放体验下降拆分的核心逻辑是只在代码层拆分没有意义必须让故障隔离和弹性扩展两个维度都真正获益才值得拆成独立服务。如果拆完之后大家还是共用同一个数据库、同一套缓存、同一个集群那只是把单体代码搬到了多个进程里没解决任何实际问题。2. 转码任务状态一致性被连续追问的三级链路2.1 第一轮追问任务状态机和消息队列的可靠性拆完服务之后面试官顺着转码链路往下走问了一个看似基础的问题“上传完成之后转码任务你是怎么触发和跟踪的”我的回答是转码绝对不能同步执行因为耗时太长必须走异步任务。任务表放在独立的库或表中字段至少包含task_id、video_id、status、progress、retry_count、create_time、update_time。状态流转是PENDING到PROCESSING再流转到SUCCESS或FAILED失败后按最大次数重试。触发方式很清楚上传服务在文件上传成功后投递一条消息到MQ转码编排服务消费消息后创建任务记录再调度Worker执行。面试官马上追问“如果MQ挂了或者消息丢了怎么办”这个问题要讲的是消息的可靠投递链路缺一个环节都不够严谨生产端要开启发送确认消息发出去之后必须收到Broker的确认响应没确认就本地重试Broker端要开持久化保证进程重启后消息不丢消费端要做手动ack业务处理成功之后再提交offset避免处理到一半进程挂掉导致消息被误认为已消费。转码任务不是高吞吐低延迟的类型它有明显的可靠性要求所以这些设置牺牲一点吞吐量完全值得。2.2 第二轮追问重复消费怎么处理幂等设计怎么做面试官没停接着问“如果同一个任务被消费了两次你怎么办”真实的场景是消费端把任务处理完了业务数据已经更新但在提交offset之前进程挂了MQ会重新投递这条消息。这时候如果没有幂等保护同一个转码任务可能被创建两次Worker可能被重复调度最后结果就是资源浪费和状态错乱。幂等设计要分三层做。第一层处理前先查询任务状态如果已经是终态就直接跳过第二层在任务表对task_id或者video_id加唯一约束靠数据库拒绝重复插入第三层如果是更复杂的跨服务重复消费场景可以单独建一张消息消费记录表用消息ID做唯一索引。幂等的本质不是“消息只被投递一次”而是“重复处理业务数据时最终结果和一次处理完全一致”。这个回答面试官认可了但他又补了一个坑“幂等判断本身不是原子操作如果两个请求同时进来怎么办”我补充说查询状态和更新状态要放在同一个数据库事务里通过更新语句的行锁或者唯一索引冲突来保证只有一个请求能真正执行下去。2.3 第三轮追问分布式事务怎么取舍到这里难度明显上了一个台阶。面试官问“转码成功之后需要更新任务状态、更新视频可播放状态、写一条播放记录、发起审核任务。这些操作分布在不同的库甚至不同的服务里分布式事务怎么保证”我当时心里很清楚他主要想听的不是两阶段提交而是看你会不会在分布式场景下放弃强一致、拥抱最终一致性。我的回答是不要用强一致方案代价太大协调者的高可用和性能损耗在业务上完全不划算。用本地消息表加定时任务补偿的方案业务操作和消息发送放在同一个本地事务里事务提交后消息就一定存在了再通过一个定时任务扫描没有完成投递的消息重新投递给MQ。下游消费方负责幂等处理失败了靠重试收敛。还可以用支持事务消息能力的MQ来实现可靠投递它的原理和本地消息表类似区别是消息发送被封装进了Broker的事务机制里。选择哪个方案取决于现有中间件体系但核心思想都是把业务操作和消息投递的原子性保证住之后靠消息和重试把最终一致性做出来。2.4 设计中容易忽略的状态机细节有一点是面试时不会深究、但上线后一定会踩的坑状态机别设计成带环的。比如SUCCESS之后还能回到PENDING或者FAILED之后还能自动跳成PROCESSING这种设计会让补偿任务反复处理脏数据做调度的人会被搞疯。正确的做法是状态只能向前流转终态不可逆。失败重试要单独记录在retry_count里task表还要预留last_error字段。否则线上看到任务卡住你连它上次出错的原因都看不到排查成本会很高。提示异步任务系统设计的三个关键点就是可靠投递、幂等消费、最终收敛。能把这条链路讲顺分布式事务这道题基本就稳了。3. AI能力嵌入音视频微服务的三种典型落地方案3.1 独立内容审核服务同步接口加异步任务混合编排聊完转码面试官把话题引到了AI上“既然提到了审核你讲讲审核服务怎么设计”内容审核天然要调用AI模型抽帧做图像识别、OCR识别文字、音频转写后做语义识别。审核结果的时效性要求很有意思如果允许先发布后审核那审核是异步任务结果回来后再处理违规内容如果要求先审后发那审核就成了发布链路的前置依赖。我当时给出的方案是混合编排。审核服务对外提供一个同步接口实际上调用轻量级模型做快速判断业务后端在发布前调用一次明显违规的直接拦截深度审核则通过异步任务完成对画面和音频抽样后送模型结果通过状态回调或者业务轮询更新。这样既不会阻塞上传链路的整体吞吐也能在入口处挡住大部分明显问题。3.2 封面、字幕、标签生成必须拆成独立消费组的异步编排除了审核AI在音视频场景里还有很多产出型任务比如自动生成封面、自动字幕、智能分类打标签。这些任务有一个共同特点可以接受延迟用户上传完视频不会指望一秒内出封面几分钟内有结果就很合理。所以这类任务更适合走异步流水线上传完成投递MQ智能处理编排服务消费后分别把任务派发给封面生成、字幕识别、标签分类三个不同消费组。为什么要拆成独立消费组因为它们执行时间差异很大封面可能只要5秒字幕转写可能30秒标签分类可能10秒。如果共用同一个消费队列一个慢任务会拖慢整个链路。还可以给任务加优先级付费用户的视频优先处理。这种细节工程师在选型Review里经常会纠结但在面试里能主动提出来是一个比较加分的信号。3.3 冷启动和GPU资源管理的坑面试官在这里追问了一个很实际的问题“如果瞬间来了20个新视频20个审核任务同时进审核服务每个任务都触发模型加载会发生什么”答案是冷启动雪崩。GPU显存有限20个模型实例同时加载显存会直接打满模型加载本身要几秒到几十秒任务几乎全部超时超时后的重试又加重压力最终把审核服务整个拖垮。正确的做法我总结成三句话模型常驻内存绝对不能边推理边加载推理服务独立部署用队列控制并发把GPU当成一个有界资源池服务启动时完成模型预热并预留一定的显存buffer。如果是多种模型并存还要考虑模型分片或者按任务类型动态调度但面试阶段能把前三点讲清楚已经能体现很强的工程意识了。4. 直播与实时互动场景下的高并发治理4.1 大V开播瞬间的流量洪峰先落在哪一层第四部分面试官突然把场景移到了直播“假设产品里还有直播功能大V开播瞬间十万人同时进直播间哪个组件会最先扛不住”我第一反应是注册发现。服务扩容不是瞬时的但流量是瞬时的如果开播前没有提前扩容注册中心会瞬间涌入大量服务实例的注册请求下游消费者也要重新拉取服务列表可能把整个集群搞出抖动。治理手段要分层准备网关层做连接数限制和鉴权拦截挡住无效流量接入层用限流组件给每个直播间的进入加上阈值业务层提前配置熔断降级规则比如点赞数、评论数这类非核心链路在压力过大时降级写入事后再快速扩容。限流组件的规则最好是预先配置不要等故障发生了再去后台点鼠标那个时间窗口足够导致一次线上事故。4.2 播放地址、在线状态和热点Key的缓存设计面试官接着追问“聊聊Redis你在音视频场景里怎么用缓存”我举了播放地址的例子。CDN签名地址有效期比较短每次播放都要经过鉴权服务重新生成短视频场景的播放量又非常大所以播放地址是典型的缓存热点。但缓存和数据库的一致性问题躲不开这里要特别注意顺序先更新DB再删缓存而不是先删缓存再更新DB。原因是并发场景下先删缓存会导致旧数据在你删完缓存之后又被写回去形成长期的脏缓存。先更新DB再删缓存最坏的情况也只是删除前短暂读到旧值可以通过延迟双删和删除重试来兜底。更成熟的做法是订阅数据库的变更日志异步监听数据变更后主动清理对应缓存让缓存删除不再依赖业务代码。4.3 接口P99延迟突增的排查链路最后一道题是经典排查题“线上接口P99延迟从50ms涨到500ms你怎么查”我给的排查顺序是先看CPU和内存指标确认有没有GC抖动或线程池打满再看日志里的耗时分布定位是网络层、数据库还是下游依赖然后看慢SQL和数据库连接池是否打满再看下游服务的RT有没有异常最后用链路追踪工具看全链路耗时分布。面试官追问了一句“JVM为什么会导致接口变慢”我解释说Full GC会触发Stop The World暂停时间可能是几百毫秒接口自然超时。线程池打满后大量任务排队等待请求堆积也会导致延迟快速上升。真正出问题的时候不要急着调JVM参数先搞清楚卡顿是哪个原因造成的。如果是对象分配过多导致GC频繁优先改代码逻辑和对象复用而不是在启动参数上调堆内存。5. 面试复盘三个让我卡壳的追问与完整排查路径5.1 追问一缓存和数据库的一致性我答浅了播放地址那道题我只说了“先更新DB再删缓存”面试官立刻反问“删缓存失败了怎么办”我承认第一次回答不够深。正确做法是删除操作要有重试机制可以发一条延迟消息让消费者再删一次就是延迟双删的思路。更稳妥的是在更新DB后通过订阅机制异步清理让缓存删除不依赖业务代码的即时执行。回到面试现场面试官主要想听你能不能想到“删除动作也可能失败失败以后必须有兜底”这个层面。这个坑在工程上非常常见因为缓存删除经常被当成零成本操作。5.2 追问二一条审核任务卡在pending几小时怎么排查这道题当时我答得比较散重新整理成了完整链路排查节点检查项常用手段消息队列消费积压、死信看堆积曲线、消费者数量Worker日志超时、重试、异常看重试次数是否超过阈值GPU资源推理排队、显存看推理耗时与GPU利用率数据库状态锁、死锁看锁等待和死锁日志发布记录最近变更看上一次发版内容和时间正确的顺序是先看最近有没有代码发布线上异常大多由变更引起再看消息队列有没有积压积压说明消费端跟不上了排队看消费日志找到失败的具体原因然后看AI推理服务的耗时和GPU利用率确认是资源问题还是模型性能退化最后查数据库锁和阻塞。所有环节都查不到才考虑状态机被异常分支卡住这时候需要提供一个管理员手工修正终态的任务接口作为兜底。这个排查顺序是面试官最后认可的但“先查发布”那步是他点出来的我当时确实没往这个方向想。5.3 追问三十万人同时在线的互动直播整体架构怎么做最后一道是开放题面试官要求我口述一套完整方案。我的回答链路是接入层用网关支撑长连接比如WebSocket在线状态用Redis维护心跳状态变更后通过消息广播通知相关房间消息分发采用推拉结合弹幕延迟要求高用长连接推送离线礼物列表用轮询拉取。评论系统为了保证有序性每个房间维护一个单调递增的sequence用户发送的消息先分配序号再广播客户端按序号展示。面试官追问“读扩散和写扩散怎么选”我回答互动消息天然有写多读少的特点消息本体只保存一份但最近200条用Redis的List缓存进房间直接拉取最近消息不重复扩散。在十万人级别的实时场景下这个方案已经足够稳定。我个人在这场面试里踩过最大的坑就是太习惯把知识背成独立模块遇到具体场景时反而串不起来。经过这件事我整理了自己的面试准备方法不再背“微服务组件清单”而是抓住一个真实业务场景从服务拆分讲到状态一致性再讲到AI集成和高并发治理一条链路过到底。最后分享一个小技巧面试前准备一页自己画过的架构图手绘版本就行重要的不是画得多标准而是你必须能把每一个框、每一条线背后的设计理由讲出来。面试官要的从来不是标准答案而是你脑子里那套经过验证的判断逻辑。
