1、Redis3.0
· 優點
##a. 無中心節點
b. 資料依照 slot 存儲分佈在多個 Redis 實例上c. 平滑的進行擴容/ 縮容節點d.
自動故障轉移##(節點之間經過
Gossip
協議交換狀態資訊,進行投票機製完成# Slave
#到
Master 角色的提升)
#e. 降低運維成本，提高了系統的可擴充性和高可用性
（推薦（免費）：redis
）
##· ##a. ##嚴重依賴外在#Sers- Tribb. 缺乏監控管理
#c. ##需要依賴 Smart Client(連線維護, 快取路由表
, MultiOp
和 Pipeline
支援
)
d. Failover
節點的偵測過慢，不如“ 中心節點 ZooKeeper」
及時
#e.Gossip 訊息的開銷
#f.
無法根據統計區分冷熱資料
#g. Slave「
冷備”，無法緩解讀取壓力
#2、Proxy Redis Cluster
#·
優點##·
優點Smart Client：
##########a. ######比相比於使用代理，減少了一層網絡傳輸的消耗，效率較高######;############b. ######不依賴第三方中間件，實作方法和程式碼自己掌控，可隨時調整。 ############Proxy######：#############a. ######提供一套####### HTTP Restful ######接口，隔離底層儲存。對客戶端完全透明，跨語言呼叫。 ######
b. 升級維護較為容易，維護 Redis Cluster，只需要平滑升級 Proxy。
c. 層次化存儲，底層儲存做冷熱異構存儲。
d. 權限控制，Proxy 可以透過秘鑰控制白名單，把一些不合法的請求都過濾掉。並且也可以控制使用者請求的超大 Value 進行控制和過濾。
e. 安全性，可以屏蔽掉一些危險指令，例如 Keys##、Save、Flush All 等。
f. 容量控制，根據不同使用者容量申請進行容量限制。
g. 資源邏輯隔離，依照不同使用者的 Key 加上前綴，來進行資源隔離。
h. 監控埋點，對於不同的介面進行埋點監控等資訊。
· 缺點
#Smart Client：
a. 客戶端的不成熟，影響應用的穩定性，提高開發難度。
b. MultiOp 和 Pipeline 支援有限。
c. 連線維護，Smart 用戶端對連接到叢集中每個結點 Socket 的維護。
Proxy：
#a. 代理層多了一次轉發，效能有所損耗。
b．進行擴容/縮容時候對運維需求較高，而且難以做到平滑的擴縮容
3 、技術選型
redis官方文件中有以下這段話:
The redis-cli cluster support is very basic so it alwaysuses the fact that Redis Cluster nodes are able to redirect a client to theright node. A serious client is able to do better than that, and cache the map betweenhash slots and nodes addresses, to directly use the right connection to theright node. The map is refreshed only when something changed in the clusterconfiguration, for example after a failover or after the system adflay adf.
##大意就是目前
redis cluster#官方客戶端功能簡陋，依賴redis節點重定向去到叢集中找到資料所在的redis#實例。需要有一個更完善的客戶端，能夠實現一致性hash，failover和叢集管理功能。因此使用官方的redis cluster客戶端不是明智的選擇，本文提供3種方案供大家參考，如果有不合理的地方，歡迎大家與我共同探討。 方案 1 使用nginx開發(OpenResty#方式)
原因如下:
a.單Master多Work模式，每個Work跟Redis一樣都是單一進程單執行緒模式，而且都是基於Epoll事件驅動的模式。
b. Nginx採用了非同步非阻塞的方式來處理請求，高效的非同步框架。
c. 記憶體佔用少，有自己的一套記憶體池管理方式。將大量小記憶體的申請聚集到一塊，能夠比Malloc更快。減少記憶體碎片，防止記憶體洩漏。減少記憶體管理複雜度。
d. 為了提高 Nginx 的存取速度，Nginx 使用了自己的一套連結池。
e. 最重要的是支援自訂模組開發。
f. 業界內，對於Nginx，Redis的口碑可稱得上兩大神器。性能都很好。
方案 2 codis#（豌豆莢採用的基於代理的redis群集方案)
#參考codis官方文件#https:/ /github.com/CodisLabs/codis
Codis是一整套快取解決方案，包含高可用、資料分片、監控、動態擴態# etc.。
走的是 Apps->#代理->rediscluster，一定規模後基本上都採用這種方式。
方案3 自己獨立開發redis智慧型客戶端
主要實作redis slots管理，failover#，一致性 hash功能。
4、Redis 3.0群集
Redis 3.0叢集採用了P2P的模式，完全去中心化。 Redis把所有的Key分成了16384slot，每個Redis實例負責其中一部分slot。叢集中的所有資訊(節點、連接埠、slot等)，都透過節點之間的定期資料交換而更新。
Redis客戶端在任何一個Redis實例發出請求，如果所需資料不在該實例中，透過重定向命令引導客戶端存取所需的實例。
Redis 3.0叢集的工作流程如下圖所示。
Redis叢集內的機器定期交換數據，工作流程如下：
（1） Redis客戶端在Redis2實例上存取某個資料；
（2）#在Redis2 內發現這個資料是在Redis3這個實例中，給Redis客戶端發送一個重定向的指令；
（3） Redis客戶端收到重定向指令後，存取Redis3實例取得所需的資料。
Redis 3.0的叢集方案有以下兩個問題：
1) #一個Redis實例具備了「資料儲存」與“路由重定向”，完全去中心化的設計。這帶來的好處是部署非常簡單，直接部署Redis就行，不像Codis有那麼多的元件和相依性。但帶來的問題是很難對業務進行無痛的升級，若哪天Redis集群出了什麼嚴重的Bug #，就只能回滾整個Redis叢集。
2) #對協定進行了較大的修改，而對應的Redis#「客戶端也需要升級。升級Redis客戶端後誰能確保沒有Bug？而且對於線上已經大規模運作的業務，升級程式碼中的Redis客戶端也是一個很麻煩的事情。
5、Redis4.0
(1)所有的redis節點彼此互聯(PING-PONG##機制 )，內部使用二進位協定最佳化傳輸速度和頻寬；
(2)節點的Fail是透過叢集中超過半數的節點偵測失效時才生效；
(3)客戶端與redis節點直連，不需要中間proxy層。客戶端不需要連接叢集所有節點，連接叢集中任何一個可用節點即可；
(4)redis-cluster把所有的實體節點對應到[0-16383]slot(插槽)上，cluster #負責維護node<->slot<->value。
以上是一起看看Redis叢集架構及對比的詳細內容。更多資訊請關注PHP中文網其他相關文章！
