適用場景

當使用簡單上傳(PutObject)功能來上傳較大的檔案到OSS的時候,如果上傳的過程中出現了網路錯誤,那麼此次上傳失敗。重試必須從檔案起始位置上傳。針對這種情況,OSS提供了分區上傳(Multipart Upload)來達到斷點續傳的效果。顧名思義,分區上傳就是將要上傳的檔案分成多個資料區塊(OSS裡又稱之為Part)來分別上傳,上傳完成之後再調用OSS的介面將這些Part組合成一個Object。

相對於其他的上傳方式,分區上傳適用於以下場景:

  • 惡劣的網路環境:如手機端,當出現上傳失敗的時候,可以對失敗的Part進行獨立的重試,而不需要重新上傳其他的Part。
  • 斷點續傳:中途暫停之後,可以從上次上傳完成的Part的位置繼續上傳。
  • 加速上傳:要上傳到OSS的本地檔案很大的時候,可以並行上傳多個Part以加快上傳。
  • 流式上傳:可以在需要上傳的檔案大小還不確定的情況下開始上傳。這種場景在視頻監控等行業應用中比較常見。

基本流程

流程如下:

  1. 將要上傳的檔案按照一定的大小分區。
  2. 初始化一個分區上傳任務(InitiateMultipartUpload)。
  3. 逐個或並行上傳分區(UploadPart)。
  4. 完成上傳(CompleteMultipartUpload)。


該過程需注意以下幾點:

  • 除了最後一塊Part,其他Part的大小不能小於100KB,否則會導致調用CompleteMultipartUpload介面時失敗。
  • 要上傳的檔案切分成Part之後,檔案順序是通過上傳過程中指定的partNumber來確定的,實際執行中並沒有順序要求,因此可以實現並發上傳。具體的並發個數並不是越多速度越快,要結合用戶自身的網路情況和裝置負載綜合考慮。
  • 預設情況下,已經上傳但還沒有調用CompleteMultipartUpload的Part是不會自動回收的,因此如果要終止上傳並刪除佔用的空間請調用AbortMultipartUpload。如果需要自動回收上傳的Part,請參考Object生命週期管理

斷點續傳

因為已經上傳的Part的生命週期是永久的,因此很容易可以實現斷點續傳的功能。

在使用分區上傳的過程中,如果系統意外崩潰,可以在重啟的時候通過ListMultipartUploadsListParts兩個介面來獲取某個Object上的所有的分區上傳任務和每個分區上傳任務中上傳成功的Part列表。這樣就可以從最後一塊成功上傳的Part開始繼續上傳,從而達到斷點續傳的效果。暫停和恢複上傳實現原理也是一樣的。

斷點續傳功能在行動裝置和大檔案上傳中的優勢尤為明顯。

上傳限制

  • 大小限制:在這種上傳方式下,Object的大小是由Part來決定的,最大支援10000塊Part。每塊Part最小100KB(最後一塊可以比100KB小),最大5GB。Object的大小不能超過48.8TB。
  • 命名限制
    • 使用UTF-8編碼
    • 長度必須在1-1023位元組之間
    • 不能以“/”或者“\”字元開頭

上傳的安全及授權

為了防止第三方往開發人員的Bucket未經授權上傳,OSS提供了Bucket和Object等級的存取權限控制,詳細解釋見存取控制。為了授權給第三方上傳,OSS除了Bucket和Object等級的存取權限外,還提供了帳號等級的授權,見上傳安全之授權第三方

上傳後續操作

  • 在檔案上傳到OSS上後,開發人員可以使用上傳後回調來向指定的應用伺服器發起回調請求,進行下一步操作。
  • 如果上傳的是圖片,可以使用圖片服務進行後續處理。
  • 如果上傳的是音頻或者視頻檔案,可以使用媒體轉碼進行後續處理。

功能使用參考:

最佳實踐

相關參考連結: