摘要：| 方案 | 描述 | 數據分區支持策略 | 分佈式 |在線數據熱遷移 | |--|--|--| | twemproxy | twitter 開源的redis代理中間件，不修改redis源碼 https://github.com/twitter/twemproxy | 存在modula（固定取模）、 random （隨機）、ketama（哈希一致性）三種可選的配置 | 本身是單點的，可以通過keepalived等保證高可用 | 不支持，無法平滑地擴容/縮容 | |Redis Cluster | 官方提供的集羣方案 | 採用預先分片（PreSharding），即哈希槽方式，存儲在每一個master節點上 | 沒有proxy代理層，客戶端可以連接集羣中的任意master節點 | 提供客戶端命令 redis-cli --cluster reshard ip port 按哈希槽遷移指定節點的數據 | | codis | 豌豆莢開源的redis代理中間件，修改了redis源碼 https://github.com/CodisLabs/codis | 採用預先分片（PreSharding），即哈希槽方式，存儲在ZooKeeper上 | 集羣部署，部署相對複雜 | 支持數據熱遷移 |。但Redis單 Master 實例提供讀寫服務，仍然有容量和壓力問題，因此需要數據分區，構建多個 Master 實例同時提供讀寫服務（不僅限於從 replica 節點提供讀服務）。

Redis爲什麼需要集羣？

首先Redis單實例主要有單點，容量有限，流量壓力上限的問題。

Redis單點故障，可以通過主從複製 replication ，和自動故障轉移 sentinel 哨兵機制。

但Redis單 Master 實例提供讀寫服務，仍然有容量和壓力問題，因此需要數據分區，構建多個 Master 實例同時提供讀寫服務（不僅限於從 replica 節點提供讀服務）。

那麼就需要一定的機制保證數據分區。這樣能充分把容量分攤到多臺計算機，或能充分利用多核計算機的性能。

並且數據在各個主Master節點間不能混亂，當然最好還能支持在線數據熱遷移的特性。

探討數據分區方案

針對數據分區，一般來說，分爲兩個大類：

  • 邏輯拆分： 邏輯上能拆分，比如 Redis 中的 M1 節點 存儲 A服務需要的業務數據，而 Redis 中的 M2 節點存儲 B服務需要的業務數據。
  • 數據分區： 當邏輯上不能拆分，那麼只能按數據來拆分，需要保證客戶端讀和寫數據一致。 因此需要一個高效快速的數據結構來路由對應的 Master 節點。 最容易想到的就是類比 Java 中的 HashMap ， 採用 哈希算法，快速找到，快速設置。 這裏有四種方式，分別是固定取模，隨機，哈希一致性，哈希槽。

固定取模

假設有三個 Master，配置IP 和權重如下：

Real Server IP weight
10.0.2.21 1
10.0.2.22 2
10.0.2.23 3

那麼會根據每一個real Server 及其權重虛擬出對應權重 weight 個的虛擬vritual server節點，映射關係會是：

Real Server IP virtual server
10.0.2.21 1
10.0.2.22 2,3
10.0.2.23 4,5,6

一個 key 存儲在那個虛擬vritual server節點，通過哈希hash算法：

virtual_server_index = hash(key) % (total_virtual_weight)

假設某個key，它的 hash 值是 10，那麼以上： 10%6=4，將落到 10.0.2.23 這個真實的 Master上。

  • 缺點 因爲取模的模數是固定的，當新增或刪除 master節點時，所有的數據幾乎要全部洗牌，幾乎需要重新遷移數據（而且相當麻煩），無法做到在線數據熱遷移。 意味着Redis在此種用法下，只能當緩存，不能當存儲數據庫！

隨機

隨機選取一個存儲和訪問。 一般結合 list ，用於非順序性要求的消息隊列場景。

  • 缺點： 使用場景比較單一。 並且由於隨機性問題，導致持久化存在不可靠性。Redis在此種用法下，也只能當緩存，不能當存儲數據庫！

一致性哈希

一致性哈希算法（ Consistent Hashing ）最早在論文《 Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web 》中被提出。 簡單來說，一致性哈希將整個哈希值空間組織成一個虛擬的圓環，如假設某哈希函數H的值空間爲0-2^32-1（即哈希值是一個32位無符號整形），整個哈希空間環如下：

  • 1.有一個HASH環，環上每個節點都是一個自然數，從0開始順時針遞增，直到2^32-1，最後回到0

  • 2.真實節點 M1 M2 M3 通過 hash（IP 或主機名）確定在哈希環上的位置

  • 3.當客戶端請求時，首先 hash(key) 確定在哈希環上的位置，然後順時針往後找，找到的第一個真實節點，就是客戶端需要請求訪問的真實主機

  • 優點： 哈希一致性其實是對固定取模的一種優化。 （1）擴展性：當增加節點時，只會影響順時針的真實節點（此部分數據比較難遷移），而不是影響全部的節點。 （2）容錯性：當節點宕機或刪除節點時，只會影響逆時針的真實節點，而不是影響全部的節點。 （3）平衡性：當哈希算法的節點過少時，會可能造成某些服務器的數據存儲較多，而另外一些存儲較少，造成數據傾斜，當節點足夠多時，這種現象得以緩解。 因此虛擬節點個數較大的時候，數據的平衡性得以保證。

  • 缺點： 因爲當增刪節點時，需要重新計算受影響部分的節點中的key全部找出來，才能遷移，這個很麻煩！！！ Redis在此種用法下，也只能當緩存，不能當存儲數據庫！

哈希槽（PreSharding，預先分片）

這個跟哈希一致性很相似。 區別在於，它預先分配好真實節點管理的哈希槽（ slot ），並存儲管理起來，我們可以預先知道哪個master主機擁有哪些哈希槽（ slot ）,這裏總數是16384。 

127.0.0.1:7001> cluster nodes
2aaf59558f1b9f493a946a695e51711eb03d15f9 127.0.0.1:7002@17002 master - 0 1590126183862 2 connected 5461-10922
6439c3e9468fd2c545a63b3b9bfe658c5fc14287 127.0.0.1:7003@17003 master - 0 1590126181856 3 connected 10923-16383
340d985880c23de9816226dff5fd903322e44313 127.0.0.1:7001@17001 myself,master - 0 1590126182000 1 connected 0-5460

我們可以清晰看到Redis Cluster中的每一個master節點管理的哈希槽。 比如 127.0.0.1:7001 擁有哈希槽 0-5460， 127.0.0.1:7002 擁有哈希槽 5461-10922， 127.0.0.1:7003 擁有哈希槽 10923-16383。

➜  redis-cli -p 7001         
127.0.0.1:7001> set a 1
(error) MOVED 15495 127.0.0.1:7003

➜  redis-cli -p 7001 -c
127.0.0.1:7001> set a 1
-> Redirected to slot [15495] located at 127.0.0.1:7003
OK

我們看到的是master節點在 Redis Cluster中的實現時，都存有所有的路由信息。 當客戶端的key 經過hash運算，發送 slot 槽位不在本節點的時候。 （1）如果是非集羣方式連接，則直接報告錯誤給client，告訴它應該訪問集羣中那個IP的master主機。 （2）如果是集羣方式連接，則將客戶端重定向到正確的節點上。 注意這裏並不是127.0.0.1:7001 幫client去連接127.0.0.1:7003獲取數據的，而是將客戶端請求重定向了。

  • 優點： 繼承並增強一致性哈希的容錯性，擴展性，以及平衡性。 Redis在此種用法下，可以當緩存，也能當存儲數據庫！

  • 這裏Redis給出更詳細的說明： https://redis.io/topics/partitioning

具體方案

以下列表爲按照出現的先後順序排列：

| 方案 | 描述 | 數據分區支持策略 | 分佈式 |在線數據熱遷移 | |--|--|--| | twemproxy | twitter 開源的redis代理中間件，不修改redis源碼 https://github.com/twitter/twemproxy | 存在modula（固定取模）、 random （隨機）、ketama（哈希一致性）三種可選的配置 | 本身是單點的，可以通過keepalived等保證高可用 | 不支持，無法平滑地擴容/縮容 | |Redis Cluster | 官方提供的集羣方案 | 採用預先分片（PreSharding），即哈希槽方式，存儲在每一個master節點上 | 沒有proxy代理層，客戶端可以連接集羣中的任意master節點 | 提供客戶端命令 redis-cli --cluster reshard ip port 按哈希槽遷移指定節點的數據 | | codis | 豌豆莢開源的redis代理中間件，修改了redis源碼 https://github.com/CodisLabs/codis | 採用預先分片（PreSharding），即哈希槽方式，存儲在ZooKeeper上 | 集羣部署，部署相對複雜 | 支持數據熱遷移 |

@SvenAugustus( https://www.flysium.xyz/ )

更多請關注微信公衆號【編程不離宗】，專注於分享服務器開發與編程相關的技術乾貨：

相關文章