AWS HLS转码完成后自动获取流URL的最佳实践

核心思路 #

围绕转码完成后的事件触发+URL生成+数据库更新的闭环设计，优先保证流程的可靠性和效率，避免冗余步骤。

具体实现方案 #

方案1：转码Lambda直接完成URL生成与数据库更新 #

这是最直接的方式，适合转码逻辑不复杂、耗时较短的场景：

• 转码Lambda完成HLS转码后，直接拼接CloudFront流URL：
  • 拼接规则：https://<你的CloudFront域名>/<输出存储桶的文件路径>/<主索引文件名>.m3u8
  • 示例代码片段：

    cloudfront_domain = "d123456abcdef.cloudfront.net"
    output_key = "transcoded/videos/123/index.m3u8"
    hls_url = f"https://{cloudfront_domain}/{output_key}"
    

• 在同一个Lambda中直接调用MongoDB的更新接口，把生成的URL写入对应文档，同时可更新视频状态为「已完成」
• 注意：如果转码耗时较长，要确保Lambda超时时间设置足够；若数据库更新逻辑复杂，建议拆分到单独Lambda，通过SNS或SQS触发，避免主转码Lambda负担过重

方案2：用S3事件通知触发后续处理（适合多文件输出场景） #

当HLS转码生成多个分片文件（.ts）和索引文件时，建议监听主索引文件（.m3u8）的创建事件触发后续流程：

• 给输出S3存储桶配置事件通知，当*.m3u8类型文件被创建时，触发专门的「URL生成+数据库更新」Lambda
• 该Lambda核心逻辑：
  1. 从S3事件中提取主索引文件的存储键（Key）
  2. 拼接CloudFront完整流URL
  3. 从文件路径中提取视频ID（比如transcoded/videos/<video-id>/index.m3u8），找到MongoDB对应文档并更新流URL和状态
• 额外优化：若担心分片文件未完全生成就触发事件，可给S3事件配置延迟触发（最长15分钟），或用Step Functions编排转码+等待所有文件写入+更新数据库的完整流程

方案3：用Step Functions编排完整工作流（适合复杂场景） #

如果服务有扩展需求（比如转码失败告警、多格式输出、状态跟踪），Step Functions是更可靠的选择：

• 工作流步骤：
  1. 启动转码：S3上传事件触发Step Functions，调用转码Lambda
  2. 转码完成校验：检查输出桶中是否存在主.m3u8文件，确认所有转码文件生成完毕
  3. 生成URL并更新数据库：调用专门Lambda拼接CloudFront URL，写入MongoDB
  4. 错误处理：若转码或数据库更新失败，触发告警（如SNS发送通知），并标记视频状态为「失败」
• 这种方式可直观监控每个步骤状态，方便排查问题

关键注意事项 #

• URL权限：确保CloudFront分发配置了正确的OAI（Origin Access Identity），输出S3存储桶权限允许CloudFront访问，避免URL无法访问
• 重试机制：给数据库更新的Lambda配置重试策略（比如最多3次重试），并设置死信队列存储重试失败的任务，避免数据丢失
• 状态跟踪：在MongoDB中提前记录视频的上传时间、转码状态（如「转码中」「已完成」「失败」），提升服务可观测性
• 性能优化：若批量处理视频，建议用SQS做消息队列削峰填谷，避免Lambda并发过高触发限流

内容的提问来源于stack exchange，提问作者Surajit