分片(partitioning)就是將你的數(shù)據(jù)拆分到多個 Redis 實例的過程俱尼，這樣每個實例將只包含所有鍵的子集。本文第一部分將向你介紹分片的概念唁情，第二部分將向你展示 Redis 分片的可選方案姻僧。

分片能做什么

Redis 的分片承擔(dān)著兩個主要目標(biāo)：

允許使用很多電腦的內(nèi)存總和來支持更大的數(shù)據(jù)庫。沒有分片份企，你就被局限于單機(jī)能支持的內(nèi)存容量也榄。

允許伸縮計算能力到多核或多服務(wù)器，伸縮網(wǎng)絡(luò)帶寬到多服務(wù)器或多網(wǎng)絡(luò)適配器。

分片基礎(chǔ)

有很多不同的分片標(biāo)準(zhǔn)(criteria)甜紫。假想我們有 4 個 Redis 實例 R0降宅，R1，R2囚霸，R3腰根，還有很多表示用戶的鍵，像 user:1拓型，user:2额嘿，… 等等，我們能找到不同的方式來選擇一個指定的鍵存儲在哪個實例中吨述。換句話說岩睁，有許多不同的辦法來映射一個鍵到一個指定的 Redis 服務(wù)器。

最簡單的執(zhí)行分片的方式之一是范圍分片(range partitioning)揣云，通過映射對象的范圍到指定的 Redis 實例來完成分片捕儒。例如，我可以假設(shè)用戶從 ID 0 到 ID 10000 進(jìn)入實例 R0邓夕，用戶從 ID 10001 到 ID 20000 進(jìn)入實例 R1刘莹，等等。

這套辦法行得通焚刚，并且事實上在實踐中被采用点弯，然而，這有一個缺點矿咕，就是需要一個映射范圍到實例的表格抢肛。這張表需要管理，不同類型的對象都需要一個表碳柱，所以范圍分片在 Redis 中常常并不可取捡絮，因為這要比替他分片可選方案低效得多。

一種范圍分片的替代方案是哈希分片(hash partitioning)莲镣。這種模式適用于任何鍵福稳，不需要鍵像 object_name:?這樣的餓形式，就像這樣簡單：

使用一個哈希函數(shù)(例如瑞侮，crc32 哈希函數(shù)) 將鍵名轉(zhuǎn)換為一個數(shù)字。例如半火，如果鍵是 foobar越妈，crc32(foobar)將會輸出類似于 93024922 的東西。

對這個數(shù)據(jù)進(jìn)行取模運算钮糖，以將其轉(zhuǎn)換為一個 0 到 3 之間的數(shù)字梅掠，這樣這個數(shù)字就可以映射到我的 4 臺 Redis 實例之一。93024922 模 4 等于 2，所以我知道我的鍵 foobar 應(yīng)當(dāng)存儲到 R2 實例瓤檐。注意：取模操作返回除法操作的余數(shù)，在許多編程語言總實現(xiàn)為%操作符娱节。

有許多其他的方式可以分片挠蛉，從這兩個例子中你就可以知道了。一種哈希分片的高級形式稱為一致性哈希(consistent hashing)肄满，被一些 Redis 客戶端和代理實現(xiàn)谴古。

分片的不同實現(xiàn)

分片可由軟件棧中的不同部分來承擔(dān)。

客戶端分片(Client side partitioning)意味著稠歉，客戶端直接選擇正確的節(jié)點來寫入和讀取指定鍵掰担。許多 Redis 客戶端實現(xiàn)了客戶端分片。

代理協(xié)助分片(Proxy assisted partitioning)意味著怒炸，我們的客戶端發(fā)送請求到一個可以理解 Redis 協(xié)議的代理上带饱，而不是直接發(fā)送請求到 Redis 實例上。代理會根據(jù)配置好的分片模式阅羹，來保證轉(zhuǎn)發(fā)我們的請求到正確的 Redis 實例勺疼，并返回響應(yīng)給客戶端。Redis 和 Memcached 的代理 Twemproxy 實現(xiàn)了代理協(xié)助的分片捏鱼。

查詢路由(Query routing)意味著执庐，你可以發(fā)送你的查詢到一個隨機(jī)實例，這個實例會保證轉(zhuǎn)發(fā)你的查詢到正確的節(jié)點导梆。Redis 集群在客戶端的幫助下轨淌，實現(xiàn)了查詢路由的一種混合形式 (請求不是直接從 Redis 實例轉(zhuǎn)發(fā)到另一個，而是客戶端收到重定向到正確的節(jié)點)看尼。

分片的缺點

（1）Redis 的一些特性與分片在一起時玩轉(zhuǎn)的不是很好：

（2）涉及多個鍵的操作通常不支持递鹉。例如，你不能對映射在兩個不同 Redis 實例上的鍵執(zhí)行交集(事實上有辦法做到狡忙，但不是直接這么干)梳虽。

（3）涉及多個鍵的事務(wù)不能使用。

（4）分片的粒度(granularity)是鍵灾茁，所以不能使用一個很大的鍵來分片數(shù)據(jù)集窜觉，例如一個很大的有序集合。

（5）當(dāng)使用了分片北专，數(shù)據(jù)處理變得更復(fù)雜禀挫，例如，你需要處理多個 RDB/AOF 文件拓颓，備份數(shù)據(jù)時你需要聚合多個實例和主機(jī)的持久化文件语婴。

（6）添加和刪除容量也很復(fù)雜。例如，Redis 集群具有運行時動態(tài)添加和刪除節(jié)點的能力來支持透明地再均衡數(shù)據(jù)砰左，但是其他方式匿醒，像客戶端分片和代理都不支持這個特性。但是缠导，有一種稱為預(yù)分片(Presharding)的技術(shù)在這一點上能幫上忙廉羔。

數(shù)據(jù)存儲還是緩存

盡管無論是將 Redis 作為數(shù)據(jù)存儲還是緩存，Redis 的分片概念上都是一樣的僻造，但是作為數(shù)據(jù)存儲時有一個重要的局限憋他。當(dāng) Redis 作為數(shù)據(jù)存儲時，一個給定的鍵總是映射到相同的 Redis 實例髓削。當(dāng) Redis 作為緩存時竹挡，如果一個節(jié)點不可用而使用另一個節(jié)點，這并不是一個什么大問題立膛，按照我們的愿望來改變鍵和實例的映射來改進(jìn)系統(tǒng)的可用性(就是系統(tǒng)回復(fù)我們查詢的能力)揪罕。

一致性哈希實現(xiàn)常常能夠在指定鍵的首選節(jié)點不可用時切換到其他節(jié)點。類似的宝泵，如果你添加一個新節(jié)點耸序，部分?jǐn)?shù)據(jù)就會開始被存儲到這個新節(jié)點上。

這里的主要概念如下：

如果 Redis 用作緩存鲁猩，使用一致性哈希來來實現(xiàn)伸縮擴(kuò)展(scaling up and down)是很容易的坎怪。

如果 Redis 用作存儲，使用固定的鍵到節(jié)點的映射廓握，所以節(jié)點的數(shù)量必須固定不能改變搅窿。否則，當(dāng)增刪節(jié)點時隙券，就需要一個支持再平衡節(jié)點間鍵的系統(tǒng)男应，當(dāng)前只有 Redis 集群可以做到這一點，但是 Redis 集群現(xiàn)在還處在 beta 階段娱仔，尚未考慮再生產(chǎn)環(huán)境中使用沐飘。

預(yù)分片

我們已經(jīng)知道分片存在的一個問題，除非我們使用 Redis 作為緩存牲迫，增加和刪除節(jié)點是一件很棘手的事情耐朴，使用固定的鍵和實例映射要簡單得多。

然而盹憎，數(shù)據(jù)存儲的需求可能一直在變化筛峭。今天我可以接受 10 個 Redis 節(jié)點(實例)，但是明天我可能就需要 50 個節(jié)點陪每。

因為 Redis 只有相當(dāng)少的內(nèi)存占用(footprint)而且輕量級(一個空閑的實例只是用 1MB 內(nèi)存)影晓，一個簡單的解決辦法是一開始就開啟很多的實例镰吵。即使你一開始只有一臺服務(wù)器，你也可以在第一天就決定生活在分布式的世界里挂签，使用分片來運行多個 Redis 實例在一臺服務(wù)器上疤祭。

你一開始就可以選擇很多數(shù)量的實例。例如饵婆，32 或者 64 個實例能滿足大多數(shù)的用戶画株，并且為未來的增長提供足夠的空間。

這樣啦辐，當(dāng)你的數(shù)據(jù)存儲需要增長，你需要更多的 Redis 服務(wù)器蜈项，你要做的就是簡單地將實例從一臺服務(wù)器移動到另外一臺芹关。當(dāng)你新添加了第一臺服務(wù)器，你就需要把一半的 Redis 實例從第一臺服務(wù)器搬到第二臺紧卒，如此等等侥衬。

使用 Redis 復(fù)制，你就可以在很小或者根本不需要停機(jī)時間內(nèi)完成移動數(shù)據(jù)：

在你的新服務(wù)器上啟動一個空實例跑芳。

移動數(shù)據(jù)轴总，配置新實例為源實例的從服務(wù)。

停止你的客戶端博个。

更新被移動實例的服務(wù)器 IP 地址配置怀樟。

向新服務(wù)器上的從節(jié)點發(fā)送 SLAVEOF NO ONE 命令。

以新的更新配置啟動你的客戶端盆佣。

最后關(guān)閉掉舊服務(wù)器上不再使用的實例往堡。

Redis 分片的實現(xiàn)

Redis 集群是自動分片和高可用的首選方式。當(dāng)前還不能完全用于生產(chǎn)環(huán)境共耍，但是已經(jīng)進(jìn)入了 beta 階段虑灰。

一旦 Redis 集群可用，以及支持 Redis 集群的客戶端可用痹兜，Redis 集群將會成為 Redis 分片的事實標(biāo)準(zhǔn)穆咐。

Redis 集群是查詢路由和客戶端分片的混合模式。

Twemproxy 是 Twitter 開發(fā)的一個支持 Memcached ASCII 和 Redis 協(xié)議的代理字旭。它是單線程的对湃，由 C 語言編寫，運行非常的快遗淳。他是基于 Apache 2.0 許可的開源項目熟尉。

Twemproxy 支持自動在多個 Redis 實例間分片，如果節(jié)點不可用時洲脂，還有可選的節(jié)點排除支持(這會改變鍵和實例的映射斤儿，所以你應(yīng)該只在將 Redis 作為緩存是才使用這個特性)剧包。

這并不是單點故障(single point of failure)，因為你可以啟動多個代理往果，并且讓你的客戶端連接到第一個接受連接的代理疆液。

Twemproxy 之外的可選方案，是使用實現(xiàn)了客戶端分片的客戶端陕贮，通過一致性哈隙橛停或者別的類似算法。有多個支持一致性哈希的 Redis 客戶端肮之，例如 Redis-rb 和 Predis掉缺。