Redis分區實作原理介紹-Redis-PHP中文網

Redis分區實作原理介紹

Redis Partitioning即Redis分區，簡單的說就是將資料分佈到不同的redis實例中，因此對於每個redis實例所儲存的內容僅僅是所有內容的子集。

我們為什麼要分割？分區的動機是什麼？通常來說，Redis分區的好處大致有以下兩個面向：

1、效能的提升，單機Redis的網路I/O能力和運算資源是有限的，將請求分散到多台機器，充分利用多台機器的運算能力可網路頻寬，有助於提高Redis整體的服務能力。

2、儲存的橫向擴展，即使Redis的服務能力能夠滿足應用需求，但是隨著儲存資料的增加，單一機器受限於機器本身的儲存容量，將資料分散到多台機器上儲存使得Redis服務可以橫向擴展。

總的來說，分區使得我們本來受限於單一電腦硬體資源的問題不再是問題，儲存不夠？運算資源不夠？頻寬不夠？我們都可以透過增加機器來解決這些問題。

Redis分區基礎

實際應用程式中有很多分區的具體策略，舉個例子，假設我們已經有了一組四個Redis實例分別為R0、 R1、R2、R3，另外我們有一批代表使用者的鍵，如：user:1，user:2，…等等，其中「user:」後面的數字代表的是使用者的ID，我們要做的事情是把這些鍵分散儲存在這四個不同的Redis實例上。怎麼做呢？最簡單的一種方式是範圍分區(range partitioning)，下面我們來看看基於範圍分區怎麼做。

範圍分區

所謂範圍分區，就是將一個範圍內的key都映射到同一個Redis實例中，加入數據集還是上面提到的用戶數據，具體做法如下：

我們可以將使用者ID從0到10000的使用者資料對應到R0實例，而將使用者ID從10001到20000的物件對應到R1實例，依序類別推。

這種方法雖然簡單，但是在實際應用中是很有效的，不過還是有問題：

#我們需要一張表，這張表用來儲存用戶ID範圍到Redis實例的映射關係，例如使用者ID0-10000的是映射到R0實例…。

我們不僅需要對這張表進行維護，而且對於每種對象類型我們都需要一個這樣的表，比如我們當前存儲的是用戶信息，如果存儲的是訂單信息，我們就需要再建一張映射關係表。

如果我們想要儲存的資料的key並不能依照範圍劃分怎麼辦，例如我們的key是一組uuid，這個時候就不好用範圍分割區了。

因此，在實際應用中，範圍分區並不是很好的選擇，不用擔心，我們還有更好的方法，接下來認識下哈希分區。

哈希分區

哈希分區跟範圍分區相比一個明顯的優點是哈希分區適合任何形式的key，而不像範圍分區一樣需要key的形式為object_name:，而且分區方法也很簡單，一個公式就可以表達：

id=hash(key)%N

登入後複製

其中id代表Redis實例的編號，公式描述的是先根據key和一個hash函數（如crc32函數）計算出一個數值型的值。接著上面的例子，我們的第一個要處理的key是user:1，hash（user:1）的結果是93024922。

然後哈希結果進行取模，取模的目的是計算出一個介於0到3之間的值，因此這個值才可以被映射到我們的一個Redis實例上面。例如93024922%4結果是2，我們就會知道foobar將要存放在R2上面。

不同的分區實作

分區可以在redis軟體堆疊的不同部分實現，我們來看看下面幾種：

#客戶端實作

客戶端實作即key在redis客戶端就決定了要被儲存在那台Redis實例中，見下圖：

Redis分區實作原理介紹

上面為客戶端實作Redis分區的示意圖。

代理實作

代理實作即客戶端將請求發送到代理伺服器，代理伺服器實作了Redis協議，因此代理伺服器可以代理客戶端和Redis伺服器通信。代理伺服器透過設定的分區schema來將客戶端的請求轉送到正確的Redis實例中，同時將回饋訊息傳回給客戶端。代理實現Redis分區示意圖如下：

Redis分區實作原理介紹

Redis和Memcached代理Twemoroxy都實現了代理分區。

查詢路由

查詢路由是Redis Cluster實作的一種Redis分割方式：

Redis分區實作原理介紹

查詢路由的過程中，我們可以將查詢請求隨機的傳送到任何一個Redis實例，這個Redis實例負責將請求轉送到正確的Redis實例中。 Redis叢集實作了一個透過和客戶端協作的hybrid來做查詢路由。

Redis分區的缺點

儘管Redis分區到現在為止，so far so good，但是Redis分區有一些致命的缺點，這導致一些Redis功能在分區的環境下並不能很好地工作，我們來看看：

多鍵操作是不被支援的，例如我們將要批量操作的鍵被映射到了不同的Redis實例中。

多鍵的Redis事務是不被支援的。

分區的最小粒度是鍵，因此我們不能將關聯到一個鍵的很大的資料集對應到不同的實例。

當應用分區的時候，資料的處理是非常複雜的，例如我們需要處理多個rdb/aof文件，將分佈在不同實例的文件聚集到一起備份。

新增和刪除機器是很複雜的，例如Redis叢集支援幾乎運行時透明的因為增加或減少機器而需要做的rebalancing,然而像客戶端和代理分區這種方式是不支援這種功能的。

持久性儲存用還是快取

儘管資料分區對Redis來說無論是資料持久化儲存還是緩存，在概念上都是一樣的，然而對於數據持久化儲存還是有一個很大的限制。當我們使用Redis來作為持久化儲存的時候，每一個key必須一直被映射到同一個Redis實例。而當Redis被當做快取使用的時候，對於這個key，如果一個實例不能用了，這個key還可以被映射到其他的實例中。

Consistent hashing實作通常使得當一個key被映射到的實例不能用的時候將這個key映射到其他實例成為可能。類似，如果增加了一台機器，一部分的key將會被映射到這台新的機器上，我們需要了解的兩點如下：

1、如果Redis被用來當做緩存，且要求容易增加或刪除機器，使用consistent hashing是非常簡單的。

2、如果Redis被用來當做（持久）存儲，一個固定的key到實例的映射是需要的，因此我們不能夠再靈活的添加或刪除機器。否則，我們需要在增加或刪除機器的時候系統能夠rebalace，而當前Redis Cluster已經支援。

Pre-Sharding

透過上面的介紹，我們知道Redis分區應用起來是有問題的，除非我們只是使用Redis當做緩存，否則對於增加機器或刪除機器是非常麻煩的。

然而，通常我們Redis容量變動在實際應用中是非常常見的，例如今天我需要10台Redis機器，明天可能就需要50台機器了。

鑑於Redis是很輕量級的服務（每個實例只佔用1M），對於上面的問題一種簡單的解決方法是：

我們可以開啟多個Redis實例，儘管是一台實體機器，我們在剛開始的時候也可以開啟多個實例。我們可以從中選擇一些實例，例如32或64個實例來作為我們的工作集群。當一台實體機器儲存不夠的時候，我們可以將一般的實例移到我們的第二台實體機上，依序類別對，我們可以確保叢集中Redis的實例數不變，又可以達到擴充機器的目的。

怎麼移動Redis實例呢？當需要將Redis實例移到獨立的機器上的時候，我們可以透過下面步驟實現：

1、在新的實體機上啟動一個新的Redis實例。

2、將新的實體機當作要移動的那台的slave機器。

3、停止客戶端。

4、更新將要被移動的那Redis實例的IP位址。

5、傳送SLAVEOF ON ONE指令給slave機器。

6、使用新的IP啟動Redis客戶端。

7、關閉不再使用的那個Redis實例。

總結

這篇文章在理解Redis分區概念的基礎之上又介紹了Redis分區常見的幾種實現方式及原理，最後根據實現中遇到的問題引入了Pre -Sharding解決方案。