1

我正在构建一个 Web 应用程序，允许用户上传音频文件，尤其是音乐。大多数时候，我预计每首歌曲的持续时间通常约为几分钟，文件大小约为 3-10MB。但是，我想接受最大约 100MB 的音频上传，可能允许超过一个小时的音频。我目前正在使用 FFmpeg、SoX 和 LAME 的组合将 7 种可能的格式转换为 mp3 并执行音频修改，包括均衡、修剪和淡化。然后将文件存储并链接到数据库中。

我目前的策略是在后端使用 PHP 在一个 HTTP 文件上传请求中处理整个过程，其中我执行以下功能：

  1. 验证
  2. 将音频转码为多个版本（通过 PHP 使用 shell）
  3. 将原始版本和转码版本存储在临时目录中
  4. 将所有音频文件上传到 Amazon S3 以进行永久存储
  5. 将每个文件的 ID 提交到数据库，将它们链接到用户

这与我已经设置的图像处理系统非常相似。然而，虽然图像可以在几秒钟内完成整个过程，但音频可能需要更长的时间。处理和存储音频最多需要 5-10 分钟。

我的问题是：

  1. 对于音频处理，最好将转码分叉到另一个后台进程，将其状态写入数据库，并每隔几秒 ping 一次以更新网页，而不是在一个 HTTP 请求中完成所有操作？

  2. 为了在未来进行扩展，是否建议在单个服务器实例上进行所有处理，让前端 Web 实例自由复制/被销毁？

    • 如果是，这是否需要跨域文件直接上传到该服务器？（有人知道这是 youtube 还是大型网站的做法？）

谢谢！

4

2 回答 2

2

如果我正确理解你的系统，你最好的方法可能更像是这样：

  • 在您的 Web 前端，存储音频并创建一个“任务”，指示需要处理音频。
  • 运行一个拉取任务并进行处理的后台任务。在任务结束时，可以通知用户（如果需要）并且可以更新数据库状态或其他任何内容。

您的任务应该这样编写，以便如果它们在中途失败，它们可以从一开始重新执行而不会造成问题。您可以在此架构中运行多个后台任务和 Web 前端。

编写任务的一个好方法是使用像AMQP这样的消息传递系统。有像rabbitmq这样的廉价服务可以为你做到这一点。当然，您也可以在任何数据库之上构建自己的数据库，但这可能需要轮询。

最后，您可能会发现使用zencoder 之类的服务来进行转码更快、更高效，因为它们可以并行化工作并且可能处理更多输入格式，但它可能与您的处理不兼容。

于 2013-08-25T00:04:33.903 回答
0

您肯定想将音频处理交给后台进程。

根据所涉及的可扩展性，您可能需要一台专用于处理的计算机。您可能想查看其他可以卸载音频内容的资源（例如 PCIe 卡等）

很抱歉，我对跨域文件上传或大狗如何做到这一点一无所知（youtube，soundcloud 等）

于 2013-08-23T23:03:32.763 回答