redis集群 學習參考：
redis集群在啟動的時候就自動在多個節點間分好片。同時提供了分片之間的可用性：當一部分redis節點故障或網路中斷，
集群也能繼續工作。但是，當大面積的節點故障或網路中斷（比如大部分的主節點都不可用了），集群就不能使用。
所以，從實用性的角度，redis集群提供以下功能：
● 自動把資料切分到多個redis節點中
● 當一部分節點掛了或不可達，集群依然能繼續工作
redis集群不是使用一致性雜湊，而是使用雜湊槽。整個redis集群有16384個雜湊槽，決定乙個key應該分配到那個槽的算
法是：計算該key的crc16結果再模16834。
集群中的每個節點負責一部分雜湊槽，比如集群中有３個節點，則：
● 節點ａ儲存的雜湊槽範圍是：0 – 5500
● 節點ｂ儲存的雜湊槽範圍是：5501 – 11000
● 節點ｃ儲存的雜湊槽範圍是：11001 – 16384
這樣的分布方式方便節點的新增和刪除。比如，需要新增乙個節點ｄ，只需要把ａ、ｂ、ｃ中的部分雜湊槽資料移到ｄ節點。
同樣，如果希望在集群中刪除ａ節點，只需要把ａ節點的雜湊槽的資料移到ｂ和ｃ節點，當ａ節點的資料全部被移走後，ａ
節點就可以完全從集群中刪除。
因為把雜湊槽從乙個節點移到另乙個節點是不需要停機的，所以，增加或刪除節點，或更改節點上的雜湊槽，也是不需要停
機的。如果多個key都屬於乙個雜湊槽，集群支援通過乙個命令（或事務, 或lua指令碼）同時操作這些key。通過「雜湊標籤」的概
念，使用者可以讓多個key分配到同乙個雜湊槽。雜湊標籤在集群詳細文件中有描述，這裡做個簡單介紹：如果key含有大括
號」{}」,則只有大括號中的字串會參與雜湊，比如」this」和」another」這２個key會分配到同乙個雜湊槽，
所以可以在乙個命令中同時操作他們。
為了保證在部分節點故障或網路不通時集群依然能正常工作，集群使用了主從模型，每個雜湊槽有一（主節點）到n個副本
（n-1個從節點）。在我們剛才的集群例子中，有a,b,c三個節點，如果b節點故障集群就不能正常工作了，因為ｂ節點中的
雜湊槽資料沒法操作。但是，如果我們給每乙個節點都增加乙個從節點，就變成了：a,b,c三個節點是主節點，a1, b1,
c1 分別是他們的從節點，當b節點宕機時，我們的集群也能正常運作。b1節點是b節點的副本，如果b節點故障，集群會
提公升b1為主節點，從而讓集群繼續正常工作。但是，如果b和b1同時故障，集群就不能繼續工作了。
redis集群的一致性保證
redis集群不能保證強一致性。一些已經向客戶端確認寫成功的操作，會在某些不確定的情況下丟失。
產生寫操作丟失的第乙個原因，是因為主從節點之間使用了非同步的方式來同步資料。
乙個寫操作是這樣乙個流程：
1)客戶端向主節點b發起寫的操作2)主節點b回應客戶端寫操作成功3)主節點b向它的從節點b1,b2,b3同步該寫操作
從上面的流程可以看出來，主節點b並沒有等從節點b1,b2,b3寫完之後再回覆客戶端這次操作的結果。所以，如果主
節點b在通知客戶端寫操作成功之後，但同步給從節點之前，主節點ｂ故障了，其中乙個沒有收到該寫操作的從節點會
晉公升成主節點，該寫操作就這樣永遠丟失了。
就像傳統的資料庫，在不涉及到分布式的情況下，它每秒寫回磁碟。為了提高一致性，可以在寫盤完成之後再回覆客
戶端，但這樣就要損失效能。這種方式就等於redis集群使用同步複製的方式。
基本上，在效能和一致性之間，需要乙個權衡。
linux下Redis集群搭建
redis 5.0 版本後，放棄了ruby的集群方式，本次集群搭建只適用5.0以後版本 第一步 安裝redis 具體操作看這裡 第二步 複製redis配置檔案 進入local檔案，建立redis cluster檔案 cd usr local mkdir redis cluster 在redis cl...
Linux下Redis集群環境的搭建
一 安裝redis 使用redis3.0版本 1 需要gcc環境，如果沒有執行命令安裝gcc yum install gcc c 3 解壓原始碼包 tar zxvf redis 3.0.0.tar.gz4.進入解壓目錄編譯 make5.安裝redis make install prefix usr ...
linux搭建redis集群
上傳 rz 到linux，解壓 tar zxvf 在redis x.x.x裡面的src 包，使用 make install 安裝redis 這裡我建立了7001 7009的資料夾，均只放乙個名為redis.conf的檔案 內容模板如下 port 埠號 cluster enabled yes maxm...