redis-cluster的安裝管理
redis-cluster的安裝管理
聲明：
本文只允許用於個人學習交流使用，如有錯誤之處請多多指正。
文檔版本：Version 1.0
修改記錄：2015-10-30
環境介紹
系統環境：RedHat Enterprise Linux Server release 6.2 (Santiago)
內核版本：Linuxzxt-02.com 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64x86_64 x86_64 GNU/Linux
軟件版本：redis-3.0.5
主機名：redis-01.com、redis-02.com
主機IP：192.168.1.193 192.168.1.176
安裝所需軟件環境：
Zlib、ruby（必須1.9.2以上）、rubygem、gem-redis
註：在閱讀文本文檔之前需要讀者知道的是本文檔以及目前網絡上的大部分相近的文檔都來源於http://redis.io。如果您的英文閱讀能較好的話建議您閱讀Reis官方文檔。http://redis.io/topics/cluster-spec
http://redis.io/topics/cluster-tutorial
redis-cluster簡介：
Redis 集群是一個可以在多個Redis節點之間進行數據共享的設施（installation）。Redis 集群不支持那些需要同時處理多個鍵的Redis 命令，因為執行這些命令需要在多個
Redis 集群通過分區（partition）來提供一定程度的可用性（availability）：即使集群中有一部分節點失效或者無法進行通訊，集群也可以繼續處理命令請求。
Redis集群提供了以下兩個好處：
將數據自動切分（split）到多個節點的能力。
當集群中的一部分節點失效或者無法進行通訊時，仍然可以繼續處理命令請求的能力
Redis 集群的數據分片
Redis 集群沒有使用一致性hash,而是引入了哈希槽的概念.
Redis 集群有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽
節點 A 包含 0 到 5500號哈希槽
節點 B 包含5501 到 11000 號哈希槽.
節點 C 包含11001 到 16384號哈希槽.
這種結構很容易添加或者刪除節點. 比如如果我想新添加個節點D,我需要從節點 A, B, C中得部分槽到D上. 如果我像移除節點A,需要將A中得槽移到B和C節點上,然後將沒有任何槽的A節點從集群中移除即可.
由於從一個節點將哈希槽移動到另一個節點並不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態.
Redis 集群的主從復制模型
為了使在部分節點失敗或者大部分節點無法通信的情況下集群仍然可用，所以集群使用了主從復制模型,每個節點都會有N-1個復制品.
在我們例子中具有A，B，C三個節點的集群,在沒有復制模型的情況下,如果節點B失敗了，那麽整個集群就會以為缺少5501-11000這個範圍的槽而不可用.
然而如果在集群創建的時候（或者過一段時間）我們為每個節點添加一個從節點A1，B1，C1,那麽整個集群便有三個master節點和三個slave節點組成，這樣在節點B失敗後，集群便會選舉B1為新的主節點繼續服務，整個集群便不會因為槽找不到而不可用了
不過當B和B1 都失敗後，集群是不可用的.
Redis 一致性保證
Redis 並不能保證數據的強一致性.這意味這在實際中集群在特定的條件下可能會丟失寫操作.
第一個原因是因為集群是用了異步復制. 寫操作過程:
客戶端向主節點B寫入一條命令.
主節點B向客戶端回復命令狀態.
主節點將寫操作復制給他得從節點 B1,B2 和 B3.
主節點對命令的復制工作發生在返回命令回復之後， 因為如果每次處理命令請求都需要等待復制操作完成的話， 那麽主節點處理命令請求的速度將極大地降低 —— 我們必須在性能和一致性之間做出權衡。
註意：Redis 集群可能會在將來提供同步寫的方法。
Redis 集群另外一種可能會丟失命令的情況是集群出現了網絡分區，
本文出自 “無名之輩” 博客，轉載請與作者聯系！
redis-cluster的安裝管理