****正文****
Redis Partitioning即Redis分區(qū)躺同，簡單的說就是將數(shù)據(jù)分布到不同的redis實例中酝枢，因此對于每個redis實例所存儲的內(nèi)容僅僅是所有內(nèi)容的一個子集。分區(qū)（Partitioning）不僅僅是Redis中的概念氛谜，幾乎是所有數(shù)據(jù)存儲系統(tǒng)都會涉及到的概念燥撞，這篇文章將會在理解分區(qū)基本概念的基礎(chǔ)之上進一步了解Redis對分區(qū)的支持投剥。
****一、我們?yōu)槭裁匆謪^(qū)****
我們?yōu)槭裁匆謪^(qū)迹鹅？分區(qū)的動機是什么卦洽？通常來說，Redis分區(qū)的好處大致有如下兩個方面：
性能的提升斜棚，單機Redis的網(wǎng)絡(luò)I/O能力和計算資源是有限的阀蒂，將請求分散到多臺機器，充分利用多臺機器的計算能力可網(wǎng)絡(luò)帶寬弟蚀，有助于提高Redis總體的服務(wù)能力蚤霞。
存儲的橫向擴展，即使Redis的服務(wù)能力能夠滿足應(yīng)用需求义钉，但是隨著存儲數(shù)據(jù)的增加昧绣，單臺機器受限于機器本身的存儲容量，將數(shù)據(jù)分散到多臺機器上存儲使得Redis服務(wù)可以橫向擴展断医。
總的來說滞乙，分區(qū)使得我們本來受限于單臺計算機硬件資源的問題不再是問題，存儲不夠鉴嗤？計算資源不夠斩启？帶寬不夠？我們都可以通過增加機器來解決這些問題醉锅。
****二兔簇、Redis分區(qū)基礎(chǔ)****
實際應(yīng)用中有很多分區(qū)的具體策略，舉個例子，假設(shè)我們已經(jīng)有了一組四個Redis實例分別為R0垄琐、R1边酒、R2、R3狸窘，另外我們有一批代表用戶的鍵墩朦，如：user:1，user:2翻擒，……等等氓涣，其中“user:”后面的數(shù)字代表的是用戶的ID，我們要做的事情是把這些鍵分散存儲在這四個不同的Redis實例上陋气。怎么做呢劳吠？最簡單的一種方式是范圍分區(qū)(range partitioning)，下面我們來看看基于范圍分區(qū)怎么做巩趁。
****范圍分區(qū)****
所謂范圍分區(qū)痒玩，就是將一個范圍內(nèi)的key都映射到同一個Redis實例中，加入數(shù)據(jù)集還是上面提到的用戶數(shù)據(jù)议慰，具體做法如下：
我們可以將用戶ID從0到10000的用戶數(shù)據(jù)映射到R0實例蠢古，而將用戶ID從10001到20000的對象映射到R1實例，依次類推褒脯。
這種方法雖然簡單便瑟，但是在實際應(yīng)用中是很有效的，不過還是有問題：
我們需要一張表番川，這張表用來存儲用戶ID范圍到Redis實例的映射關(guān)系到涂，比如用戶ID0-10000的是映射到R0實例……。
我們不僅需要對這張表進行維護颁督，而且對于每種對象類型我們都需要一個這樣的表践啄，比如我們當(dāng)前存儲的是用戶信息，如果存儲的是訂單信息沉御，我們就需要再建一張映射關(guān)系表屿讽。
如果我們想要存儲的數(shù)據(jù)的key并不能按照范圍劃分怎么辦，比如我們的key是一組uuid吠裆，這個時候就不好用范圍分區(qū)了伐谈。
因此，在實際應(yīng)用中试疙，范圍分區(qū)并不是很好的選擇诵棵，不用擔(dān)心，我們還有更好的方法祝旷，接下來認(rèn)識下哈希分區(qū)履澳。
****哈希分區(qū)****
哈希分區(qū)跟范圍分區(qū)相比一個明顯的優(yōu)點是哈希分區(qū)適合任何形式的key嘶窄，而不像范圍分區(qū)一樣需要key的形式為object_name:<id>，而且分區(qū)方法也很簡單距贷，一個公式就可以表達：
id=hash(key)%N
其中id代表Redis實例的編號柄冲，公式描述的是首先根據(jù)key和一個hash函數(shù)（如crc32函數(shù)）計算出一個數(shù)值型的值。接著上面的例子忠蝗，我們的第一個要處理的key是user:1现横，hash（user:1）的結(jié)果是93024922。
然后哈希結(jié)果進行取模阁最，取模的目的是計算出一個介于0到3之間的值长赞，因此這個值才可以被映射到我們的一臺Redis實例上面。比如93024922%4結(jié)果是2闽撤，我們就會知道foobar將要被存儲在R2上面。
當(dāng)然除了上面提到的兩種分區(qū)方法脯颜，還有很多其他的方法哟旗。比如一種從哈希分區(qū)演進而來的consistent hashing分區(qū)，相信信息可以參考我的另一篇文章《memcached分布式實現(xiàn)原理》栋操，其已經(jīng)被redis client和proxies實現(xiàn)了闸餐。
****三、不同的分區(qū)實現(xiàn)****
分區(qū)可以在redis軟件棧的不同部分被實現(xiàn)矾芙，我們來看看下面幾種：
****客戶端實現(xiàn)****
客戶端實現(xiàn)即key在redis客戶端就決定了要被存儲在那臺Redis實例中舍沙，見下圖：
[圖片上傳中。剔宪。拂铡。（1）]
客戶端實現(xiàn)分區(qū)示意圖
****代理實現(xiàn)****
代理實現(xiàn)即客戶端將請求發(fā)往代理服務(wù)器，代理服務(wù)器實現(xiàn)了Redis協(xié)議葱绒，因此代理服務(wù)器可以代理客戶端和Redis服務(wù)器通信感帅。代理服務(wù)器通過配置的分區(qū)schema來將客戶端的請求轉(zhuǎn)發(fā)到正確的Redis實例中，同時將反饋消息返回給客戶端地淀。代理實現(xiàn)Redis分區(qū)示意圖如下：
代理實現(xiàn)Redis分區(qū)示意圖
Redis和Memcached代理Twemoroxy都實現(xiàn)了代理分區(qū)失球。
****查詢路由****
查詢路由是Redis Cluster實現(xiàn)的一種Redis分區(qū)方式：
查詢路由Redis分區(qū)示意圖
查詢路由的過程中，我們可以將查詢請求隨機的發(fā)送到任意一個Redis實例帮毁，這個Redis實例負(fù)責(zé)將請求轉(zhuǎn)發(fā)至正確的Redis實例中实苞。Redis集群實現(xiàn)了一個通過和客戶端協(xié)作的hybrid來做查詢路由。
****四烈疚、Redis分區(qū)的缺點****
盡管Redis分區(qū)到現(xiàn)在為止黔牵，so far so good，但是Redis分區(qū)有一些致命的缺點胞得，這導(dǎo)致一些Redis功能在分區(qū)的環(huán)境下并不能很好地工作荧止，我們來看看：
多鍵操作是不被支持的屹电，比如我們將要批量操作的鍵被映射到了不同的Redis實例中。
多鍵的Redis事務(wù)是不被支持的跃巡。
分區(qū)的最小粒度是鍵危号，因此我們不能將關(guān)聯(lián)到一個鍵的很大的數(shù)據(jù)集映射到不同的實例。
當(dāng)應(yīng)用分區(qū)的時候素邪，數(shù)據(jù)的處理是非常復(fù)雜的外莲，比如我們需要處理多個rdb/aof文件，將分布在不同實例的文件聚集到一起備份兔朦。
添加和刪除機器是很復(fù)雜的偷线，例如Redis集群支持幾乎運行時透明的因為增加或減少機器而需要做的rebalancing,然而像客戶端和代理分區(qū)這種方式是不支持這種功能的。
既然有問題沽甥，那么就需要解決方案声邦，這個時候Pre-sharding來了，后面我們會介紹Pre-Sharding摆舟。
****五亥曹、持久存儲用還是緩存****
盡管數(shù)據(jù)分區(qū)對于Redis來說無論是數(shù)據(jù)持久化存儲還是緩存，在概念上都是一樣的恨诱，然而對于數(shù)據(jù)持久化存儲還是有一個很大的限制媳瞪。當(dāng)我們使用Redis來作為持久化存儲的時候，每一個key必須一直被映射到同一個Redis實例照宝。而當(dāng)Redis被當(dāng)做緩存使用的時候蛇受，對于這個key，如果一個實例不能用了厕鹃，這個key還可以被映射到其他的實例中兢仰。
Consistent hashing實現(xiàn)通常使得當(dāng)一個key被映射到的實例不能用的時候?qū)⑦@個key映射到其他實例成為可能。類似熊响，如果增加了一臺機器旨别，一部分的key將會被映射到這臺新的機器上，我們需要了解的兩點如下：
如果Redis被用來當(dāng)做緩存汗茄，且要求容易增加或刪除機器秸弛，使用consistent hashing是非常簡單的。
如果Redis被用來當(dāng)做（持久）存儲洪碳，一個固定的key到實例的映射是需要的递览，因此我們不能夠再靈活的添加或刪除機器。否則瞳腌，我們需要在增加或刪除機器的時候系統(tǒng)能夠rebalace绞铃，當(dāng)前Redis Cluster已經(jīng)支持。
****六嫂侍、Pre-Sharding****
通過上面的介紹儿捧，我們知道Redis分區(qū)應(yīng)用起來是有問題的荚坞，除非我們只是使用Redis當(dāng)做緩存，否則對于增加機器或刪除機器是非常麻煩的菲盾。
然而颓影，通常我們Redis容量變動在實際應(yīng)用中是非常常見的，比如今天我需要10臺Redis機器懒鉴，明天可能就需要50臺機器了诡挂。
鑒于Redis是很輕量級的服務(wù)（每個實例僅僅占用1M），對于上面的問題一種簡單的解決辦法是：
我們可以開啟多個Redis實例临谱，盡管是一臺物理機器璃俗，我們在剛開始的時候也可以開啟多個實例。我們可以從中選擇一些實例悉默，比如32或64個實例來作為我們的工作集群城豁。當(dāng)一臺物理機器存儲不夠的時候，我們可以將一般的實例移動到我們的第二臺物理機上抄课，依次類對钮蛛，我們可以保證集群中Redis的實例數(shù)不變，又可以達到擴充機器的目的剖膳。
怎么移動Redis實例呢？當(dāng)需要將Redis實例移動到獨立的機器上的時候岭辣，我們可以通過下面步驟實現(xiàn)：
在新的物理機上啟動一個新的Redis實例吱晒。
將新的物理機作為要移動的那臺的slave機器。
停止客戶端沦童。
更新將要被移動的那臺Redis實例的IP地址仑濒。
對于slave機器發(fā)送SLAVEOF ON ONE命令。
使用新的IP啟動Redis客戶端偷遗。
關(guān)閉不再使用的那個Redis實例墩瞳。
****七、總結(jié)****
這篇文章在理解Redis分區(qū)概念的基礎(chǔ)之上又介紹了Redis分區(qū)常見的幾種實現(xiàn)方式及原理氏豌，最后根據(jù)實現(xiàn)中遇到的問題引入了Pre-Sharding解決方案喉酌。
