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

分區：如何在多個redis實例之間分割數據

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

為什么分區是有用的

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

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

分區基礎知識

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

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

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

范圍分區的一個替代方案就是hash分區。

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

不同的分區實現

• 客戶端實現分區

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

• 代理輔助分區

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

• 查詢路由

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

分區的不足

redis的一些特性在分區方面表現的不是很好：

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

數據是要存儲還是緩存？

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

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

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

Presharding

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

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

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

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

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

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

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

redis分區實現

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

redis 集群

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

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

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

Twemproxy

    Twemproxy是由Twitter開發的支持Memcached ASCII和Redis協議的一個代理。它是單線程的，C語言實現，且相當的快。它是在Apache 2許可條款下開源的。

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

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

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

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

支持一致性hash的客戶端

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