在業(yè)務(wù)開發(fā)中，緩存服務(wù)和其他數(shù)據(jù)服務(wù)一樣，需要滿足高可用性，而高可用最常用的手段就是 集群擴展。

緩存的集群高可用

目前 Redis 流行的集群方案有 官方 Cluster 方案、twemproxy 代理方案、哨兵模式、Codis 等方案，關(guān)于這幾種方案的具體應(yīng)用，我們在下一課時將詳細(xì)展開講解。

緩存服務(wù)從單點擴展到集群以后，勢必會產(chǎn)生緩存數(shù)據(jù)的分發(fā)問題，假設(shè)我們的緩存服務(wù)器有 3 臺，每臺緩存的數(shù)據(jù)是不相同的，那么我們在更新緩存時，該放置在哪臺機器上呢？根據(jù) key 獲取緩存時，該從哪臺服務(wù)器上獲??？這就涉及緩存的 負(fù)載均衡策略。

關(guān)于緩存集群高可用的配置方式，有數(shù)據(jù)同步和不同步之分。在數(shù)據(jù)同步的方案下，所有節(jié)點之間數(shù)據(jù)都是一樣的，不同節(jié)點互為副本，這種方式不需要關(guān)心緩存數(shù)據(jù)的分發(fā)，實現(xiàn)了緩存集群的最大可用，但是由于冗余了多份緩存數(shù)據(jù)，會造成比較多的服務(wù)器資源浪費；另外一方面，在更新緩存數(shù)據(jù)時，還要考慮不同節(jié)點之間的一致性。

數(shù)據(jù)不同步的方案，就是每個緩存節(jié)點存儲的數(shù)據(jù)不同，在緩存讀寫時使用一定的策略進行分發(fā)。在實際開發(fā)中，大部分都是應(yīng)用數(shù)據(jù)不同步的方案，如果需要冗余數(shù)據(jù)，則可以通過緩存集群主從同步實現(xiàn)。

不同路由方案的擴容問題

在第 22 課時講解數(shù)據(jù)庫分庫分表時，我們分析了數(shù)據(jù)庫分庫分表擴容的問題，分庫分表以后，當(dāng)存儲節(jié)點發(fā)生增加或減少時，合理的配置分表策略，可以使得數(shù)據(jù)遷移最小。

其實不只是數(shù)據(jù)庫，緩存集群也有一樣的問題。下面來看一下幾種負(fù)載均衡策略，以及對應(yīng)的優(yōu)缺點。

哈希取模路由

最常見的方式是對緩存數(shù)據(jù)進行哈希，典型的操作就是通過對緩存 hash（緩存 Key）/ 節(jié)點數(shù)量。

假設(shè)我們有 5 臺緩存服務(wù)器，偽代碼如下：

//獲取緩存服務(wù)器下標(biāo) public Integer getRoute(String key){ int cacheIndex = key.hashcode() % 5; return cacheIndex; }

哈希取模的方式，適合對固定數(shù)量的緩存集群進行路由，但是對橫向擴展不友好。如果緩存機器數(shù)量發(fā)生變更過，比如從 5 臺服務(wù)器調(diào)整為 10 臺服務(wù)器，原來的緩存數(shù)據(jù)無法分配到正確機器，就會出現(xiàn)路由不正確，從而業(yè)務(wù)請求直接落到數(shù)據(jù)庫上。

一致性哈希

在負(fù)載均衡策略中，可以應(yīng)用一致性哈希，減少節(jié)點擴展時的數(shù)據(jù)失效或者遷移的情況。維基百科對一致性哈希是這么定義的：

一致性哈希是一種特殊的哈希算法。在使用一致性哈希算法后，哈希表槽位數(shù)（大?。┑母淖兤骄恍枰獙?K/n 個關(guān)鍵字重新映射，其中 K 是關(guān)鍵字的數(shù)量，n 是槽位數(shù)量。然而在傳統(tǒng)的哈希表中，添加或刪除一個槽位幾乎需要對所有關(guān)鍵字進行重新映射。

一致性哈希通過一個哈希環(huán)實現(xiàn)，Hash 環(huán)的基本思路是獲取所有的服務(wù)器節(jié)點 hash 值，然后獲取 key 的 hash，與節(jié)點的 hash 進行對比，找出順時針最近的節(jié)點進行存儲和讀取。

以電商中的商品數(shù)據(jù)為例，假設(shè)我們有 4 臺緩存服務(wù)器：

• A 服務(wù)器，地址 hash 結(jié)果是 100

• B 服務(wù)器，地址 hash 結(jié)果是 200

• C 服務(wù)器，地址 hash 結(jié)果是 300

• D 服務(wù)器，地址 hash 結(jié)果是 400

現(xiàn)在有某條數(shù)據(jù)的 Key 進行哈希操作，得到 200，則存儲在 B 服務(wù)器；某條數(shù)據(jù)的 Key 進行哈希操作，得到 260，則存儲在 C 服務(wù)器；某條數(shù)據(jù)的 Key 進行哈希操作，得到 500，則存儲在 A 服務(wù)器。

一致性哈希算法在擴展時，只需要遷移少量的數(shù)據(jù)就可以。例如，我們剛才的例子中，如果 D 服務(wù)器下線，原先路由到 D 服務(wù)器的數(shù)據(jù)，只要順時針遷移到 A 服務(wù)器就可以，其他服務(wù)器不受影響，我們只需要移動一臺機器的數(shù)據(jù)即可。

一致性哈希雖然對擴容和縮容友好，但是存在另外一個問題，就很容易出現(xiàn)數(shù)據(jù)傾斜。

相信你已經(jīng)考慮到了，假設(shè)我們有 A、B、C 一直到 J 服務(wù)器，總共 10 臺，組成一個哈希環(huán)。如果從 F 服務(wù)器一直到 J 服務(wù)器的 5 個節(jié)點宕機，那么這 5 臺服務(wù)器原來的訪問，都會被轉(zhuǎn)移到服務(wù)器 A 之上，服務(wù)器的流量可能是原來的 5 倍或者更高，直到把服務(wù)器 A 打爆，這時候流量繼續(xù)轉(zhuǎn)移到 B 服務(wù)器，就出現(xiàn)我們在第 34 課時提到的 緩存雪崩。

那么數(shù)據(jù)傾斜是如何解決的呢? 一個方案就是添加虛擬節(jié)點，對服務(wù)器節(jié)點也進行哈希操作，在整個哈希環(huán)上，均勻添加若干個節(jié)點。比如 a1 和 a2 都屬于 A 節(jié)點，b1、b2 都屬于 B 節(jié)點，這樣在哈希時可以平衡各個節(jié)點的數(shù)據(jù)。

另外，在面試中，面試官可能會要求你實現(xiàn)一致性哈希算法。以 Java 為例，可以應(yīng)用 TreeMap 這個數(shù)據(jù)結(jié)構(gòu)。

TreeMap 基于紅黑樹實現(xiàn)，元素默認(rèn)按照 keys 的自然排序排列，對外開放了一個 tailMap(K fromKey) 方法，該方法可以返回比 fromKey 順序的下一個節(jié)點，大大簡化了一致性哈希的實現(xiàn)。這里我就不添加代碼了，感興趣的同學(xué)可以去動手模擬實現(xiàn)一下。

總結(jié)

這一課時的內(nèi)容，和你分享了應(yīng)用緩存集群的知識點，包括集群下的高可用，以及哈希取模和一致性哈希的負(fù)載均衡策略。

一致性哈希算法的應(yīng)用，主要是考慮到分布式系統(tǒng)每個節(jié)點都有可能失效，并且新的節(jié)點很可能動態(tài)地增加進來的情況，如何保證當(dāng)系統(tǒng)的節(jié)點數(shù)目發(fā)生變化的時候，我們的系統(tǒng)仍然能夠?qū)ν馓峁┝己玫姆?wù)。

負(fù)載均衡在分布式系統(tǒng)設(shè)計中是非常重要的一部分，今天主要關(guān)注的是數(shù)據(jù)路由方案，除了數(shù)據(jù)路由，負(fù)載均衡在 API 網(wǎng)關(guān)、分布式服務(wù)調(diào)用中也非常關(guān)鍵。在服務(wù)調(diào)用中常用的負(fù)載均衡策略還包括輪訓(xùn)、隨機，根據(jù)響應(yīng)時間判斷等。在你的工作中，有哪些場景用到了負(fù)載均衡，又是如何進行應(yīng)用的呢？歡迎留言進行分享。