一年之前——

未來兩年內(nèi)，系統(tǒng)預估的總訂單數(shù)量可達一億條左右。

按Mysql單表存儲500萬條記錄來算，暫時不必分庫，單庫30個分表是比較合適的水平分表方案。

于是小灰設計了這樣的分表邏輯：

1. 訂單表創(chuàng)建單庫30個分表
2. 對用戶ID和30進行取模，取模結(jié)果決定了記錄存于第幾個分表
3. 查詢時需要以用戶ID作為條件，根據(jù)取模結(jié)果確定查詢哪一個分表

分表方式如下圖(為了便于描述，簡化為5個分表)：

過了兩個月——

又過了半年多——

小灰的回憶告一段落——

1.首先，我們把全量的緩存空間當做一個環(huán)形存儲結(jié)構(gòu)。環(huán)形空間總共分成2^32個緩存區(qū)，在Redis中則是把緩存key分配到16384個slot。

2.每一個緩存key都可以通過Hash算法轉(zhuǎn)化為一個32位的二進制數(shù)，也就對應著環(huán)形空間的某一個緩存區(qū)。我們把所有的緩存key映射到環(huán)形空間的不同位置。

3.我們的每一個緩存節(jié)點(Shard)也遵循同樣的Hash算法，比如利用IP做Hash，映射到環(huán)形空間當中。

4.如何讓key和節(jié)點對應起來呢?很簡單，每一個key的順時針方向最近節(jié)點，就是key所歸屬的存儲節(jié)點。所以圖中key1存儲于node1，key2，key3存儲于node2，key4存儲于node3。

1.增加節(jié)點

當緩存集群的節(jié)點有所增加的時候，整個環(huán)形空間的映射仍然會保持一致性哈希的順時針規(guī)則，所以有一小部分key的歸屬會受到影響。

有哪些key會受到影響呢?圖中加入了新節(jié)點node4，處于node1和node2之間，按照順時針規(guī)則，從node1到node4之間的緩存不再歸屬于node2，而是歸屬于新節(jié)點node4。因此受影響的key只有key2。

最終把key2的緩存數(shù)據(jù)從node2遷移到node4，就形成了新的符合一致性哈希規(guī)則的緩存結(jié)構(gòu)。

2.刪除節(jié)點

當緩存集群的節(jié)點需要刪除的時候(比如節(jié)點掛掉)，整個環(huán)形空間的映射同樣會保持一致性哈希的順時針規(guī)則，同樣有一小部分key的歸屬會受到影響。

有哪些key會受到影響呢?圖中刪除了原節(jié)點node3，按照順時針規(guī)則，原本node3所擁有的緩存數(shù)據(jù)就需要“托付”給node3的順時針后繼節(jié)點node1。因此受影響的key只有key4。

最終把key4的緩存數(shù)據(jù)從node3遷移到node1，就形成了新的符合一致性哈希規(guī)則的緩存結(jié)構(gòu)。

如上圖所示，假如node1的ip是192.168.1.109，那么原node1節(jié)點在環(huán)形空間的位置就是hash(“192.168.1.109”)。

我們基于node1構(gòu)建兩個虛擬節(jié)點，node1-1 和 node1-2，虛擬節(jié)點在環(huán)形空間的位置可以利用(IP+后綴)計算，例如：

hash(“192.168.1.109#1”)，hash(“192.168.1.109#2”)

此時，環(huán)形空間中不再有物理節(jié)點node1，node2，只有虛擬節(jié)點node1-1，node1-2，node2-1，node2-2。由于虛擬節(jié)點數(shù)量較多，緩存key與虛擬節(jié)點的映射關(guān)系也變得相對均衡了。