Biu.Moe 上传音乐流程介绍

Biu 一开始直接从浙江绍兴电信节点接收用户的上传，经常遇到联通不稳定等问题。

为了给用户提供更好的上传环境和更可靠的存储，只好关闭一周重写整个上传流程。

接收上传使用的是七牛，依赖一下第三方 CDN 来提升上传速度。结果是本文发布的时候开放了大概一个小时，接收投稿

还在不断增长中……

其中一个用户不到一小时上传了 100 首以上，看来 CDN 不仅仅是下载，上传也很重要。

废话到此为止，来说整个上传的流程。先列个流程单

1. 选择文件，获取到文件信息
2. 前端上传队列开始上传
3. 七牛通知后端去获取文件
4. 后端拿到文件后进行校检
5. 校检通过开始转码
6. 审核通过后分发至存储节点

噫，看起来也不是很复杂是吧？接下来我把每个流程的具体细节列一下。

在上传界面选择文件之后，首先进行歌曲编码分析，如果是 MP3 而且码率过低，前端直接打断上传流程。

音质初步判断通过的话，会尝试提取 ID3 信息，包括歌曲名、歌手、专辑名自动填写进表单，并获取文件的 MD5 保存至服务器。这个 MD5 是用于校对转码节点接收的文件与用户上传的文件是不是完全匹配的，如果不匹配该怎么处理呢？这点稍后讲。

转码节点拿到文件，通知七牛删除。然后进行精确的音质分析，包括编码类型和码率，判断通过之后会开始进行转码，如果是无损会转换出 FLAC 压缩等级 8 和 Q0.65 质量的 AAC，分别用于客户端和网页的在线播放。在这个地方我做了一个简单的队列处理，防止并行任务过多导致 CPU 过载或者内存 OOM。这里有一个坑，就是 itunes AAC 与标准 AAC 有一点区别，在客户端会出现无法边缓冲边播放的问题，因此服务器会重新封装 AAC 文件绕过这个坑。

转码完成之后算出全部文件的 MD5 保存进入后台进行审核，如果不通过会有『退回』和『删除』两个功能。审核通过的话会为这个歌曲分配两个存储节点，并通知存储节点获取文件到临时文件夹。两个节点完成全部文件的下载之后会进行 MD5 校对，校检失败的话会打回后台，后台有一个『重新分发』按钮供重新分发。

两个存储节点都汇报保存成功之后，网站会进行歌曲发布获得具体的歌曲 ID，并通知两个存储节点将文件从临时文件夹挪到对应的路径上，在这里如果移动失败还会有一个状态回报。

到这里歌曲就发布完成了。不过我们需要思考一个问题，如何保证用户上传的数据绝对准确没有被篡改？

回到上传文件这步，刚才提到获取文件的 MD5 保存在服务器。上传完成后转码节点如果发现 MD5 不符，需要知道是用户上传到七牛的问题，还是转码节点从七牛获取的问题。很可惜七牛不提供 MD5 计算，只提供了七牛自己开发的一个算法叫 Qetag。因此如果出现校检失败，服务器会匹配 Qetag，如果 Qetag 不符，那可能是转码节点从七牛获取的问题，后台会出现转码节点拉取失败，『重新拉取』按钮。如果 Qetag 是正确的但是 MD5 校检失败，就是用户上传的数据遭到篡改，只能打回由用户重新上传。

一个看起来不难的上传，想要尽量做到完美，也是非常麻烦的。接下来会考虑开放上传 API，方便那些会自己写程序的搬运工批量上传。

最后附上上传表的状态（其实是给自己备份的）：