redis是單執行緒，但是一般的作為快取使用的話，redis足夠了，因為它的讀寫速度太快了。

　　　   官方的一個簡單測試：

　　　　　　測試完成了50個併發執行100000個請求。

　　　　　　設定和獲取的值是一個256位元組字串。

　　　　　　結果:讀的速度是110000次/s,寫的速度是81000次/s 

　　　　在這麼快的讀寫速度下，對於一般程式來說足夠用了，但是對於訪問量特別大的網站來說，還是稍有不足。那麼，如何提升redis的效能呢？看標題就知道了，搭建叢集。

　　3.0版本之前

　　　　3.0版本之前的redis是不支援叢集的，我們的徐子睿老師說，那個時候，我們的redis如果想要叢集的話，就需要一箇中間件，然後這個中介軟體負責將我們需要存入redis中的資料的key通過一套演算法計算得出一個值。然後根據這個值找到對應的redis節點，將這些資料存在這個redis的節點中。

　　　　在取值的時候，同樣先將key進行計算，得到對應的值，然後就去找對應的redis節點，從對應的節點中取出對應的值。

　　　　這樣做有很多不好的地方，比如說我們的這些計算都需要在系統中去進行，所以會增加系統的負擔。還有就是這種叢集模式下，某個節點掛掉，其他的節點無法知道。而且也不容易對每個節點進行負載均衡。

　　3.0版本及以後

　　　　先來一張redis叢集的架構圖：

　　　　在這個圖中，每一個藍色的圈都代表著一個redis的伺服器節點。它們任何兩個節點之間都是相互連通的。客戶端可以與任何一個節點相連線，然後就可以訪問叢集中的任何一個節點。對其進行存取和其他操作。

　　　　那麼redis是怎麼做到的呢？首先，在redis的每一個節點上，都有這麼兩個東西，一個是插槽（slot）可以理解為是一個可以儲存兩個數值的一個變數這個變數的取值範圍是：0-16383。還有一個就是cluster我個人把這個cluster理解為是一個叢集管理的外掛。當我們的存取的key到達的時候，redis會根據crc16的演算法得出一個結果，然後把結果對 16384 求餘數，這樣每個 key 都會對應一個編號在 0-16383 之間的雜湊槽，通過這個值，去找到對應的插槽所對應的節點，然後直接自動跳轉到這個對應的節點上進行存取操作。

　　　　還有就是因為如果叢集的話，是有好多個redis一起工作的，那麼，就需要這個叢集不是那麼容易掛掉，所以呢，理論上就應該給叢集中的每個節點至少一個備用的redis服務。這個備用的redis稱為從節點（slave）。那麼這個叢集是如何判斷是否有某個節點掛掉了呢？

　　　　首先要說的是，每一個節點都存有這個叢集所有主節點以及從節點的資訊。

　　　　它們之間通過互相的ping-pong判斷是否節點可以連線上。如果有一半以上的節點去ping一個節點的時候沒有迴應，叢集就認為這個節點宕機了，然後去連線它的備用節點。如果某個節點和所有從節點全部掛掉，我們叢集就進入faill狀態。還有就是如果有一半以上的主節點宕機，那麼我們叢集同樣進入發力了狀態。這就是我們的redis的投票機制，具體原理如下圖所示：

　　　　(1)投票過程是叢集中所有master參與,如果半數以上master節點與master節點通訊超時(cluster-node-timeout),認為當前master節點掛掉.

　　　　(2):什麼時候整個叢集不可用(cluster_state:fail)? 

    　　　　a:如果叢集任意master掛掉,且當前master沒有slave.叢集進入fail狀態,也可以理解成叢集的slot對映[0-16383]不完整時進入fail狀態. ps : redis-3.0.0.rc1加入cluster-require-full-coverage引數,預設關閉,開啟叢集相容部分失敗.

    　　　　b:如果叢集超過半數以上master掛掉，無論是否有slave，叢集進入fail狀態.

https://www.cnblogs.com/liyasong/p/redis_jiqun.html?utm_source=itdadao&utm_medium=referral