本文介紹利用阿里云OSS分布式架構提升OSS數據處理速度、降低數據延遲、加速應用程序響應能力的多種方法，旨在優化OSS性能表現。
將順序前綴改為隨機性前綴
為了優化OSS的數據分布和提升處理效率，建議您采用隨機性前綴替代傳統的順序前綴來命名您的文件。OSS根據文件key的UTF-8編碼順序自動劃分數據分區，以支持大規模文件管理和高并發請求。然而，在使用順序前綴（如時間戳或按字典序排列的字符串）的情況下，可能引起部分分區過載現象，即大量文件集中在少數幾個分區中。
例如，當您的請求速率超過2000次/秒時（下載、上傳、刪除、拷貝、獲取元數據信息等操作算1次操作，批量刪除N個文件、列舉N個文件等操作算N次操作），會帶來以下問題：
熱點分區形成：高頻率的請求集中在某些特定分區，使之變成熱點分區，導致分區的I/O能力被耗盡，或被系統自動限制請求速率。
請求速率受限：熱點分區的存在會觸發系統進行持續的分區數據再均衡，這個過程可能會延長請求處理時間。
說明分區數據再均衡基于實時系統狀態和處理能力分析，而非固定拆分規則，使用順序前綴命名的文件也可能在重新均衡后仍處于熱點分區。
為解決以上問題，您可以將文件key的順序前綴改為隨機性前綴，使得文件索引（以及I/O負載）均勻地分布在多個分區。
向文件key添加十六進制哈希前綴
如果您使用日期與客戶ID生成文件key，則包含順序時間戳前綴：
sample-bucket-01/2024-07-19/customer-1/file1 sample-bucket-01/2024-07-19/customer-2/file2 sample-bucket-01/2024-07-19/customer-3/file3 ... sample-bucket-01/2024-07-20/customer-2/file4 sample-bucket-01/2024-07-20/customer-5/file5 sample-bucket-01/2024-07-20/customer-7/file6 ...針對這種情況，您可以對客戶ID計算哈希（即MD5），并取若干字符的哈希前綴作為文件key的前綴。假如取4個字符的哈希前綴，那么經過改造后的文件key示例變為：
sample-bucket-01/9b11/2024-07-19/customer-1/file1 sample-bucket-01/9fc2/2024-07-19/customer-2/file2 sample-bucket-01/d1b3/2024-07-19/customer-3/file3 ... sample-bucket-01/9fc2/2024-07-20/customer-2/file4 sample-bucket-01/f1ed/2024-07-20/customer-5/file5 sample-bucket-01/0ddc/2024-07-20/customer-7/file6 ...加入4個字符組成的十六進制哈希來作為前綴，則每個字符有0~9以及a~f共16種取值，4個字符共有16 4=65536種可能的字符組合。在存儲系統中，這些數據理論上會被持續劃分至最多65536個分區，以每個分區操作2000次/秒的性能瓶頸標準，再結合您業務的請求速率，可以評估哈希桶的個數是否合適。
如果您想要列出文件key中帶有特定日期的文件，例如列出sample-bucket-01里帶有2024-07-19的文件，您只要對sample-bucket-01進行列舉（即通過多次調用ListObject接口，分批次地獲得sample-bucket-01下的所有文件），然后合并帶有該日期的文件即可。
反轉文件key
如果您使用了毫秒精度的Unix時間戳生成文件key，同樣屬于順序前綴：
sample-bucket-02/1513160001245.log sample-bucket-02/1513160001722.log sample-bucket-02/1513160001836.log sample-bucket-02/1513160001956.log ... sample-bucket-02/1513160002153.log sample-bucket-02/1513160002556.log sample-bucket-02/1513160002859.log ...這種情況可以考慮通過反轉時間戳前綴來避免文件key包含順序前綴，反轉后結果如下：
sample-bucket-02/5421000613151.log sample-bucket-02/2271000613151.log sample-bucket-02/6381000613151.log sample-bucket-02/6591000613151.log ... sample-bucket-02/3512000613151.log sample-bucket-02/6552000613151.log sample-bucket-02/9582000613151.log ...由于文件key中的前3位數字代表毫秒時間，會有1000種取值。而第4位數字，每1秒鐘就會改變一次。同理第5位數字每10秒鐘就會改變一次。以此類推，反轉文件key將極大地增強前綴的隨機性，從而將負載壓力均勻地分攤在各個分區上，避免出現性能瓶頸。
使用字節范圍提取
當下載OSS中的大文件（大于100 MB）時，由于網絡環境不穩定可能導致傳輸中斷。如果您只需要下載文件的部分內容，而不是下載完整文件的情況下，可以使用HTTP Range請求獲取文件的部分內容。請求方法說明如下：
Get /ObjectName HTTP/1.1
Host:examplebucket.oss-cn-hangzhou.aliyuncs.com
Date:Fri, 19 Jul 2024 17:27:45 GMT
Authorization:SignatureValue
Range:bytes=[$ByteRange]根據HTTP協議規范，Range請求頭允許客戶端指定希望接收的數據片段有效區間位于0至content-length - 1的范圍內。關于通過HTTP Range請求分段獲取OSS資源的更多示例，請參見如何通過HTTP Range請求分段獲取OSS資源。
使用OSS傳輸加速
當您需要實現Bucket遠距離數據傳輸加速（例如從中國內地向非中國內地Bucket請求加速上傳或下載文件），上傳和下載GB、TB級大文件時，您可以開啟傳輸加速。傳輸加速利用全球分布的云機房，將全球各地用戶對Bucket的訪問，經過智能路由解析至就近的接入點，使用優化后的網絡及協議，為云存儲的上傳、下載提供端到端的加速方案。更多信息，請參見傳輸加速。
對頻繁訪問的內容使用緩存
為提升OSS高頻訪問內容的訪問速度，推薦使用CDN加速訪問。CDN的工作原理是將靜態內容復制至全球各地的邊緣節點，讓用戶可以從最近的節點快速獲取內容，從而大幅提升網站訪問速度和穩定性。
具體而言，當用戶請求OSS某個文件時，CDN首先檢查邊緣節點是否存在該文件。若不存在或文件已過期，則向源站OSS請求內容并復制至附近邊緣節點。當源站OSS內容變更時，CDN自動更新邊緣節點緩存，確保源站與CDN邊緣節點內容同步。
借助以上方案，CDN可以有效減輕源站OSS負載，提高內容訪問速度及穩定性，特別適用于全球用戶廣泛分布的企業。更多信息，請參見CDN加速訪問。
使用最新版本OSS SDK
OSS SDK為優化OSS性能的建議準則提供了內置支持。使用阿里云最新版本OSS SDK對于性能提升的幫助主要體現在以下幾個方面：
新特性的支持：新版SDK通常包含最新的功能和改進，能夠利用OSS的新特性，例如最新的API、優化的算法和更高效的編碼方式，從而提高性能。
錯誤處理和重試機制：新版SDK通常包含更完善的錯誤處理和重試機制，能夠自動處理常見的錯誤，例如HTTP 503錯誤，減少因網絡問題導致的失敗操作，提高成功率。
傳輸管理：新版SDK會提供更高級別的傳輸管理功能，自動擴展連接并在適當的時候使用范圍請求，實現高效的吞吐量。
多線程支持：新版SDK通常支持多線程編程模型，可以并行處理多個請求，提高數據處理速度。
內存管理優化：考慮到內存資源的有效利用，新版SDK在內存管理層面進行了深度優化，旨在減少不必要的內存開銷，提升內存使用效率。
兼容性增強：新版SDK致力于修復歷史遺留問題，持續增強與各類第三方軟件庫及操作系統平臺的兼容性。
如何獲取阿里云最新版本OSS SDK，請參見SDK簡介。
在同一地域內中結合使用OSS和ECS
為了充分利用阿里云OSS和ECS的優勢，推薦您在同一地域內部署您的ECS實例和OSS存儲空間。這種部署策略能夠顯著減少數據傳輸的延遲時間，提升數據讀取速度，從而增強應用的整體性能。 當您的ECS實例和OSS存儲空間位于同一個地域時，通過內網Endpoint進行通信，可以免除內網流量費用。這意味著，在ECS實例與OSS之間傳輸大量數據時，無需額外支付高額的網絡帶寬費用，降低了總體成本。 要實現這一配置，請參見ECS實例通過OSS內網地址訪問OSS資源。
對時延敏感的應用程序進行超時重試
OSS針對管控類API，如GetService（ListBuckets）、PutBucket、GetBucketLifecycle等進行QPS限制。如果應用程序產生高請求速率，可能會收到HTTP 503減速響應。如果發生這類錯誤，建議您延遲幾秒后進行重試。
單個阿里云賬號的總QPS為10,000，如果您需要更高的QPS，請聯系技術支持。注意，在整體訪問QPS未超過上述閾值的情況下，如果請求集中在特定分區，服務端也可能會因為超過單分區的服務能力而限流并返回503；如果請求前綴合理打散（參見OSS性能與擴展性最佳實踐），OSS會自動擴展分區數量來支持更高QPS的訪問，您只需要等待并重試即可。
當您發出大量不同大小的請求時（例如超過128 MB），建議您測量吞吐量，并重試最慢的5%請求。當您發出較小的請求時（例如小于512 KB），時延通常在數十毫秒以內。建議您在2秒后重試GET或PUT操作。如果需要額外的重試，最好的做法是退出。例如，建議您在2秒后重試，然后等4秒后再次重試。
如果您的應用程序向OSS發出固定大小的請求，您期望每個請求的響應時間趨于一致。在這種情況下，推薦的策略是識別最慢的1%請求并重試。通常情況下，即使一次重試也能有效減少時延。
通過水平擴展和并行請求實現高吞吐量
OSS是一個超大的分布式系統。為了幫助您利用其規模，建議您將并行請求水平擴展到OSS服務終端節點，這種擴展方式有助于通過網絡將負載分布在多個路徑上。
對于高吞吐量傳輸，建議您在多個線程或多個實例中同時啟動多個請求連接來并行上傳和下載數據。對于某些應用程序，您可以通過在不同的線程或實例中同時啟動多個請求來實現并行連接。擴展策略取決于您的應用程序和您訪問的對象的結構。
當您要調整并發的請求數時，性能測量非常重要。建議從單個請求開始，測量當前的網絡帶寬以及其他資源的使用情況，從而識別瓶頸資源（即使用率最高的資源），以及可能的并發請求數。例如，如果一次處理一個請求導致CPU使用率為10%，則表明最多可以支持10個并發請求。
水平擴展存儲連接
將請求分散在多個連接上是橫向擴展性能的常見設計模式。當您構建高性能應用程序時，可將OSS作為一個大的分布式系統，而不是像傳統存儲服務器那樣作為單個網絡終端節點。您可以通過向OSS發送多個并發請求來實現最佳性能。將這些請求分散到不同的連接上，可以最大限度地利用阿里云OSS的可訪問帶寬。OSS對存儲空間的連接數沒有限制。
增加重試次數
鑒于阿里云OSS的規模較大，如果第一次請求速度較慢，您可以嘗試發送重試請求。您可以通過OSS SDK配置超時和重試值，并根據您應用程序的容錯要求進行調整。