今天跟同事討論分布式檔案儲存系統，說到如何評價乙個系統的好與壞，一時還真覺得不太好評判。當然了系統本身的伸縮性、可用性肯定要好，否則無法長期投入穩定運營的，畢竟業務，特別是網際網路業務經常會有快速增長或者快速萎縮的現象以及7*24小時不間斷服務的需求。那麼除了這兩個以外，如何評判好與壞呢？實際上很多系統都有自己適用的場景，即使再通用的系統，也總有一些場景表現不如人意。系統支援的功能，以及每種功能介面所表現出來的效能應該是乙個比較好的評判標準。那麼其實我們可以拿posix檔案系統介面作為標準參照物。假想一種場景，所有這些分布式檔案儲存系統都盡可能實現posix檔案系統介面的乙個子集，那麼我們就可以根據每個系統實現的子集介面的數量，以及每個介面的呼叫效能來綜合確定系統的好與壞。比如目錄檔案遍歷，比如大檔案讀寫，比如大量小檔案讀寫，比如檔案查詢，比如刪除檔案，比如拷貝檔案，比如訪問控制等等操作，在這個標準面前，其實很多所謂的高效能的分布式檔案儲存系統都將現出原形，因為它們在實現的時候往往忽略了甚至是摒棄了這些考慮。
在一些傳統的檔案系統（比如ext3/4，reiserfs等）裡面，是需要考慮到一些極端情況的，比如單個檔案很大很大，達到tb量級，比如檔案很小很小，小到只有幾十個位元組，又或者乙個目錄下有很多很多檔案，達到百萬數量級，再者目錄層次比較深，達到了數十層等等，這些極端情況都是檔案系統應該考慮的問題，至少需要在乙個合理的響應時間內完成操作。而大部分分布式檔案儲存系統往往達不到這些極端條件的要求，只要出現其中乙個，也許就會出現意外情況，甚至嚴重得幾乎不可服務。另外，大部分的分布式檔案儲存系統都沒有實現分布式事務，因為分布式事務會造成整體吞吐量下降，所以這樣也會導致資料一致性更容易遭到破壞，多個併發的請求有可能互相影響，導致資料最終狀態難以確定。大部分這類系統還會採用信令與資料相分離的架構，一方面減輕了中心伺服器的負擔（只處理元資料），另一方面也縮短了資料傳輸的路徑（客戶端直連儲存伺服器）。但是由於網路的不穩定性和儲存伺服器的不可靠性（基本上都是採用廉價的pc伺服器做儲存），那麼其實是會增加系統總的互動次數，從而某些情況下效率下降。另外很多系統在多副本機制下，往往乙個副本會比較脆弱，且損壞的時候得通過其他遠端副本來緩慢恢復，副本自身的保護與恢復能力也是比較差的。雖然在分布式環境下少數副本節點的故障不會影響全域性，但是對於被故障節點所處理的請求將會是確定性的受影響，甚至出現資料丟失風險（特別是在非同步複製副本的情況下）。
如何實現較完善的機制去克服以上這些困難，也許才是作為綜合評判系統到底是好還是壞。如果只是在特定場景下表現良好而已，那麼只能說它與業務已經有較大的耦合。只要換乙個業務，也許就表現沒那麼好了。當然，我們可以通過定製的方法構建多個不同的系統，以應對不同種類的業務，但是這又繞回到開頭的問題，很難比較系統的好與壞。。。
分布式系統漫談
分布式系統漫談 微服務的挑戰和解決方案。微服務的挑戰 在使用微服務架構後，由於服務間的呼叫不再是程序內的呼叫而是通過輕量級的網路協議通訊，而眾所周知網路不不可信的，因此服務可能出現出錯 超時或宕機等問題。因此在微服務架構設計時，我們就要把這部分問題考慮進去，下面說說我們應該採取哪些措施和方案去解決。...
FastDFS分布式檔案儲存系統
負載均衡和排程，通過tracker server 在文上傳的時候可以根據一些策略找到storage server提供檔案上傳服務，可以將tracker 稱為追蹤伺服器或排程伺服器 檔案儲存，客戶端上傳的檔案最終儲存在storage 伺服器，storage server沒有實現自己的檔案系統而是利用作...
python分布式儲存系統 分布式系統
danger 什麼是分布式系統 分布式系統是由一組通過網路進行通訊 為了完成共同的任務而協調工作的計算機節點組成的系統。分布式系統的出現是為了用廉價的 普通的機器完成單個計算機無法完成的計算 儲存任務。其目的是利用更多的機器，處理更多的資料。首先需要明確的是，只有當單個節點的處理能力無法滿足日益增長...