进行实时，可扩展音频处理的最佳策略？

Question

我正在构建一个允许用户上传音频文件，特别是音乐的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或大型网站的用途吗？）

谢谢！

Answer 1

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

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

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

编写任务的好方法是使用消息传递系统，如AMQP。有一些便宜的服务，比如rabbitmq，会为你做这件事。当然，您也可以在任何数据库之上构建自己的数据库，但这可能需要轮询。

最后，您可能会发现使用像zencoder这样的服务进行转码更快更有效，因为它们可以并行化工作并可能处理更多输入格式，但它可能与您的处理不兼容

Answer 2

你肯定想把音频处理转移到后台进程。

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

很抱歉，我对跨域文件上传或大狗怎么做（youtube，soundcloud等）一无所知