核心結論
音頻文件絕不存放於關係型數據庫（BLOB/CLOB），而是採用分布式文件系統 + 對象存儲 + CDN 的組合架構。
為什麼不存數據庫？
- 性能災難：大對象讀寫會嚴重阻塞數據庫緩衝池，導致連接池耗盡、查詢延遲飆升；
- 擴展性差：TB/PB 級媒體數據無法通過分表分庫水平擴展，備份恢復極其緩慢；
- 成本高昂：高性能塊存儲（如 RDS SSD）單價遠超對象存儲（OSS/S3/HDFS）。
主流存儲方案對比
| 方案 | 典型技術 | 適用場景 | 優勢 | 劣勢 |
|---|
| 分布式文件系統 | HDFS、Ceph、GFS、MooseFS | 海量非結構化數據、大數據離線分析 | 高吞吐、故障自愈、POSIX 兼容 | 小文件性能弱、運維複雜 |
| 對象存儲 | AWS S3、阿里云 OSS、騰訊云 COS、MinIO | 靜態資源分發、多副本跨區容災 | 無限擴展、HTTP/HTTPS 原生訪問、生命周期管理 | 非 POSIX、隨機讀寫延遲高 |
| CDN 加速 | Akamai、Cloudflare、云廠商自建 CDN | 終端用戶就近獲取音頻流 | 毫秒級首包、降低源站壓力、防盜鏈 | 緩存一致性、成本隨流量增長 |
實際架構分層（以網易雲為例）
- 上傳層：客戶端直傳 OSS（預簽名 URL），服務端僅驗證元數據入庫；
- 轉碼層：觸發媒體處理工作流（FFmpeg/云轉碼），生成多碼率（128k/320k/無損）+ 多格式（MP3/AAC/FLAC）；
- 存儲層：熱門曲目存高性能 SSD 集群（或 OSS 標準存儲），長尾曲目沉降至 OSS 低頻/歸檔存儲；
- 分發層：CDN 回源 OSS，邊緣節點緩存熱門片段，支持 Range 請求實現拖拽播放；
- 元數據庫：MySQL/TiDB 僅存
song_id, title, artist, duration, oss_key, bitrate_map, cdn_url_template 等結構化信息。
關鍵優化技巧
- 預取/預緩存：播放前 30 秒預載下一首片段；
- 斷點續傳：HTTP Range + ETag 實現大文件斷點下載；
- 防盜鏈：Referer 檢查 + 簽名 URL 時效控制；
- 成本控制：智能分級存儲（熱/溫/冷）+ 重複刪除（內容哈希去重）。
總結
大型音樂平台通過「對象存儲存文件 + 數據庫存元數據 + CDN 加速分發」的經典模式，實現了億級曲庫的低成本、高可用、極速分發。切勿嘗試將二進制音頻寫入關係型數據庫。
