Tim Yang去年在博客（http://timyang.net）討論一個(gè)有狀態(tài)服務(wù)的場(chǎng)景下如何使用一致性哈希算法的問(wèn)題。其中主要涉及到增加或刪除節點(diǎn)時(shí)引起的系統震蕩。其中也討論了是否使用隨機選取節點(diǎn)，并使用memcached保持選擇的方案。
我們知道一致性哈希算法可以很好的解決增加或刪除節點(diǎn)時(shí)引起的系統震蕩問(wèn)題。采用虛擬節點(diǎn)后，平均的將增刪節點(diǎn)產(chǎn)生的震蕩分配到其他節點(diǎn)上。測試證實(shí)了一致性哈希算法有很良好的平均性。
我們做一個(gè)簡(jiǎn)單測試：
有50個(gè)node，200個(gè)虛節點(diǎn)，100000個(gè)session。分別測試增加10%的節點(diǎn)和刪除10%的節點(diǎn)對系統有多少影響。結果分析如下，
Normal case : nodes count : 50
Added case : nodes count : 55
Reduced case : nodes count : 45
85512 --- 85431
Same percent in added case : 89.218124%
Same percent in reduced case : 89.13361%
（增加或刪除10%的節點(diǎn)后，仍有約89%的session被分配給原有節點(diǎn)）
但測試中暴露了兩個(gè)問(wèn)題，有待以后研究。
一個(gè)是隨著(zhù)節點(diǎn)數的增加，分配給每個(gè)節點(diǎn)的session不再是非常平均。特別是在環(huán)開(kāi)始的幾個(gè)節點(diǎn)分配的較少
第二是當節點(diǎn)數量很多時(shí)，比如2^32大小的尋址空間上，如果節點(diǎn)數量很大，超過(guò)1000個(gè)虛節點(diǎn)，算法性能就開(kāi)始有比較明顯的下降。這可能是由于實(shí)現問(wèn)題，但是還需要調研。
回到原來(lái)的問(wèn)題上，即什么樣的場(chǎng)景適合使用一致性哈希算法。
這里有兩類(lèi)場(chǎng)景，我們先來(lái)討論比較簡(jiǎn)單的情況。
場(chǎng)景一
假設有一種靜態(tài)資源，例如視頻、網(wǎng)頁(yè)、大型log文件等，只有第一次請求時(shí)才加載到系統中。我們希望以后每次對相關(guān)資源的請求都送達到同一個(gè)節點(diǎn)。這樣可以最大限度的利用整個(gè)集群的能力，這也是CDN的基本思路。
這類(lèi)場(chǎng)景的特點(diǎn)是，
1，在高并發(fā)情況下，如何使多個(gè)并發(fā)請求都被發(fā)送到同一節點(diǎn)。
2，session實(shí)際是無(wú)狀態(tài)的
在該情況下，使用一致性哈希是很合適的。我在構建高性能Java服務(wù)器中談到了使用一致性哈希算法替代多線(xiàn)程上同步鎖，從而極大的提高系統性能。就是在這個(gè)場(chǎng)景下實(shí)現的。
場(chǎng)景二
一個(gè)有狀態(tài)服務(wù)，持有大量有狀態(tài)session，且session不斷的被更新和查詢(xún)。
這種類(lèi)型的session是不可能被實(shí)時(shí)更新到數據庫的，因此它們只能在分布式內存中被保持。由于session更新頻繁，且要特別考慮到場(chǎng)景是多線(xiàn)程同時(shí)受理對同一session的多個(gè)請求。因此我們的考慮是，不能完全把session保存在一個(gè)分布式memory中，因為頻繁的更新對CPU和網(wǎng)絡(luò )都有比較大的壓力session異步備份，還是那句話(huà)，這次業(yè)務(wù)可以失敗，但是系統不能因為業(yè)務(wù)無(wú)法更新而停止工作
可以有幾種解決方案，
buddy replication+一致性哈希
借鑒Jboss Cache buddy replication的思路。為了減少網(wǎng)絡(luò )和被備份節點(diǎn)的壓力，我們不希望把session復制到整個(gè)cluster上。但是又希望可以當單點(diǎn)crash后從內存恢復數據。因此我們只把session備份到幾個(gè)節點(diǎn)上，例如當一致性哈希找到了工作節點(diǎn)后，該工作節點(diǎn)再使用固定后綴找到buddy node進(jìn)行復制。
例如，sessionID+"buddy1"；sessionID+"buddy2"；
每次更新本地session的同時(shí)，節點(diǎn)異步的向buddy中的memcached寫(xiě)一個(gè)備份。如果本節點(diǎn)crash，session被分配到其他節點(diǎn)處理，它會(huì )試圖從buddy的memcached中取回狀態(tài)。
whole cluster replication
如果你的服務(wù)要求一個(gè)會(huì )話(huà)都不能丟失，則只能進(jìn)行全cluster復制。這樣可以保證任何一節點(diǎn)活著(zhù)就能繼續進(jìn)行業(yè)務(wù)。我們測試過(guò)一些開(kāi)源產(chǎn)品，比如Jboss InfiniSpan，
在節點(diǎn)數量不大，且網(wǎng)絡(luò )條件很好的情況，僅用UDP進(jìn)行whole cluster replication效果就很好。如果參考其實(shí)可以發(fā)現，通過(guò)NIO/TCP進(jìn)行可序列號對象復制，其速度和可靠性在節點(diǎn)數較多的集群中也可以工作的很好。
以上兩種場(chǎng)景在實(shí)際運營(yíng)的系統中都可勝任，當然對于不同客戶(hù)的不同要求，需要采用不同的架構。另外要考慮到團隊的能力，比如團隊如果一直基于JBoss開(kāi)發(fā)，且用戶(hù)對session狀態(tài)的丟失率有嚴格要求，則采用Jboss Cache是最簡(jiǎn)單的方法。盡管它顯然沒(méi)有一致性哈希這么酷：）
本文純屬原創(chuàng )，歡迎轉載，請注明原網(wǎng)址；
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
