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