之前参与开发一个教学辅助系统（如实验视频点播系统），遇到的技术挑战是什么？你是如何解决的？

1) 【一句话结论】在开发教学辅助系统（实验视频点播）时，核心挑战是平衡高并发访问、低延迟播放与数据安全，通过采用HLS流媒体协议、CDN缓存、负载均衡及动态切片技术，有效解决了视频加载慢、卡顿及系统过载问题。

2) 【原理/概念讲解】视频点播系统的关键技术包括流媒体传输协议（如HTTP Live Streaming, HLS）和动态自适应流媒体（DASH），它们将视频文件切分为小片段（如1秒），按需传输，减少初始加载时间。类比：就像把大蛋糕切成小块，用户按需取，不用等整个蛋糕做好再吃。缓存技术（如CDN边缘节点缓存）通过将热门视频存储在离用户更近的节点，降低网络延迟；负载均衡则通过Nginx等工具分发请求，避免单点过载。数据安全方面，采用HTTPS加密传输，防止视频内容泄露。

3) 【对比与适用场景】

特性	HLS (HTTP Live Streaming)	DASH (Dynamic Adaptive Streaming over HTTP)
定义	Apple开发的流媒体协议，基于M3U8播放列表和TS片段	产业联盟标准，支持更多编码格式，更灵活的片段选择
特性	依赖Apple设备，播放列表固定	兼容性广，支持多种编码（如H.264, H.265），自适应码率
使用场景	移动端、Apple设备为主	通用场景，如PC、智能电视、移动端
注意点	需要M3U8列表，片段生成复杂	片段选择逻辑更复杂，需要客户端智能选择

4) 【示例】伪代码示例（视频请求处理流程）：

用户请求视频URL（如/video/实验1.mp4）  
系统检查本地缓存（Redis）：  
  若存在，直接返回缓存视频片段  
  否则，检查CDN缓存：  
    若存在，返回CDN视频片段  
    否则，调用视频切片服务：  
      1. 解析视频文件，按1秒切片生成TS片段  
      2. 将片段上传至CDN（如阿里云OSS+CDN）  
      3. 更新播放列表（M3U8）并存储至缓存  
系统返回视频片段给用户，客户端通过HLS协议解析播放  

5) 【面试口播版答案】（约90秒）
“面试官您好，我之前参与的教学辅助系统是一个实验视频点播平台。遇到的最大技术挑战是高并发下的低延迟播放与系统稳定性。具体来说，学生同时在线观看实验视频时，容易导致视频加载卡顿甚至系统崩溃。解决思路是：首先，采用HLS流媒体协议，将视频切分为1秒的小片段，按需传输，减少初始加载时间；其次，部署CDN边缘节点，将热门视频缓存到离用户最近的节点，降低网络延迟；然后，通过Nginx负载均衡分发请求，避免服务器过载；最后，结合Redis缓存播放列表，提升查询效率。通过这些措施，系统并发用户数提升了3倍，视频播放卡顿率从20%降至1%以下，用户反馈明显改善。”

6) 【追问清单】

• 问：为什么选择HLS而不是DASH？答：因为系统主要面向高校用户，设备兼容性要求高，HLS在移动端（如iPhone）支持更好，且实现相对简单。
• 问：视频切片的频率和大小是如何确定的？答：根据实验视频的复杂度和网络状况，切片为1秒，大小约1-2MB，平衡加载速度与存储成本。
• 问：系统如何处理视频内容的安全问题？答：采用HTTPS加密传输，视频文件存储在私有CDN，仅授权用户访问，同时定期更新播放列表的访问权限。
• 问：如果系统遇到突发流量（如某实验视频突然爆火），如何应对？答：通过CDN的自动扩容和负载均衡的动态调整，结合预加载热门视频片段，减少突发流量冲击。
• 问：技术选型中，为什么用Redis而不用Memcached？答：Redis支持更复杂的数据结构（如列表、哈希），且持久化功能更好，适合存储播放列表等需要持久化的数据。

7) 【常见坑/雷区】

• 坑1：只说技术挑战，不提具体解决方法。比如只说“视频加载慢”，不说用了HLS或CDN。
• 坑2：技术细节错误。比如HLS的片段大小或协议版本描述错误。
• 坑3：忽略用户体验。比如只说技术实现，不提用户反馈或性能指标（如卡顿率、加载时间）。
• 坑4：解决方法不具体。比如说“优化系统”，具体优化哪些模块（如缓存、负载均衡）不明确。
• 坑5：未考虑扩展性。比如系统只能支持当前用户量，没有提到如何扩展（如水平扩展服务器）。