優點：
秒級切換，在 5s 內完成整個切換操作
腳本自定義，架構可控
對應用透明，前端不用擔心後端發生什麼變化
缺點：
維護成本略高，Redis Sentinel 集群建議投入 3 臺機器以上
使用 VIP 增加維護成本，存在 IP 混亂風險
Sentinel 模式存在短時間的服務不可用
3.3 封裝客戶端直連 Redis Sentinel 端口
3、封裝客戶端直連 Redis Sentinel 端口
部分業務只能通過外網訪問 Redis，上述兩種方案均不可用，於是衍生出了這種方案。Web 使用客戶端連接其中一臺 Redis Sentinel 集群中的一臺機器的某個端口，然後通過這個端口獲取到當前的主節點，然後再連接到真實的 Redis 主節點進行相應的業務員操作。需要注意的是，Redis Sentinel 端口和 Redis 主節點均需要開放訪問權限。如果前端業務使用 Java，有 JedisSentinelPool 可以複用；如果前端業務使用 PHP，可以在 phpredis 的基礎上做二次封裝。
優點：
服務探測故障及時
DBA 維護成本低
缺點：
依賴客戶端支持 Sentinel
Sentinel 服務器和 Redis 節點需要開放訪問權限
對應用有侵入性
4、Redis Sentinel 集群 + Keepalived/Haproxy
Redis Sentinel 集群 + Keepalived/Haproxy
底層是 Redis Sentinel 集群，代理著 Redis 主從，Web 端通過 VIP 提供服務。當主節點發生故障，比如機器故障、Redis 節點故障或者網絡不可達，Redis 之間的切換通過 Redis Sentinel 內部機制保障，VIP 切換通過 Keepalived 保障。
優點：
秒級切換
對應用透明
缺點：
維護成本高
存在腦裂
Sentinel 模式存在短時間的服務不可用
5、Redis M/S + Keepalived
Redis M/S + Keepalived
此方案沒有使用到 Redis Sentinel。此方案使用了原生的主從和 Keepalived，VIP 切換通過 Keepalived 保障，Redis 主從之間的切換需要自定義腳本實現。
優點：
秒級切換
對應用透明
部署簡單，維護成本低
缺點：
需要腳本實現切換功能
存在腦裂
6、Redis Cluster
Redis Cluster
From: http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster
Redis 3.0.0 在 2015 年 4 月 2 日正式發佈，距今已有兩年多的時間。Redis 集群採用 P2P 模式，無中心化。把 key 分成 16384 個 slot，每個實例負責一部分 slot。客戶端請求對應的數據，若該實例 slot 沒有對應的數據，該實例會轉發給對應的實例。另外，Redis 集群通過 Gossip 協議同步節點信息。
優點：
組件 all-in-box，部署簡單，節約機器資源
性能比 proxy 模式好
自動故障轉移、Slot 遷移中數據可用
官方原生集群方案，更新與支持有保障
缺點：
架構比較新，最佳實踐較少
多鍵操作支持有限（驅動可以曲線救國）
為了性能提升，客戶端需要緩存路由表信息
節點發現、reshard 操作不夠自動化
7、Twemproxy
Twemproxy
From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster
多個同構 Twemproxy（配置相同）同時工作，接受客戶端的請求，根據 hash 算法，轉發給對應的 Redis。
Twemproxy 方案比較成熟了，之前我們團隊長期使用此方案，但是效果並不是很理想。一方面是定位問題比較困難，另一方面是它對自動剔除節點的支持不是很友好。
優點：
開發簡單，對應用幾乎透明
歷史悠久，方案成熟
缺點：
代理影響性能
LVS 和 Twemproxy 會有節點性能瓶頸
Redis 擴容非常麻煩
Twitter 內部已放棄使用該方案，新使用的架構未開源
8、Codis
Codis
From: https://github.com/CodisLabs/codis
Codis 是由豌豆莢開源的產品，涉及組件眾多，其中 ZooKeeper 存放路由表和代理節點元數據、分發 Codis-Config 的命令；Codis-Config 是集成管理工具，有 Web 界面供使用；Codis-Proxy 是一個兼容 Redis 協議的無狀態代理；Codis-Redis 基於 Redis 2.8 版本二次開發，加入 slot 支持，方便遷移數據。
優點：
開發簡單，對應用幾乎透明
性能比 Twemproxy 好
有圖形化界面，擴容容易，運維方便
缺點：
代理依舊影響性能
組件過多，需要很多機器資源
修改了 Redis 代碼，導致和官方無法同步，新特性跟進緩慢
開發團隊準備主推基於 Redis 改造的 reborndb
四、最佳實踐
所謂的最佳實踐，都是最適合具體場景的實踐。
主推以下方案：
Redis Sentinel 集群 + 內網 DNS + 自定義腳本
Redis Sentinel 集群 + VIP + 自定義腳本
以下是實戰過程中總結出的最佳實踐：
Redis Sentinel 集群建議使用 >= 5 臺機器
不同的大業務可以使用一套 Redis Sentinel 集群，代理該業務下的所有端口
根據不同的業務劃分好 Redis 端口範圍
自定義腳本建議採用 Python 實現，擴展便利
自定義腳本需要注意判斷當前的 Sentinel 角色
自定義腳本傳入參數：
自定義腳本需要遠程 ssh 操作機器，建議使用 paramiko 庫，避免重複建立 SSH 連接，消耗時間
加速 SSH 連接，建議關閉以下兩個參數
UseDNS no
GSSAPIAuthentication no
微信或者郵件告警，建議 fork 一個進程，避免主進程阻塞
自動切換和故障切換，所有操作建議在 15s 以內完成
閱讀更多 Java技術進階 的文章
