原文地址：http://redis.io/topics/partitioning

分區(qū)：如何在多個redis實例之間分割數(shù)據(jù)

    分區(qū)就是把你的數(shù)據(jù)分割到多個redis實例的過程，以便每個實例只包含你所擁有的key的子集。文檔的第一部分將向你介紹分區(qū)的概念，第二部分將向你展示區(qū)分可選擇的策略。

為什么分區(qū)是有用的

在redis服務器中的分區(qū)主要包含兩個目標：

• 通過利用多臺計算機內存的和值，允許我們構造更大的數(shù)據(jù)庫。
• 通過多核和多臺計算機，允許我們擴展計算能力；通過多臺計算機和網絡適配器，允許我們擴展網絡帶寬。

分區(qū)基礎知識

    這里有不同的分區(qū)標準。設想我們有4個redis實例R0，R1，R2，R3，很多 key表現(xiàn)為user:0，user:1，......等等，我們可以找到不同的方式來定位一個給定的key存儲在哪臺實例上。換句話說就是有不同的系統(tǒng)用來映射給定的key與給定的redis實例。

一種最簡單的分區(qū)方式是范圍分區(qū)，它是通過把范圍內的對象映射到特定的redis實例來實現(xiàn)的。例如，我可以定義id 0-10000將進入R0，而id10001-20000進入R1等等。

    這種系統(tǒng)，在實踐中確實被采用，然而，它存在不足，它需要一個表用來映射范圍與redis實例。這個表是需要管理的，并且對于每種類型的對象，我們都需要一個表。通常來講，這對于redis不是個好主意。

范圍分區(qū)的一個替代方案就是hash分區(qū)。

• 對key做hash運算，獲得一個數(shù)字。例如，可以采用crc32函數(shù)，結果會輸出類似于93024922的數(shù)值。
• 對獲得數(shù)值取模，就能夠獲得實例。

不同的分區(qū)實現(xiàn)

• 客戶端實現(xiàn)分區(qū)

由客戶端直接選擇正確的節(jié)點來讀寫key。

• 代理輔助分區(qū)

        客戶端發(fā)送請求給代理，代理能夠通過redis協(xié)議與redis會話。代理通過配置的分區(qū)方案，確保把我們的請求轉發(fā)到正確的redis實例上，并且把響應返回給客戶端。redis和memcached代理Twemproxy實現(xiàn)了代理輔助分區(qū)。

• 查詢路由

你可以發(fā)送你的請求到一個隨機的實例，這個實例將確保把你的請求轉發(fā)到正確的實例。在客戶端的幫助下，redis集群實現(xiàn)了混合形式的查詢路由(請求不是直接從一個redis實例轉發(fā)到另外一個實例，而是客戶端獲得重定向后，訪問正確的節(jié)點)

分區(qū)的不足

redis的一些特性在分區(qū)方面表現(xiàn)的不是很好：

• 涉及多個key的操作通常是不被支持的。舉例來說，當兩個set映射到不同的redis實例上時，你就不能對這兩個set執(zhí)行交集操作。
• 涉及多個key的redis事務不能使用。
• 當使用分區(qū)時，數(shù)據(jù)處理較為復雜，比如你需要處理多個rdb/aof文件，并且從多個實例和主機備份持久化文件。
• 增加或刪除容量也比較復雜。redis集群大多數(shù)支持在運行時增加、刪除節(jié)點的透明數(shù)據(jù)平衡的能力，但是類似于客戶端分區(qū)、代理等其他系統(tǒng)則不支持這項特性。然而，一種叫做presharding的技術對此是有幫助的。

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

    當使用redis作為數(shù)據(jù)存儲和緩存時，分區(qū)在概念上是相同的，然而這里還是有很大的不同。當redis作為數(shù)據(jù)存儲使用時，你必須確定，一個給定的key應該總是映射到同一個實例上，當redis被用作緩存使用時，如果我們使用了不同的節(jié)點，即使給定的一個節(jié)點是無法獲得的，這也不是一個大問題。當我們希望提供系統(tǒng)的可用性時，可以通過改變key到實例的映射來實現(xiàn)這一點。

    如果對于一個給定的key，其首選節(jié)點不可用，一致性hash實現(xiàn)通常能夠把key切換到其他節(jié)點。同樣，如果添加一個新節(jié)點，部分新key也將被存儲到新節(jié)點中，主要概念如下：

• 如果redis被用作cache scale up 、scale down時，使用一致性hash比較容易。
• 如果redis被用作存儲，我們需要固定key與節(jié)點之間的映射，并且固定節(jié)點的數(shù)量。否則在增加或者刪減節(jié)點時，我們需要一個有能力再平衡key與節(jié)點的系統(tǒng)。而且目前只有redis集群能夠做到這一點，但目前redis集群仍是beta版，還沒有考慮生產環(huán)境的準備。

Presharding

    我們知道，分區(qū)面臨的問題是，除非我們使用redis作為緩存，否則增加、刪除節(jié)點可能是棘手的，并且使用固定的key到實例的映射是比較簡單的。

然而，數(shù)據(jù)存儲的需求可能會隨時間而變化的。今天，我可能需要10個節(jié)點，但是明天，我可能需要50個節(jié)點。

    由于redis占用空間較小且是輕量級的，一個解決該問題的簡單方法就是，一開始的時候就啟動大量實例。即使你開始只啟動一臺服務器，自第一天起，你可以決定生活在一個分布式的世界里，在你唯一的服務器上運行多個redis實例，使用分區(qū)。

    你可以在啟動時選擇足夠數(shù)量的實例，比如，32或者64個實例可能是大多數(shù)用戶的常見做法，同時這種做法也提供了足夠的增長空間。

這樣，當你的數(shù)據(jù)存儲需要增加或者需要更多的redis服務器時，你所需要做的就是把實例從一臺服務器遷移到另外一臺。一旦你增加第一個額外的服務器，你就需要把半數(shù)的redis實例從第一臺服務器遷移第二臺，依此類推。

使用redis復制技術，你就有可能非停機或者最小數(shù)據(jù)量遷移實施。

• 在新服務器上啟動空實例。
• 移動數(shù)據(jù)，配置這些新實例為源實例的從庫。
• 停止client。
• 更改被移動的實例的配置為新服務器ip。
• 向新服務器上的從庫發(fā)送SLAVEOF NO ONE命令。
• 按更新的配置，重啟client。
• 最后關閉老的服務器上不再使用的實例。

redis分區(qū)實現(xiàn)

到目前為止，我們從理論上討論了redis分區(qū)，但應如何實踐？我們該采用什么系統(tǒng)？

redis 集群

    redis集群是獲得自動切分和高可用性的首選方法。它現(xiàn)在還不具備實施到生產環(huán)境，但已經進入到最后的測試階段，所以我們建議你開始嘗試它。你可以在 Cluster tutorial.獲得過多redis集群信息。

    一旦redis集群可用，且如果對于你使用的語言，有配套的redis集群客戶端，那么redis集群將成為redis分區(qū)的事實標準。

redis集群是介于查詢路由與客戶端分區(qū)的混合體。

Twemproxy

    Twemproxy是由Twitter開發(fā)的支持Memcached ASCII和Redis協(xié)議的一個代理。它是單線程的，C語言實現(xiàn)，且相當?shù)目臁Ｋ窃?/span>Apache 2許可條款下開源的。

    Twemproxy支持多個redis實例之間的自動分區(qū)，并支持不可用節(jié)點彈出的功能(這將改變key到實例的映射，如果你把redis作為緩存使用，可以利用這個特性)。

    Twemproxy是非單點故障的，因為你可以啟動過個代理，并且通知客戶端連接到第一個可接受連接的代理。

    Twemproxy是客戶端與redis實例之間的中間層，它能以最小的額外復雜度為我們處理分區(qū)。從目前來看，它是建議的redis分區(qū)處理方式。

你可以從這里獲得更多關于Twemproxy的信息。
Twemproxy介紹：http://www.cnblogs.com/yuxingfirst/archive/2013/02/05/2892947.html

支持一致性hash的客戶端

    另外一種替代Twemproxy的方案，就是使用實現(xiàn)分區(qū)(一致性hash或者其他算法)的客戶端。有不少客戶端都支持一致性hash特別是Redis-rb 和Predis。請查看完整的redis客戶端列表，檢查是否存在使用你的語言實現(xiàn)了一致性hash的成熟的客戶端。