一、常見使用方式
Redis 的幾種常見使用方式包括：
- Redis 單副本
- Redis 多副本(主從)
- Redis Sentinel(哨兵)
- Redis Cluster
- Redis 自研
二、各種使用方式的優缺點
1、Redis 單副本
Redis 單副本，采用單個 Redis 節點部署架構，沒有備用節點實時同步數據，不提供數據持久化和備份策略，適用於數據可靠性要求不高的純緩存業務場景。
優點：
- 架構簡單，部署方便;
- 高性價比：緩存使用時無需備用節點(單實例可用性可以用 supervisor 或 crontab 保證)，當然為了滿足業務的高可用性，也可以犧牲一個備用節點，但同時刻只有一個實例對外提供服務;
- 高性能。
缺點：
- 不保證數據的可靠性;
- 在緩存使用，進程重啟后，數據丟失，即使有備用的節點解決高可用性，但是仍然不能解決緩存預熱問題，因此不適用於數據可靠性要求高的業務;
- 高性能受限於單核 CPU 的處理能力(Redis 是單線程機制)，CPU 為主要瓶頸，所以適合操作命令簡單，排序、計算較少的場景。也可以考慮用 Memcached 替代。
2、Redis 多副本(主從)
Redis 多副本，采用主從(replication)部署結構，相較於單副本而言最大的特點就是主從實例間數據實時同步，並且提供數據持久化和備份策略。主從實例部署在不同的物理服務器上，根據公司的基礎環境配置，可以實現同時對外提供服務和讀寫分離策略。
優點：
- 高可靠性：一方面，采用雙機主備架構，能夠在主庫出現故障時自動進行主備切換，從庫提升為主庫提供服務，保證服務平穩運行;另一方面，開啟數據持久化功能和配置合理的備份策略，能有效的解決數據誤操作和數據異常丟失的問題;
- 讀寫分離策略：從節點可以擴展主庫節點的讀能力，有效應對大並發量的讀操作。
缺點：
- 故障恢復復雜，如果沒有 RedisHA 系統(需要開發)，當主庫節點出現故障時，需要手動將一個從節點晉升為主節點，同時需要通知業務方變更配置，並且需要讓其它從庫節點去復制新主庫節點，整個過程需要人為干預，比較繁瑣;
- 主庫的寫能力受到單機的限制，可以考慮分片;
- 主庫的存儲能力受到單機的限制，可以考慮 Pika;
- 原生復制的弊端在早期的版本中也會比較突出，如：Redis 復制中斷后，Slave 會發起 psync，此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓;又由於 COW 機制，導致極端情況下的主庫內存溢出，程序異常退出或宕機;主庫節點生成備份文件導致服務器磁盤 IO 和 CPU(壓縮)資源消耗;發送數 GB 大小的備份文件導致服務器出口帶寬暴增，阻塞請求，建議升級到最新版本。
3、Redis Sentinel(哨兵)
Redis Sentinel 是社區版本推出的原生高可用解決方案，其部署架構主要包括兩部分：Redis Sentinel 集群和 Redis 數據集群。
其中 Redis Sentinel 集群是由若干 Sentinel 節點組成的分布式集群，可以實現故障發現、故障自動轉移、配置中心和客戶端通知。Redis Sentinel 的節點數量要滿足 2n+1(n>=1)的奇數個。
優點：
- Redis Sentinel 集群部署簡單;
- 能夠解決 Redis 主從模式下的高可用切換問題;
- 很方便實現 Redis 數據節點的線形擴展，輕松突破 Redis 自身單線程瓶頸，可極大滿足 Redis 大容量或高性能的業務需求;
- 可以實現一套 Sentinel 監控一組 Redis 數據節點或多組數據節點。
缺點：
- 部署相對 Redis 主從模式要復雜一些，原理理解更繁瑣;
- 資源浪費，Redis 數據節點中 slave 節點作為備份節點不提供服務;
- Redis Sentinel 主要是針對 Redis 數據節點中的主節點的高可用切換，對 Redis 的數據節點做失敗判定分為主觀下線和客觀下線兩種，對於 Redis 的從節點有對節點做主觀下線操作，並不執行故障轉移。
- 不能解決讀寫分離問題，實現起來相對復雜。
建議：
- 如果監控同一業務，可以選擇一套 Sentinel 集群監控多組 Redis 數據節點的方案，反之選擇一套 Sentinel 監控一組 Redis 數據節點的方案。
- sentinel monitor配置中的建議設置成 Sentinel 節點的一半加 1，當 Sentinel 部署在多個 IDC 的時候，單個 IDC 部署的 Sentinel 數量不建議超過(Sentinel 數量 – quorum)。
- 合理設置參數，防止誤切，控制切換靈敏度控制：
- quorum
- down-after-milliseconds 30000
- failover-timeout 180000
- maxclient
- timeout
- 部署的各個節點服務器時間盡量要同步，否則日志的時序性會混亂。
- Redis 建議使用 pipeline 和 multi-keys 操作，減少 RTT 次數，提高請求效率。
- 自行搞定配置中心(zookeeper)，方便客戶端對實例的鏈接訪問。
4、Redis Cluster
Redis Cluster 是社區版推出的 Redis 分布式集群解決方案，主要解決 Redis 分布式方面的需求，比如，當遇到單機內存，並發和流量等瓶頸的時候，Redis Cluster 能起到很好的負載均衡的目的。
Redis Cluster 集群節點最小配置 6 個節點以上(3 主 3 從)，其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。
Redis Cluster 采用虛擬槽分區，所有的鍵根據哈希函數映射到 0～16383 個整數槽內，每個節點負責維護一部分槽以及槽所印映射的鍵值數據。
優點：
- 無中心架構;
- 數據按照 slot 存儲分布在多個節點，節點間數據共享，可動態調整數據分布;
- 可擴展性：可線性擴展到 1000 多個節點，節點可動態添加或刪除;
- 高可用性：部分節點不可用時，集群仍可用。通過增加 Slave 做 standby 數據副本，能夠實現故障自動 failover，節點之間通過 gossip 協議交換狀態信息，用投票機制完成 Slave 到 Master 的角色提升;
- 降低運維成本，提高系統的擴展性和可用性。
缺點：
- Client 實現復雜，驅動要求實現 Smart Client，緩存 slots mapping 信息並及時更新，提高了開發難度，客戶端的不成熟影響業務的穩定性。目前僅 JedisCluster 相對成熟，異常處理部分還不完善，比如常見的“max redirect exception”。
- 節點會因為某些原因發生阻塞(阻塞時間大於 clutser-node-timeout)，被判斷下線，這種 failover 是沒有必要的。
- 數據通過異步復制，不保證數據的強一致性。
- 多個業務使用同一套集群時，無法根據統計區分冷熱數據，資源隔離性較差，容易出現相互影響的情況。
- Slave 在集群中充當“冷備”，不能緩解讀壓力，當然可以通過 SDK 的合理設計來提高 Slave 資源的利用率。
- Key 批量操作限制，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 執行批量操作。對於映射為不同 slot 值的 Key 由於 Keys 不支持跨 slot 查詢，所以執行 mset、mget、sunion 等操作支持不友好。
- Key 事務操作支持有限，只支持多 key 在同一節點上的事務操作，當多個 Key 分布於不同的節點上時無法使用事務功能。
- Key 作為數據分區的最小粒度，不能將一個很大的鍵值對象如 hash、list 等映射到不同的節點。
- 不支持多數據庫空間，單機下的 redis 可以支持到 16 個數據庫，集群模式下只能使用 1 個數據庫空間，即 db 0。
- 復制結構只支持一層，從節點只能復制主節點，不支持嵌套樹狀復制結構。
- 避免產生 hot-key，導致主庫節點成為系統的短板。
- 避免產生 big-key，導致網卡撐爆、慢查詢等。
- 重試時間應該大於 cluster-node-time 時間。
- Redis Cluster 不建議使用 pipeline 和 multi-keys 操作，減少 max redirect 產生的場景。
5、Redis 自研
Redis 自研的高可用解決方案，主要體現在配置中心、故障探測和 failover 的處理機制上，通常需要根據企業業務的實際線上環境來定制化。
優點：
- 高可靠性、高可用性;
- 自主可控性高;
- 貼切業務實際需求，可縮性好，兼容性好。
缺點：
- 實現復雜，開發成本高;
- 需要建立配套的周邊設施，如監控，域名服務，存儲元數據信息的數據庫等;
- 維護成本高。