企业官网建设流程全解析

我随便搜了搜“大厂Java面试 音视频 Spring Boot Redis”这类面经，发现一个特别典型的通病：大多数候选人都在背 Spring Boot 的自动装配、背 Redis 的数据类型和持久化策略，一聊到“到底怎么用在音视频场景里”就开始含糊其辞，只能挤出几句“用 Redis 做缓存”“用 Spring Boot 写接口”这种不痛不痒的话。

这其实很可惜。音视频场景恰恰是面试官最想听到“深度”的领域之一——它不像普通 CRUD 那样谁都能聊两句，它有明确的业务痛点、有清晰的技术约束、有能把 Redis 各种高级特性串起来用的天然土壤。这篇文章我就从面试官的视角，把这个话题拆开揉碎，讲清楚在音视频业务里，Spring Boot 和 Redis 到底是怎么配合的，以及你该怎么把这段经历讲成加分项，而不是背课文。

1. 音视频场景的特殊性：这才是面试官真正想听的“题眼”

1.1 为什么不能拿普通业务系统的思维去套音视频

先抛一个很反直觉的结论：音视频场景下的 Redis 用法，和普通电商、社交业务里的用法，底层逻辑有本质区别。

普通业务系统里，Redis 扮演的基本是“加速层”角色——把数据库里查出来的热点数据塞进缓存，扛住读流量。这个逻辑没有错，但放到音视频场景里，你会发现一个尴尬的事实：音视频的核心数据（视频文件本身、音频流）几乎不会塞进 Redis。一个 2GB 的视频文件你塞进 Redis 试试？内存直接爆炸不说，序列化反序列化的开销都会让你怀疑人生。

那 Redis 在音视频场景里到底是干嘛的？

答案一句话就能说完：它管的是“围绕媒体文件的那一圈元数据和状态”，而不是媒体文件本身。

我举个例子你就明白了。某视频平台上传了一个 4K 视频，后端要做的事情包括：转码、切片、生成封面、抽帧、审核、更新播放地址。这些步骤里，视频文件本身是躺在对象存储里的，但“这个视频现在转码到哪一步了”“切片任务有没有失败”“封面图生成好了没有”“播放地址什么时候可以对外暴露”——这些状态信息，全部要有一个地方实时记录、实时查询、实时更新。数据库当然能做，但问题是音视频处理链路里的状态变化极其频繁，如果每转码一个分片都写一次数据库，数据库的压力和响应速度都扛不住。

1.2 音视频场景真正压垮系统的四个问题

面试官聊到音视频，表面上在问技术，其实是在问你对四个问题的理解有多深：

第一，长耗时任务的状态追踪。一个高清视频转码，快则几十秒，慢则几分钟甚至更久。在这么长的时间窗口里，用户可能反复刷新页面查进度，后端需要有一个高性能的“当前状态查询”机制。用数据库轮询？几千个用户同时刷新，数据库连接池就废了。

第二，任务调度和排队。转码任务不是来一个处理一个的，处理器的资源是有限的，大量任务涌进来必须排队。这个队列用什么做？怎么保证任务不丢、不重复消费、失败还能重试？

第三，热点数据的读取放大。一个爆款视频上线，一秒内几万次播放请求进来，用户的播放器会先请求视频的“元信息”——分辨率列表、码率、时长、封面图。这些数据量不大，但访问频率极高，而且访问模式是典型的“读多写少”，写一次，读百万次。

第四，分布式环境下的并发一致性。转码服务可能是多个实例并行部署的，多个实例同时处理同一个视频任务的不同分片，大家都在更新同一个任务的进度，怎么保证不冲突？怎么保证任务不会被两个实例同时抢走？

这四个问题，每个都是一道深水区考题。而 Spring Boot + Redis 这套组合，恰好能给出非常漂亮的答案——前提是你要真懂怎么配。

2. 转码任务剖析：用 Redis 实现可靠的异步任务状态机

2.1 从“数据库轮询”到“Redis 状态机”的进化逻辑

先说说大多数人第一版是怎么做的，因为只有理解了错误做法，你才知道正确做法好在哪。

很多团队刚开始做音视频转码时，习惯把任务状态直接怼进 MySQL 表里，字段无非就是video_id、status、progress、update_time。前端每隔两秒调一次接口查进度，后端每次查一次数据库。听起来没什么问题，但一旦流量上来就露馅了：

• 数据库行锁竞争，多个请求同时更新同一行时性能骤降；
• 查询压力集中在热点视频上，一条WHERE video_id = ?的 SQL 被几千个用户同时打，慢查询日志刷屏；
• 状态更新频率高，Binlog 量暴涨，DBA 半夜打电话找你。

Redis 的介入，不是替代数据库，而是在数据库前面加了一层“状态加速层”。核心思路是：任务的全生命周期状态——等待中、转码中、切片中、完成、失败、重试中——全部用 Redis 的 Hash 结构维护。Hash 的好处是你可以把多个字段放在同一个 key 下，一次HGETALL就把任务的进度、当前阶段、错误信息全拿回来，网络开销极小。

我参与过的某播放器后端项目，转码状态就是直接用 Hash 存的，key 命名类似task:video:{videoId}，字段包括stage（当前阶段）、progress（0-100 整数）、message（错误信息或描述）。查询进度时，后端接口直接从 RedisHGETALL，响应耗时从原来数据库方案的 50ms 左右压到了 1ms 以内，而且数据库的压力几乎归零。

2.2 状态流转怎么设计，才能让面试官觉得你有全局观

光会用 Hash 还不够，面试官一定会追问：“状态流转过程中，失败重试、超时、并发更新，这些问题你怎么处理？”

这里必须引入状态机的思维。转码任务的状态不是随便改的，它是有严格流向的：

PENDING（排队中）→ PROCESSING（处理中）→ SUCCEEDED（成功） ↘ FAILED（失败）→ PENDING（重试）

用 Redis 实现状态机，技术上最核心的一个原则是：状态更新必须用 Lua 脚本或事务保证原子性，不能用“先 GET 再 SET”这种两步操作。举个例子，转码分片 A 完成了，回调说“进度更新到 30%”，但同一秒内分片 B 也完成了，回调说“进度更新到 60%”，如果这两个回调同时到达，服务端先读了旧的 progress，然后各自 SET 自己算好的值，最后结果可能是 30% 覆盖了 60%，进度倒退了。这在音视频处理里是绝对不能接受的。

我当时的做法是写了一段 Lua 脚本，把“读旧值、比较新值、更新、设置过期时间”四步操作合并成一段原子执行，Redis 单线程特性保证了脚本执行期间不可能被其他命令插入。面试官听到这个细节，往往会眼睛一亮，因为他知道你不只是用过 Redis，而是真的踩过并发更新的坑。

还有一个实战里特别容易忽略的点：任务超时和死信处理。转码任务可能因为底层机器宕机而无缘无故“消失”，既没有成功回调，也没有失败回调。这种情况必须有一个兜底机制。我当时用的是 Redis 的延迟队列思路——任务进入 PROCESSING 状态时，同时往一个 ZSet 里写入一个“超时检查项”，score 设为当前时间加上超时上限（比如 10 分钟）。后台有个定时任务每 30 秒扫一次这个 ZSet，发现 score 小于当前时间的任务，就认为它超时了，把它重新塞回 PENDING 队列，并记录重试次数，超过三次的进入人工处理队列。这也是 Redis 在音视频场景里很经典的一个玩法，面试时讲出来，比你背十个数据结构定义都管用。

2.3 延迟队列的几种实现，以及我为什么推荐 ZSet + 定时任务

聊到延迟任务，很多人第一反应是 RabbitMQ 的延迟消息或者 RocketMQ 的定时消息，这个思路没错。但有些音视频团队的中间件选型很轻，不想为一个“超时检查”就额外引入一套 MQ，这时候 Redis 完全可以顶上。

我实践下来最稳的组合就是ZSet + 定时扫描：

• 生产者往 ZSet 里写入任务 ID，score 设置为期望执行时间的时间戳；
• 消费者（定时任务）用ZRANGEBYSCORE min max LIMIT 0 100取出到期任务，然后用ZREM删除；
• 为了防止任务被多个消费者同时取走，取任务和删任务要放在同一个 Lua 脚本里执行，保证原子性。

这个方案的精度虽然不如 MQ 的毫秒级，但音视频转码的超时检查本身就不是高精度场景，误差几十秒完全无所谓。面试官如果问“为什么不用 XXL-JOB 或者 MQ”，你就可以从“团队技术栈轻量化”“Redis 本来就部署了，零额外成本”这两个角度回应，显得你是有取舍判断力的，而不是什么火用什么。

3. 播放链路的 Redis 缓存设计：元数据加速与预取策略

3.1 为什么这一层缓存能让播放器秒开

转码任务做完，视频上线了，这时候第二道考题来了：高并发播放场景下，怎么保证每一个用户点开视频都能快速拉到播放元数据？

播放器一般会先请求一个“播放信息”接口，返回内容包括：视频的清晰度列表（1080P/720P/480P）、对应码率、时长、封面图 URL、播放地址列表。这个接口的特点是：

• 读多写极少（视频上传后元数据基本不变，只有上线和下架两种状态变化）；
• 单次数据量小（几 KB 到几十 KB）；
• 高频访问（热门视频的元数据接口 QPS 可能是几十万级别）。

这种场景，就是 Redis 字符串缓存的标准用法。我当时的设计很简单，key 就用meta:video:{videoId}，value 直接用 JSON 字符串。但这里有个关键细节：缓存一定要设置合理的 TTL，而不是永久有效。因为视频可能被下架、可能被更新（比如重新转码后清晰度列表变了），如果一直不失效，用户会看到已经下架的“幽灵视频”还能播放。我当时给的 TTL 是 10 分钟，配合一个“主动失效”机制——视频状态变更时，后端主动调用DEL删除对应 key，让下一次请求回源数据库重建缓存。

这个“TTL + 主动删除”的双保险策略，比单用 TTL 或者单用主动删除都可靠，面试时值得重点提。

3.2 热点视频与缓存穿透：布隆过滤器不是万能的

缓存穿透这个话题很老，但音视频场景里它有新变种。普通电商场景，穿透是因为有人拿不存在的商品 ID 刷接口；音视频场景里，穿透的高发场景是视频刚上传还没转码完成时，用户就拿到了播放地址并开始请求元数据。

我遇到的情况是这样的：用户上传视频后，客户端会先拿到一个“处理中”的占位标识，但有些客户端写得不严谨，直接拿这个占位标识去请求元数据接口，后端查不到，缓存也查不到，每次都打到数据库。一次两次无所谓，可一旦有 bot 或者异常客户端循环请求，数据库就遭殃了。

解决穿透，业界通用方案是布隆过滤器或空值缓存。我当时的取舍是：在元数据查询这层，用空值缓存就行，不引入布隆过滤器。原因很简单——音视频元数据的 key 空间虽然不小，但无效请求的 pattern 很集中（基本都是那些“处理中”的占位标识），不是随机攻击。对这种情况，把“查不到”的结果也缓存起来，TTL 设个 30 秒，就能挡住绝大部分穿透流量。布隆过滤器在这种场景属于“杀鸡用牛刀”，还白白增加维护成本。

面试时能把“什么时候用布隆过滤器、什么时候空值缓存就够了”讲清楚，比单纯背“穿透的解决方案有布隆过滤器”要高级得多。

3.3 预取策略：从“用户等了才给”到“猜到用户要什么”

最后一个加分项是预取。这个思路源于我对播放器日志的观察：用户点开一个视频，很大概率会在前几秒内切换清晰度，或者拖进度条。如果每次切换都重新请求一次后端拿到对应分片的地址，那延迟就会很明显。

我当时的优化方案是：用户第一次请求播放元数据时，后端不但返回当前所选清晰度的播放地址，还顺带把其他清晰度的地址、以及前几分钟的分片索引一并塞进响应里。播放器本地缓存这些信息，切换清晰度时直接本地切换，根本不用再打后端。这个优化把播放器“首次起播 + 首切清晰度”的平均耗时降了将近一半。

这套方案落到 Redis 层面，其实是做了一个“两级缓存”：第一级是后端 Redis 缓存元数据，第二级是客户端本地缓存。面试时可以把这个案例讲出来，它会证明你不只是会写接口，而是真的会从整个播放链路的视角来设计缓存。

4. 异步处理架构：Spring Boot 下 Redis 队列与消息机制的落地选择

4.1 为什么 Spring Boot 项目里，Redis 队列常常比 MQ 更顺手

聊完缓存，回到 Spring Boot 的编程模型。音视频后端里有大量“发出去就不用管”的任务：转码完成后的封面生成、审核结果回调、用户行为埋点上报。这些任务的特点是执行时间短、失败容忍度高、不需要严格的有序性。用重型 MQ 当然可以，但很多中大型项目的实际选择是：这些轻量任务直接用 Redis 列表（List）当队列用。

我在某跨平台系统中就用 Redis List 做过一个埋点上报队列。生产者用LPUSH往队列塞消息，消费者用BRPOP阻塞读取，为了保障高可用，消费端是 Spring Boot 里一个用@Scheduled标注的定时任务线程池去BRPOP。说实话，这套方案在上游 QPS 不超过几千的时候非常稳定，代码量也小，不到 50 行就搞定了一个“准消息队列”。

当然它也有明显的短板：消息可能丢失（断电时 List 里已取未确认的消息无法找回）、消费速度跟不上时消息会积压（List 本身没有堆积告警）。所以我给团队定了一个原则：最终一致性强、丢了也能重新生成的异步任务用 Redis 队列；不能丢、必须严格确认的任务老老实实上 MQ。这个取舍原则面试时直接甩出来，面试官会觉得你是有生产经验的。

4.2 Spring Boot 异步编程模型：@Async 与虚拟线程的取舍

聊到 Spring Boot，必须说说异步执行模型。音视频后端的很多操作是 IO 密集型的——调用对象存储服务下载视频、调用转码服务返回结果、调用第三方审核接口。如果用同步阻塞模型，一个请求占一个 Tomcat 线程，线程池很快就被 IO 等待耗干。

我最早期的写法是@Async注解 + 自定义线程池，把所有远程调用丢进异步线程池执行，主线程立刻返回。这个方案能解决问题，但有一个隐藏的坑：线程池的拒绝策略和队列容量设置不对，会导致大量任务被静默丢弃。我记得自己最开始设了核心线程数 10、最大线程数 50、队列容量 10000，结果高峰期任务积压到队列里，等转码服务恢复时，积压任务处理完已经是几分钟之后了，前端用户看到进度条一直不动。后来我把拒绝策略改成CallerRunsPolicy，队列容量压到 1000，宁可让调用方线程自己执行，也不能丢任务。

不过到了 2025 年再回头看，如果你的项目已经跑在 Java 21+ 上，我会优先建议你试试虚拟线程。虚拟线程的核心价值是：线程本身几乎零成本，你可以为每个请求创建一个“虚拟线程”去同步等待 IO，而不需要手动去搞异步回调。代码写起来像同步代码一样自然，性能却比平台线程池好得多。我在模拟项目里验证过，同样的转码调用服务，切换虚拟线程后代码量少了一截，吞吐量反而更高。这个点面试里聊出来，是现阶段比较少见的加分项，但你要注意，如果项目还在 Java 8 上，谈虚拟线程就是纸上谈兵，反而减分。

4.3 用 Redis 做分布式锁控制转码资源：别踩“自己锁自己”的坑

最后聊一个高频考点：分布式锁。音视频转码是典型的资源密集型操作，同一个转码服务往往会被多个任务共用。为了防止同一个视频被两个转码实例同时处理，或者防止转码并发数超过机器上限，分布式锁是不可避免的。

用 Redis 实现分布式锁最经典的方案是 SETNX + 过期时间，Redisson 也提供了现成的封装。但我想说的是一个更深的坑：锁的粒度设计。很多人一把锁直接锁整个视频 ID，处理时长可能达到几分钟，一旦持有锁的实例 GC 停顿，锁过期了，另一个实例就会拿到锁重复处理同一个视频。GC 在 Java 应用里算常见现象，所以这种“锁自动过期导致重复执行”的问题真的很常见。

我当时的设计是“两层锁”：第一层是资源锁，控制整个转码服务的最大并发数（比如全局只能同时跑 20 个转码任务），用 Redisson 的信号量实现；第二层是任务锁，控制同一个视频不能被重复处理，锁的粒度直接锁videoId，锁的过期时间设成任务预估时长的两倍，并且任务内部有“心跳续期”机制，不让锁因为长任务而提前过期。面试时能把这套嵌套锁的粒度设计讲出来，比背一百遍“SETNX 怎么用”都让人印象深刻。

5. 音视频场景的 Redis 面试追问：高频追问与应答思路拆解

5.1 “为什么不把视频文件直接存 Redis？”——考察的不是数据结构，是成本意识

这个问题出现频率极高，而且很多候选人一上来就懵了，感觉面试官在故意刁难。其实他真正想考察的是你有没有成本意识。

答案可以从三个层面拆：

第一，内存成本。Redis 是内存数据库，视频文件动辄几百 MB、几 GB，存进去内存瞬间就爆了，经济上完全不成立。第二，性能模型。Redis 的 IO 设计是为小数据量高频访问优化的，大文件的顺序读写能力反而不如专门的对象存储系统。第三，工程分工。大数据文件的高可用存储、冷热分层、边缘节点分发，这些是对象存储和 CDN 的职责，Redis 强行介入只会让系统变得更脆弱。

回答时可以顺便补一句：“我们当时是对象存储管文件本体，Redis 管文件的索引和状态，MySQL 管最终的元数据持久化，各司其职。”这句话会让面试官觉得你对架构分层有清晰认知。

5.2 “Redis 挂了怎么办？缓存雪崩怎么处理？”——先讲预防，再讲兜底

音视频场景的缓存雪崩，比普通业务场景更可怕——因为直播、热点视频的流量往往是瞬间暴涨的，缓存一旦不可用，数据库立刻被打爆，整个视频服务可能从“卡顿”演变成“完全不可用”。

我的回答顺序偏好是“先讲预防，再讲兜底”。预防层面无非三板斧：Key 的过期时间加随机抖动，防止大面积同时失效；Redis 做主从集群加哨兵，保障高可用；对于热点 Key 可以考虑逻辑过期或本地缓存兜底。兜底层面讲降级：缓存挂了以后，接口直接返回“稍后重试”的友好提示，而不是让请求一路打到数据库。直播场景下，短暂不可用比彻底雪崩更容易接受。

5.3 “如果 Redis 的内存不够了，你会怎么做？”——这题没有标准答案，考的是取舍

这个问题考的不是你背过多少淘汰策略，而是你在真实环境下的取舍能力。你可以从三个角度切入：

第一，检查内存都花在哪了。用redis-cli --bigkeys扫一遍，看看是不是有人把大对象无脑塞进了 Redis。第二，分析业务是否可以降级。比如播放元数据缓存，是不是可以缩短 TTL，或者只缓存 Top N 热点视频的元数据，冷门视频直接回源。第三，集群扩容。如果业务确实快速增长，做成 Redis Cluster 横向扩容是必然的。

最怕的回答是“那就加内存条”，显得完全没想过成本。比较好的收尾是：“内存不够本质是架构问题，不是容量问题，优先做的永远是评估每类数据是否真的该放在 Redis 里。”这句话基本能稳稳收住这道题。

5.4 编码题：“怎么用 Spring Boot + Redis 设计一个视频上传转码接口的全流程”

这道题相当于把前面所有内容串成一道系统设计题。我建议你按这个顺序答：

1. 客户端上传视频文件到对象存储，拿到fileUrl；
2. 后端创建视频记录（状态为 PENDING），返回videoId给客户端；
3. 后端把转码任务消息推入 Redis 队列（List）；
4. 转码消费者监听队列，取出任务后更新 Redis Hash 状态为 PROCESSING，然后调用转码服务；
5. 转码过程中，进度回调定时更新 Redis Hash 中的 progress 字段；
6. 转码完成后，消费者生成各清晰度播放地址，写入元数据缓存，最终把 MySQL 里的状态更新为 SUCCEEDED；
7. 客户端轮询进度接口时，后端直接读 Redis Hash，秒回进度。

这个流程看着不复杂，但你每一步都能准确说出“为什么用 Redis 做这一步”而不是无脑往里塞，面试官就满意了。

6. 给面试者的最后建议：把“用过”讲成“设计过”，才是这个题目的正确打开方式

这篇文章从头到尾读下来，你会发现我几乎没聊“Redis 数据结构有哪些”“Spring Boot 启动流程是什么”这类基础知识点，因为这些东西你自己背就行，面试官最不想听。音视频场景下的 Spring Boot 与 Redis，真正的价值在于：它逼着你去思考数据放哪里、任务怎么调度、并发怎么控制、失败怎么兜底。

我个人的体会是，准备这个题目时，不要只拿一个项目经历硬套。你可以在脑子里过三个不同类型的业务：一个长视频平台（重转码重存储）、一个短视频应用（重分发重热点）、一个直播回放系统（重实时重高并发），分别想想 Redis 在这三个场景里的侧重点有什么不同。这样做的好处是，面试官追问任何变种问题，你都能快速迁移思路。

最后分享一个我常用的“讲故事”模板：遇到这个问题前我用了什么方案 → 遇到什么瓶颈（一定要有数据，比如接口 P99 延迟从 200ms 涨到了 2 秒） → 我怎么定位到瓶颈（CPU 高还是 MySQL 慢日志） → 我选了 Redis 的哪个特性来解决（为什么选它不选别的） → 上线后效果如何（延迟降了多少、数据库压力降了多少） → 后续还踩了什么新坑。这套模板能让你的描述既有技术深度又有业务说服力，远远好过背一段标准答案。面试官也是人，他更愿意记住一个真实、具体、有波折的故事，而不是一段完美的八股文。