1.數據是如何被分布到多個服務器上的？（一致性哈希算法） 假設有n臺服務器， 計算這n臺服務器的IP地址的哈希值， 把這些哈希值從小到大按順時針排列組成一個“服務器節點環”， 客戶端需要存儲一系列的“鍵值對”到這些服務器上去， 計算這些“鍵”的哈希值， 看看這些“鍵”的哈希值落在“服務器環”的哪些區間， 如下圖所示： 根據上圖示意，數據將被存儲在“順時針方向上的下一個服務器節點” 讀取數據時，也是先根據“鍵”的哈希值，找到這個服務器節點， 再向這個節點索取數據。 2.數據如何均勻的分布？（虛擬服務器） 假設服務器數量較少， 很可能造成有些服務器存儲的數據較多、承擔的壓力較大， 有些服務器就比較空閑。 這時就要把一臺服務器虛擬化成多臺服務器， 具體的操作辦法： 在計算服務器對應的哈希值時 可以在IP地址字符串加多個“尾綴” 比如： 10.0.0.1#1 10.0.0.1#2 10.0.0.1#3 .... 這樣，一臺物理服務器就被虛擬化成多臺服務器， 對應“服務器環”上的多個節點。 3.如何實現數據的熱備份？ 以順時針方向看“服務器環” 當有客戶端把數據存儲在第1臺服務器上后， 第1臺服務器負責把該數據拷貝一份給第2臺服務器 以此類推， 也就是說“服務器環”上的每一個節點，都是上一個節點的熱備份節點 同時，一個服務器上存了兩類數據，一類是自身的業務數據，一類是上一節點的熱備數據。 注意：這里所說的服務器，都是物理服務器，不是虛擬服務器。 如下圖所示 4.如何讓客戶端發現所有服務端？ 每個服務器節點都要維護一個對照表 這個對照表中包含所有服務器，（IP地址和IP地址的哈希值對照表） 配置客戶端時，只要讓客戶端知道任意一個服務器的IP地址即可 客戶端可以通過獲取這個服務器的對照表從而知道所有的服務器 客戶端初始化的時候，這個對照表也存儲在客戶端一份 客戶端根據這個對照表來存取數據 注意：這個對照表是有一個版本號的，具體的用途見下面的描述 5.如何應對服務器異常？ 假設數據在節點1上讀寫不成功， 我們就認為這個節點存在異常，要把它從服務器群集中拿掉。 客戶端先在節點2（節點1的熱備節點）上完成相應的讀寫工作，這時客戶端就可以去做其他工作了。 然后節點2向節點0索取數據（這些數據是本應該備份在節點1上的數據） 然后節點2向節點3推送數據(這些數據是節點1上的數據，現在要備份在節點3上) 然后節點2更新其對照表，把節點1從其對照表中移除，并更新對照表的版本號 當有任何客戶端與節點2交互的時候， 就會發現節點2上的對照表的版本號比自己持有的對照表要高 此時，客戶端就更新自己的對照表 這些客戶端再與其他服務器交互的時候 其他服務器發現客戶端攜帶的對照表版本號比自己持有的要高 此時，其他服務器更新自己的對照表 注意：這是一個“發散式的連鎖反應”，不會影響生產。 還可以讓節點2告知節點3需要更新對照表 當節點3更新完之后，再讓節點3告知節點4.... 以此引發“環式的連鎖反應” 注意： 當“服務器環”上連續兩臺服務器同時故障的時候，那么這個系統就崩潰了 可以對數據做兩次熱備份，以提高安全性，但性能和硬件利用率會有所損耗。 6.如何增加服務器？ 首先需要通過配置讓這臺服務器知道節點環上的任意一臺服務器的IP地址（假設是10.0.0.1） 此服務端運行之后，他就會從10.0.0.1上獲取對照表， 以此知道自己在節點環中的具體位置， 它首先需要從它的下一個節點中遷移一部分數據（也就是它上一個節點熱備份的一部分數據） 然后從上一個節點中索取一部分數據(也就是該自己存儲的一部分數據) 然后它把自己加入對照表中， 然后告知10.0.0.1需要更新對照表，以此引發連鎖反應 此文最初的想法是一個alexqiu跟我說的， 后來又仔細研究了一致性哈希算法 并加入了我自己的想法（熱備機制、配置表保存及升級機制） 最終形成此文。 2014年4月9號： 針對此文做了技術分享，錄音文件地址：http://url.cn/KxFQw5 第一個問題：此文利用IP地址（虛擬IP地址）計算哈希值的辦法尚待進一步考慮和驗證 第二個問題：增減服務器節點均是在"物理節點環"上完成，與“虛擬節點環”沒有關系 第三個問題：除了熱備，還可以在熱備的基礎上實現負載均衡

轉載于:https://www.cnblogs.com/ghjbk/p/7598271.html

總結

以上是生活随笔為你收集整理的分布式缓存服务器设计原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。