雲盤為雲伺服器提供高可用、高可靠、持久化的資料塊級隨機儲存，其效能和資料可靠性尤為重要。ucloud根據以往的運營經驗，在過去一年裡重新設計了雲盤的底層架構，在提公升普通雲盤效能的同時，完成了對nvme高效能儲存的支援。本文從io路徑優化、元資料分片、支援nvme等技術維度著手，詳細講解了ucloud雲硬碟的架構公升級和效能提公升策略。
過去，io讀寫需要經過三層架構，請求首先通過網路，訪問proxy**伺服器（proxy主要負責io的路由獲取、快取、讀寫**以及io寫操作的三份複製），最後到達後端儲存節點。老的架構裡，每一次讀/寫io都需要經過2次網路**操作。
為了降低延時，優化後的方案將proxy負責的功能拆分，定義由client負責io的路由獲取、快取，以及將io的讀寫傳送到主chunk當中，由主chunk負責io寫的三份複製。架構公升級之後，io的讀寫只需經過兩層架構，尤其對於讀io而言，一次網路請求可直達後端儲存節點，其時延平均可降低0.2-1ms。
分布式儲存會將資料進行分片，從而將每個分片按多副本打散儲存於集群中。老架構中，ucloud支援的分片大小是1g。但是，在特殊場景下（如業務io熱點侷限在較小範圍內），1g分片會使普通sata磁碟的效能非常差，並且在ssd雲盤中，也不能均勻的將io流量打撒到各個儲存節點上。所以新架構中，ucloud將元資料分片調小，支援1m大小的資料分片。
分片過小時，需要同時分配或掛載的元資料量會非常大，容易超時並導致部分請求失敗。這是由於元資料採用的是預分配和掛載，申請雲盤時系統直接分配所有元資料並全部load到記憶體。
例如，同時申請100塊300g的雲盤，如果按1g分片，需要同時分配3w條元資料；如果按照1m分片，則需要同時分配3000w條元資料。
為了解決效能瓶頸，團隊採用放棄路由由中心元資料節點分配的方式。該方案中，client 端和集群後端採用同樣的計算規則r（分片大小、pg個數、對映方法、衝突規則）；雲盤申請時，元資料節點利用計算規則四元組判斷容量是否滿足；雲盤掛載時，從元資料節點獲取計算規則四元組； io時，按計算規則r（分片大小、pg個數、對映方法、衝突規則）計算出路路由元資料然後直接進行io。通過這種改造方案，可以確保在1m資料分片的情況下，元資料的分配和掛載暢通無阻，並節省io路徑上的消耗。
nvme充分利用 pci-e 通道的低延時以及並行性極大的提公升nand固態硬碟的讀寫效能和降低時延，其效能百倍於hdd。目前常用的基於nand的固態硬碟可支援超10w的寫iops、40-60w的讀iops以及1gb-3gb讀寫頻寬，為支援nvme，軟體上需要配套的優化設計。
首先，傳統架構採用單執行緒傳輸，單個執行緒寫 iops達6w，讀iops達8w，難以支援後端nvme硬碟幾十萬的iops以及1-2gb的頻寬。為了利用nvme磁碟的效能，需要將單執行緒傳輸改為多執行緒傳輸，系統定期上報執行緒cpu以及磁碟負載狀態，當滿足某執行緒持續繁忙、而有執行緒持續空閒情況時，可將選取部分磁碟分片的io切換至空閒執行緒，目前5個執行緒可以完全發揮nvme的能力。
此外，在架構優化上，除了減少io路徑層級以及更小分片外，ucloud在io路徑上使用記憶體池、物件池，減少不停的new delete，同時盡量用陣列索引，減少查詢消耗，並避免字串比較以及無謂的拷貝，最終充分地發揮nvme磁碟效能。
作者簡介
雲硬碟架構公升級和效能提公升詳解
雲盤為雲伺服器提供高可用 高可靠 持久化的資料塊級隨機儲存，其效能和資料可靠性尤為重要。ucloud根據以往的運營經驗，在過去一年裡重新設計了雲盤的底層架構，在提公升普通雲盤效能的同時，完成了對nvme高效能儲存的支援。本文從io路徑優化 元資料分片 支援nvme等技術維度著手，詳細講解了uclou...
騰訊雲伺服器高效能雲盤和SSD雲硬碟區別及選擇
總的來說這兩款雲盤都採用三副本分布式機制，也就是多備份冗餘，能保證資料高可靠性，不怕丟失 在實際使用中，ssd雲硬碟的讀寫速度數倍於高效能雲盤，當然了也貴一些。二者區別是業務對磁碟i o的要求高低，從 資料看 ssd雲盤適用於密集型i o場合，也就是頻繁讀寫雲盤的業務。ssd雲盤更適用於密集型 i ...
架構，效能和遊戲
架構是關於改動的。軟體架構的關鍵目標 最小化在編寫 前需要了解的資訊。當一塊 有改動時，不需要修改另一塊 肯定也得修改一些東西，但耦合程度越小，改動會波及的範圍就越小。解耦的重要性 代價 需要花費大量的努力去管理 使得程式在開發過程中面對千百次變化仍能保持它的結構。未來很難，模組化如果最終無益，那就...