一致性雜湊演算法在2023年由麻省理工學院提出的一種分布式雜湊（dht）實現演算法，設計目標是為了解決網際網路中的熱點(hot spot)問題，初衷和carp十分類似。一致性雜湊修正了carp使用的簡 單雜湊演算法帶來的問題，使得分布式雜湊（dht）可以在p2p環境中真正得到應用。
一致性hash演算法提出了在動態變化的cache環境中，判定雜湊演算法好壞的四個定義：
1. 平衡性(balance)：
平衡性是指雜湊的結果能夠盡可能分布到所有的緩衝中去，這樣可以使得所有的緩衝空間都得到利用。很多雜湊演算法都能夠滿足這一條件。
2. 單調性(monotonicity)：
單調性是指如果已經有一些內容通過雜湊分派到了相應的緩衝中，又有新的緩衝加入到系統中。雜湊的結果應能夠保證原有已分配的內容可以被對映到原有的或者新的緩衝中去，而不會被對映到舊的緩衝集合中的其他緩衝區。
3. 分散性(spread)：
在分布式環境中，終端有可能看不到所有的緩衝，而是只能看到其中的一部分。當終端希望通過雜湊過程將內容對映到緩衝上時，由於不同終端所見的緩衝範圍有可能不同，從而導致雜湊的結果不一致，最終的結果是相同的內容被不同的終端對映到不同的緩衝區中。這種情況顯然是應該避免的，因為它導致相同內容被儲存到不同緩衝中去，降低了系統儲存的效率。分散性的定義就是上述情況發生的嚴重程度。好的雜湊演算法應能夠盡量避免不一致的情況發生，也就是盡量降低分散性。
4. 負載(load)：
負載問題實際上是從另乙個角度看待分散性問題。既然不同的終端可能將相同的內容對映到不同的緩衝區中，那麼對於乙個特定的緩衝區而言，也可能被不同的使用者對映為不同 的內容。與分散性一樣，這種情況也是應當避免的，因此好的雜湊演算法應能夠盡量降低緩衝的負荷。
一致性雜湊是一種特殊的雜湊方式。傳統的雜湊方式在當節點數目發生變化時，會引起大量的資料遷移，而使用一致性雜湊則不會產生這種問題。一致性雜湊最早是乙個分布式快取（distributed caching）系統的放置演算法（現在很熱門的memcached就用的是一致性雜湊）。但是現在它已經被廣泛應用到了其它各個領域。對於任何乙個雜湊函式，其輸出值都有乙個取值範圍，我們可以將這個取值區間畫成乙個環，如下圖所示：
通過雜湊函式，每個節點都會被分配到環上的乙個位置，每個鍵值也會被對映到環上的乙個位置。這個鍵值最終被放置在距離該它的位置最近的，且位置編號大於等於該值的節點上面，即放置到順時針的下乙個節點上面。下圖形象的表示了這種放置方案，其中node 0上面放置range 0上面的資料，以此類推。
由於採用的雜湊函式通常是與輸入無關的均勻函式，因此當鍵值和節點都非常的多的時候，一致性雜湊可以達到很好的分布式均勻性。並且由於特殊的放置規則，一致性雜湊在節點資料發生變動時可以將影響控制在區域性區間內，從而保證非常少的資料遷移（接近理論上的最小值）。當增加乙個節點時，只有這個節點所在的區間內的資料需要被重新劃分，如下圖中，只需要將range 2上面的資料會從node 1中遷移到node 3上面。當刪除乙個節點時，只需要將這個節點上面的資料遷移到下乙個節點上面，比如刪除node 3，只把range 2上面的資料遷移到node 1上面就可以並，而其它的資料是不需要遷移變動的。
一致性雜湊有非常廣泛的應用，key-value系統，文件資料庫或者分布式關聯式資料庫都可以使用。amazon的nosql系統dynamo應用採用的就是一種改進的一致性雜湊演算法。在這個系統中又引入了虛擬節點的概念，使得這個演算法的load balance更加的好，並且同時考慮了複製技術。環上的點就變成了虛擬節點，然後再採用其它的方式將這些虛擬節點對映到實際的物理節點上面去。這使得系統有很好的可擴充套件性和可用性。
一致性hash演算法實現：
consistent hashing implementation in c：
資料庫水平分表
1.前言 但資料庫資料到達千萬級別的時候，查詢如果不按索引查就會非常慢，於是這裡打算利用水平分表來優化一下查詢，提高效率 2.分表 取我當前表的某一列的前兩個數字進行二級分表，將千萬資料化分成十萬。首先執行迴圈建表 create procedure sum1 a int begin declare ...
Mycat水平分片策略（水平分表拆分）
可以實現按照地區進行分表 根據不同的列舉 常量 進行分表儲存 1.mysql中建立3個資料庫分別為user db1 user db2 user db3 2.在3個資料庫中建立3個一樣的資料表 order info order info表中有字段name 3.配置mycat環境 schema.xml ...
資料庫水平分表（hash演算法）
這種預估大差不差的，論壇裡面發表帖子的表，時間長了這張表肯定很大，幾十萬，幾百萬都有可能。聊天室裡面資訊表，幾十個人在一起一聊乙個晚上，時間長了，這張表的資料肯定很大。像這樣的情況很多。所以這種能預估出來的大資料量表，我們就事先分出個n個表，這個n是多少，根據實際情況而定。以聊天資訊表為例 我事先建...