複製的問題

 由於複製中，每個資料庫都是擁有完整的資料，因此複製的總資料儲存量受限於記憶體最小的資料庫節點，如果資料量過大，複製就無能為力了。

分片

分片（Patitioning）就是將資料拆分到多個redis例項的過程，這樣每個Redis例項將只包含完整資料的一部分。

分片場景

常見的分片方式:

1、按照範圍分片

2、雜湊分片，例如一致性雜湊

常見的分片的實現：

①客戶端分片

②通過代分片，比如：twemproxy

③查詢路由：就是傳送查詢到一個隨機例項，這個例項會保證轉發你的查詢到正確的節點，redis叢集在客戶端的幫助下，實現了查詢路由的一種混合形式，請求不是直接從redis例項轉發到另一個例項，而是客戶端收到重定向到正確的節點

④在服務端進行分片，Redis採用雜湊槽（hash slot）的方式在伺服器端進行分片：

Redis叢集有16384個雜湊槽，使用健CrC16對16384取模來計算一個鍵所屬的雜湊槽

Redis分片的缺點

1、不支援涉及多建的操作，如mget，如果所操作的健都在同一個節點，就正常執行，否則會提示報錯

2、分片的粒度是健，因此每個鍵對應的值不要太大

3、資料備份會比較麻煩，備份資料時你需要聚合多個例項和主機的持久化檔案

4、擴容的處理比較麻煩

5、故障的恢復的處理會比較麻煩，可能需要重新梳理Master和Slave的關係，並調整每個複製集裡面的資料

Redis叢集

由於資料量過大，單個複製集難以承擔，因此需要對多個複製集進行叢集，形成水平擴充套件，每個複製集只負責儲存資料集的一部分，這就是Redis的叢集

1、在以前版本中，Redis的叢集是依靠客戶端分片來完成，但是這樣會有很多缺點，比如維護成本高，需要客戶端編碼解決；增加、移除節點都比較繁瑣等

2、Redis3.0新增的一大特性就是支援叢集，在不降低效能的情況下，還提供了網路分割槽的可訪問性和支援對主資料庫故障的恢復。

3、使用集群后，都只能使用預設的0號資料庫

4、每個redis叢集節點需要兩個TCP連線開啟，正常的TCP埠用來服務客戶端，例如6379，家10000的埠用作資料埠，必須保證防火牆開啟這兩個埠

5、Redis叢集不保證強一致性，這意味著在特定的條件下，Redis叢集可能會丟掉一些被系統收到的寫入請求命令（Master傳播命令返回OK後掛掉，slave還沒有收到廣播）

叢集的架構

1、所有的Redis節點彼此互聯，內部使用二進位制協議優化傳輸速度和寬頻

2、節點的fail是通過叢集中超過半數的節點檢測失效時才生效

3、客戶端與redis節點直連，不需要中間的proxy層。客戶端不需要連線叢集所有節點，連線叢集中任何一個可用節點即可

4、叢集把所有的物理節點對映到【0-16383】插槽上，叢集負責維護：節點—插槽—值 的關係

叢集操作的基本命令

CLUSTER INFO

CLUSTER NODES

CLUSTER MEET <IP> <PORT>

CLUSTER FORGET <NODE_ID>

CLUSTER REPLICATE <NODE_ID>

CLUSTER SAVECONFIG

CLUSTER ADDSLOTS <SLOT>

CLUSTER DELSLOTS <SLOT>

CLUSTER FLUSHSLOTS <SLOT>

CLUSTER SETSLOT <SLOT> NODE <NODE_ID>

CLUSTER SETSLOT <SLOT> MIGRATING <NODE_ID>

CLUSTER SETSLOT <SLOT> IMPORTING <NODE_ID>

CLUSTER SETSLOT <SLOT> STABLE

CLUSTER KEYSLOT <KEY>

CLUSTER COUNTKEYSINSLOT <SLOT>

CLUSTER GETKEYSINSLOT <SLOT> <COUNT>

MIGRATE 目的節點<ip> 目的節點<port> 鍵名 資料庫號碼 超時時間 [copy] [replace]