Redis在互聯網大數據平台有着廣泛的應用，主要被用來緩存熱點數據，避免海量請求壓垮數據庫，同時可以提升服務節點的響應速度和並發量。隨着數據量的增多，由於redis是占用單台物理機或虛機的內存，內存資源是有限的，要動態地擴容縮容，就需要用到redis集群。redis集群的架構方案經歷了一系列演變和改良的過程，本文介紹了四種主流的redis架構方案。
客戶端分片
- 優點
不使用第三方中間件，實現方法和代碼可以自己掌控並且可隨時調整。這種分片性能比代理式更好(因為少了分發環節)，分發壓力在客戶端，無服務端壓力增加
- 缺點
不能平滑地水平擴容，擴容/縮容時，必須手動調整分片程序，出現故障不能自動轉移，難以運維
Twemproxy
- 優點
運維成本低。業務方不用關心后端 Redis 實例，跟操作 Redis 一樣。Proxy 的邏輯和存儲的邏輯是隔離的
- 缺點
a. 代理層多了一次轉發，性能有所損耗
b. 進行擴容/縮容時候，部分數據可能會失效，需要手動進行遷移，對運維要求較高，而且難以做到平滑的擴縮容
c. 出現故障，不能自動轉移，運維性很差
Redis Cluster
- 優點
a. 無中心節點
b. 數據按照 Slot 存儲分布在多個 Redis 實例上
c. 平滑的進行擴容/縮容節點
d. 自動故障轉移(節點之間通過 Gossip 協議交換狀態信息,進行投票機制完成 Slave 到 Master 角
色的提升)
e. 降低運維成本，提高了系統的可擴展性和高可用性
- 缺點
a. 嚴重依賴外部 Redis-Trib
b. 缺乏監控管理
c. 需要依賴 Smart Client(連接維護, 緩存路由表, MultiOp 和 Pipeline 支持)
d. Failover 節點的檢測過慢，不如“中心節點 ZooKeeper”及時
e. Gossip 消息的開銷
f. 無法根據統計區分冷熱數據
g. Slave“冷備”，不能緩解讀壓力
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．進行擴容/縮容時候對運維要求較高，而且難以做到平滑的擴縮容
實際項目中該如何選型呢？
redis官方文檔中有如下這段話:
The redis-cli cluster support is very basic so it always uses the fact that Redis Cluster nodes are able to redirect a client to the right node. A serious client is able to do better than that, and cache the map between hash slots and nodes addresses, to directly use the right connection to the right node. The map is refreshed only when something changed in the cluster configuration, for example after a failover or after the system administrator changed the cluster layout by adding or removing nodes.
大意就是目前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->代理->redis cluster，一定規模后基本都采用這種方式。
方案3 自己獨立開發redis智能客戶端
主要實現redis slots管理，failover，一致性hash功能。