分片(partitioning)就是將你的資料拆分到多個Redis 實例的過程，這樣每個實例將只包含所有鍵的子集.（相關推薦：Redis教學）
1 分片何用
Redis 的分片承擔著兩個主要目標：
• 允許使用很多電腦的記憶體總和來支援更大的資料庫。沒有分片，你就被局限於單機能支援的記憶體容量。
• 允許伸縮運算能力到多核心或多伺服器，伸縮網路頻寬到多伺服器或多網路介面卡。
2 分片基礎
有很多不同的分片標準(criteria).
假想我們有4 個Redis 實例R0，R1， R2，R3，還有很多表示使用者的鍵，像user:1，user:2，… 等等，我們能找到不同的方式來選擇一個指定的鍵儲存在哪個實例中。換句話說，有許多不同的方法來映射一個鍵到一個指定的 Redis 伺服器。
最簡單的執行分片的方式之一是範圍分片(range partitioning)，透過映射物件的範圍到指定的 Redis 實例來完成分片。例如，我可以假設使用者從ID 0 到ID 10000 進入實例R0，使用者從ID 10001 到ID 20000 進入實例R1.
這套辦法行得通，並且事實上在實踐中被採用，然而，這有一個缺點，就是需要一個映射範圍到實例的表格.
這張表需要管理，不同類型的物件都需要一個表，所以範圍分片在Redis 中常常並不可取，因為這比其他分片選配方案低效得多。
一種範圍分片的替代方案是哈希分片(hash partitioning).
這種模式適用於任何鍵，不需要鍵像object_name: 這樣的餓形式，就像這樣簡單
• 使用一個雜湊函數(例如，crc32 雜湊函數) 將鍵名轉換為數字。例如，如果鍵是 foobar，crc32(foobar)將會輸出類似 93024922 的東西。
• 對這個資料進行取模運算，以將其轉換為 0 到 3 之間的數字，這樣這個數字就可以對應到我的 4 個 Redis 實例之一。 93024922 模 4 等於 2，所以我知道我的鍵 foobar 應儲存到 R2 實例。注意：取模運算傳回除法運算的餘數，在許多程式語言總是實作為%運算符。
有許多其他的方式可以分片，從這兩個例子中你就可以知道了。一種哈希分片的高級形式稱為一致性哈希(consistent hashing)，被一些 Redis 客戶端和代理實現。
3 分片實作(理論)
分片可由軟體堆疊中的不同部分來承擔。
• 客戶端分片(Client side partitioning)
客戶端直接選擇正確的節點來寫入和讀取指定鍵,許多Redis 用戶端實作了客戶端分片.
• 代理協助分片(Proxy assisted partitioning)
我們的客戶端發送請求到一個可以理解Redis 協議的代理上.而不是直接發送請求到Redis 實例上.
代理會根據配置好的分片模式,來保證轉發我們的請求到正確的Redis 實例,並返回響應給客戶端.
Redis 和Memcached 的代理Twemproxy 實現了代理協助的分片.
• 查詢路由(Query routing)
你可以傳送你的查詢到一個隨機實例，這個實例會保證轉發你的查詢到正確的節點.
Redis 叢集在客戶端的幫助下，實現了查詢路由的一種混合形式(請求不是直接從Redis 實例轉發到另一個，而是客戶端收到重定向到正確的節點).
#4 分片缺點
Redis 的一些特性與分片在一起時玩的不是很好
• 涉及多個鍵的操作通常不支援。例如，你不能對映射在兩個不同Redis 實例上的鍵執行交集(事實上有辦法做到，但不是直接這麼幹).
• 涉及多個鍵的事務不能使用
• 分片的粒度(granularity)是鍵，所以不能使用一個很大的鍵來分片資料集，例如一個很大的有序集合
• 當使用了分片，數據處理變得更複雜，例如，你需要處理多個RDB/AOF 文件，備份資料時你需要聚合多個實例和主機的持久化文件
• 新增和刪除容量也很複雜。例如，Redis 叢集具有運行時動態添加和刪除節點的能力來支援透明地再均衡數據，但是其他方式，像客戶端分片和代理程式都不支援這個特性。但是，有一種稱為預分片(Presharding)的技術在這一點上能幫上忙。
5 儲存 OR 快取
儘管無論是將 Redis 作為資料儲存還是緩存，Redis 的分片概念上都是一樣的，但是作為資料儲存時有一個重要的限制。當 Redis 作為資料儲存時，一個給定的鍵總是映射到相同的 Redis 實例。當Redis 作為快取時，如果一個節點不可用而使用另一個節點，這並不是一個什麼大問題，按照我們的願望來改變鍵和實例的映射來改進系統的可用性(就是系統回復我們查詢的能力) 。
一致性雜湊實作常常能夠在指定鍵的首選節點不可用時切換到其他節點。類似的，如果你加入一個新節點，部分資料就會開始被儲存到這個新節點。
這裡的主要概念如下：
• 如果 Redis 用作緩存，使用一致性哈希來實現伸縮擴展(scaling up and down)是很容易的。
• 如果 Redis 用作存儲，使用固定的鍵到節點的映射，所以節點的數量必須固定不能改變。否則，當增刪節點時，就需要一個支援再平衡節點間鍵的系統，目前只有Redis 叢集可以做到這一點.
6 預分片
# #我們已經知道分片存在的一個問題，除非我們使用Redis 作為緩存，增加和刪除節點是一件很棘手的事情，使用固定的鍵和實例映射要簡單得多。
然而，資料儲存的需求可能一直在變化。今天我可以接受 10 個 Redis 節點(實例)，但明天我可能需要 50 個節點。
因為 Redis 只有相當少的記憶體佔用且輕量級(一個空閒的實例只是用 1MB 記憶體)，一個簡單的解決辦法是一開始就開啟很多的實例。即使你一開始只有一台伺服器，你也可以在第一天就決定生活在分散式的世界裡，使用分片來運行多個 Redis 實例在一台伺服器上。
你一開始就可以選擇很多數量的實例。例如，32 或 64 個實例能滿足大多數的用戶，並且為未來的成長提供足夠的空間。
這樣，當你的資料儲存需要成長，你需要更多的 Redis 伺服器，你要做的就是簡單地將實例從一個伺服器移到另一個伺服器。當你新加入了第一台伺服器，你就需要把一半的 Redis 實例從第一台伺服器搬到第二台，如此等等。
使用 Redis 複製，你就可以在很小或根本不需要停機時間內完成移動資料：
• 在你的新伺服器上啟動一個空實例。
• 移動數據，配置新實例為來源實例的從服務。
• 停止你的客戶端。
• 更新被移動執行個體的伺服器 IP 位址設定。
• 傳送 SLAVEOF NO ONE 指令至新伺服器上的從節點。
• 以新的更新設定啟動你的客戶端。
• 最後關閉掉舊伺服器上不再使用的實例。
7 分片實作(實務)
到目前為止，我們從理論上討論了 Redis 分片，但是實務如何呢？你該使用什麼系統呢？
7.1 Redis 叢集
Redis 叢集是自動分片和高可用的首選方式.
一旦Redis 叢集可用，以及支援Redis 叢集的用戶端可用，Redis 叢集將會成為Redis 分片的事實標準。
Redis 叢集是查詢路由和客戶端分片的混合模式。
7.2 Twemproxy
Twemproxy 是 Twitter 開發的一個支援 Memcached ASCII 和 Redis 協定的代理。它是單線程的，由 C 語言編寫，運行非常的快。基於 Apache 2.0 授權的開源專案。
Twemproxy 支援自動在多個Redis 實例間分片，如果節點不可用時，還有可選的節點排除支援(這會改變鍵和實例的映射，所以你應該只在將Redis 作為緩存是才使用這個特性)。
這不是單點故障(single point of failure)，因為你可以啟動多個代理，並且讓你的客戶端連接到第一個接受連接的代理。
從根本上來說，Twemproxy 是介於客戶端和 Redis 實例之間的中間層，這可以在最下的額外複雜性下可靠地處理我們的分片。這是目前建議的處理Redis 分片的方式.
7.3 支援一致性雜湊的客戶端
Twemproxy 以外的可選方案，是使用實現了客戶端分片的客戶端，透過一致性哈希或別的類似演算法。有多個支援一致性雜湊的 Redis 用戶端，例如 Redis-rb 和 Predis。
請查看完整的 Redis 用戶端列表，看看是不是有支援你的程式語言的，並實現了一致性哈希的成熟客戶端。
以上是Redis分片(分散式快取)的詳細內容。更多資訊請關注PHP中文網其他相關文章！
