關於分散式文件系統負載均衡有哪些資料值得閱讀？

01-24

重點在於負載均衡演算法，全面一些，中英文都可以

謝邀！這個問題原先研究過一下，對我啟發比較大的主要是三篇論文，推薦給你。

1. sc03-An efficient data location protocol for self-organizing storage clusters：大名鼎鼎的Ceph的負載平衡策略，文中提出的幾種策略都值得嘗試，比較贊的一點是可以對照代碼體會和實踐；

2. sc04-A Self-Organizing Storage Cluster for Parallel
Data-Intensive Applications：Surrento的冷熱平衡策略採用了延遲寫技術，同樣值得借鑒。

3. sc11-Server-side io coordination for parallel file systems：這篇略tricky，看看還是不錯的。

我曾經在京東做過幾年分散式存儲系統的開發，對這個問題有過自己的心得，這個的確是分散式存儲系統中負載必須要考慮的問題。

我們的分散式存儲系統原生支持跨機房，而且跨的不止一個機房，一個文件三個副本存儲在三個機房內，這裡機房以A,B,C為例，A機房與B機房有專線，B機房與C機房有專線，A機房與C機房沒有專線，好了，我們認為專線帶寬足夠，僅有延遲問題，那麼，如果客戶端在A機房，那麼，在低負載情況下，應該優先從A機房讀，其次從B機房讀，再次從C機房讀，如果客戶端在B機房內，首先應該從B機房讀，其次A，C機房都是可以的，C機房應用同理A。

希望有一個這樣的策略，客戶端在將讀請求送往伺服器的時候，應該知道將這個請求送往哪台伺服器是最好的，如果不考慮網路問題，不考慮磁碟性能問題，認為局部可以反映整體的話，那麼，隨機演算法可能是最簡單可靠的。但是事與願違，A機房做為老機房，請求量肯定比新機房C要多得多，但是數據是分布到不同機房的，可能是AAC,ABC,ACC，甚至，這個數據，在A機房就是沒有，必須得從B機房或者C機房拿到。

我們希望達到這樣的一種效果，客戶端在發送讀請求的時候，能夠知道對端的額外的信息，例如"磁碟忙不忙，帶寬怎麼樣"，用數字來量化，就是負載值，例如a是0.6 ,b是0.5, c是0.3,所以，一個客戶端，如果在A機房機房，可能會選擇a，應為雖然b，c的負載都比a要低，但是客戶端和數據在同一個機房，沒有專線的帶寬與延遲限制。這個時候，請求將會送到a機器，一個客戶端這樣決定，成千上萬個客戶端也這樣決定，那麼勢必導致a的負載升高，這個時候變成0.9了，這個時候，B機房的b機器也許是一個更好的選擇。

我們的客戶端會根據客戶端所在的機房來確定對同一個機房，有專線連接的機房，沒有直接專線連接的機房的機器來設置一個初始的值，稱之為權重。同時，我們的通訊協議里，在每次請求伺服器返回的信息里，有一個1位元組的數值，來量化伺服器的負載（服務端定時間採集）。就是說，這次請求，將會計算伺服器的權重，來決定下一次發往這個伺服器的請求的策略。我們用一個反饋函數來計算新的權重。如果負載低於某個值，則正反饋，伺服器的權重會不斷增加，最高不會超過初始值的一定倍數。如果負載高於某個值，則是負反饋，伺服器的權重會不斷減少，直到0為止。我們稱之為動態反饋。

PS1: 上面說的讀負載只是在線業務的負載策略，一般只是圖片，訂單等小數據的讀負載策略。寫負載策略就不多說了，請求量一天才幾千萬，和讀萬全不成比例。一般考慮磁碟空間為主就行了。

PS2: 另外還有大文件，但是大文件一般都是為了高吞吐量需求並不是為了低延遲設計，只要保證數據均勻分部即可。另外，大文件一般都是為了做計算，要考慮就近計算，方正我是反對跑計算的存儲集群跨機房部署的，離線一般都是對內的，可靠性沒那麼高，什麼機房網路被挖斷也沒啥損失。

推薦分散式系統(Distributed System)資料 Qix/ds.md at master · ty4z2008/Qix · GitHub

裡面包含了分散式系統的多個問題和經典papers ,希望能夠幫助到您

註：裡面的很多內容需要梯子

只能說一下讀過的一些，《1》ceph的負載均衡（上面有兄弟提了），尤其是crush演算法數據結構的設計，可以實現跨數據中心、跨機房、機架的設計，還是比較巧妙的；《2》經典的一致性hash 《3》大型的分散式系統，需要考慮跨機房設計

不請自來

谷歌的論文雖然老了點，但是很值得讀