背景

資料爆炸的時代，產生的資料量不斷地在攀升，基本都離不開檔案儲存。

1.儲存單位從KB、MB、GB、TB、PB到ZB級別不斷攀升；

2.檔案多樣性，比如圖片、文件、素材、靜態化頁面、長短影片、安裝包等一系列檔案，比較難以維護。

解決方案

業務應用記憶體儲

傳統的javaweb專案, 檔案數量達到一定後佔據大量的記憶體、磁碟和頻寬, 無法滿足海量請求的業務開發容易-擴容難

分散式檔案系統（Distributed File System)

海量資料對儲存提出了新的要求，從而誕生了分散式檔案儲存是檔案系統管理的物理儲存資源不一定直接連線在本地節點上，而是透過計算機網路與節點（可簡單地理解為一臺計算機) 相連，或是若干不同的邏輯磁碟分割槽組合在一起而形成的完整的有層次的檔案系統自研：擴容容易-開發難

對於以上的考慮，我們可以聯想到做分散式檔案儲存，主要是想實現檔案儲存訪問的高效能與高可用，如何保證分散式儲存的高效能與高可用？其實基本就是副本備份、雙活、多活這種架構

在系統中透過複製協議將資料同步到多個儲存節點，並確保多個副本之間的資料一致性，當某個儲存節點出故障時，系統能夠自動將服務切換到其他的副本

在分散式儲存中高效能與高可用是矛盾的，比如要設計一個分散式儲存系統，CAP定理也可以推斷出來

對效能的考慮，記錄資料時先寫一個份資料到某個機器上並立即返回，然後非同步發起多個數據備份過程。這種設計的效能最好，但存在“容錯性”的風險，加入返回後，還沒來得及同步給其它節點就宕機了，則資料就丟失（非同步複製，也存在是寫主節點到記憶體還是落到磁碟）如果同時寫多個副本，每個副本寫成功以後再返回，則又導致效能下降，這個過程取決於最慢的那臺機器的效能 (同步多寫，是同步每個副本節點還是一個副本先)

那應該如何選擇呢？根據業務而定：

1.如果要求效能更高，偶爾出現檔案丟失或訪問出錯則可以非同步複製

2.要求檔案系統一定要高可用，則用同步多寫的策略，犧牲一定的效能也要保證高可用資料一致性

基於上述的，大家還知道有一個很類似的訊息佇列就是支援這種操作RocketMQ訊息高可用裡面的同步雙寫、非同步刷盤，即同時寫到兩個節點上的記憶體才返回，然後非同步持久化到磁盤裡面

好了，以上是本人對於高效能和高可用的見解，如果您喜歡我，可以一鍵三連，這樣就可以第一時間看到我更多技術文章啦。