《從Redis分區的優缺點來看適合的應用場景》要點：
本文介紹了從Redis分區的優缺點來看適合的應用場景，希望對您有用。如果有疑問，可以聯系我們。

Redis Partitioning即Redis分區,簡單的說就是將數據分布到不同的redis實例中,因此對于每個redis實例所存儲的內容僅僅是所有內容的一個子集.分區(Partitioning)不僅僅是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>,而且分區方法也很簡單,一個公式就可以表達：

id=hash(key)%N

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

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

當然除了上面提到的兩種分區方法,還有很多其他的方法.比如一種從哈希分區演進而來的consistent hashing分區,相信信息可以參考我的另一篇文章《memcached分布式實現原理》,其已經被redis client和proxies實現了.

三、不同的分區實現

分區可以在redis軟件棧的不同部分被實現,我們來看看下面幾種：

客戶端實現

客戶端實現即key在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,然而像客戶端和代理分區這種方式是不支持這種功能的.

既然有問題,那么就需要解決方案,這個時候Pre-sharding來了,后面我們會介紹Pre-Sharding.

五、持久存儲用還是緩存

盡管數據分區對于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. 對于slave機器發送SLAVEOF ON ONE命令.
6. 使用新的IP啟動Redis客戶端.
7. 關閉不再使用的那個Redis實例.

七、總結

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

參考文獻

《Redis官方文檔》

文/陸晨

原文出處——http://my.oschina.net/andylucc技術博客

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4516.html