Redis 的幾種常見使用方式包括：
1.Redis 單一副本；
2.Redis 多重副本（主從） ;
3.Redis Sentinel（哨兵）；
4.Redis Cluster;
5.Redis 自研。
Redis 單一副本，採用單一Redis 節點部署架構，沒有備用節點即時同步數據，不提供資料持久化和備份策略，適用於資料可靠性要求不高的純快取業務場景。
優點：
架構簡單，部署方便；
高性價比：快取使用時無需備用節點（單一實例可用性可以用supervisor 或crontab 保證），當然為了滿足業務的高可用性，也可以犧牲一個備用節點，但同時刻只有一個實例對外提供服務；
高效能。
缺點：
不保證資料的可靠性；
在快取使用，進程重啟後，資料遺失，即使有備用的節點解決高可用性，但仍然不能解決快取預熱問題，因此不適用於資料可靠性要求高的業務；
高效能受限於單核心CPU 的處理能力（Redis 是單執行緒機制），CPU 為主要瓶頸，所以適合操作指令簡單，排序、計算較少的場景。也可以考慮 Memcached 替代。
Redis 多副本，採用主從（replication）部署結構，相較於單副本而言最大的特點就是主從實例間數據即時同步，並提供資料持久化和備份策略。公司的基礎環境配置使得可以採用主從實例部署在不同的實體伺服器上，從而實現同時對外提供服務和讀寫分離策略。
優點：
高可靠度：一方面，採用雙機主備架構，能夠在主庫發生故障時自動進行主備切換，從庫提升為主庫提供服務，確保服務順利運作；另一方面，開啟資料持久化功能和配置合理的備份策略，能有效的解決資料誤操作和資料異常遺失的問題；
讀寫分離策略：從節點可以擴展主庫節點的讀取能力，有效應對大並發量的讀取操作。
缺點：
故障復原複雜，如果沒有RedisHA 系統（需要開發），當主庫節點發生故障時，需要手動將一個從節點晉升為主節點，同時需要通知業務方變更配置，並且需要讓它從庫節點去複製新主庫節點，整個過程需要人為幹預，比較繁瑣；
主庫的寫入能力受到單機的限制，可以考慮分片；
主函式庫的儲存能力受到單機的限制，可以考慮Pika；
原生複製的弊端在早期的版本中也會比較突出，如：Redis 複製中斷後，Slave 會發起psync，此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓；又由於COW 機制，導致極端情況下的主庫內存溢出，程式異常退出或宕機；主庫節點產生備份檔案導致伺服器磁碟IO 和CPU（壓縮）資源消耗；發送數GB 大小的備份檔案導致伺服器出口頻寬暴增，阻塞請求，建議升級到最新版本。
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）。
合理設定參數，防止誤切，控制切換靈敏度控制：
a. quorum
b. down-after-milliseconds 30000
c. failover-timeout 180000
d. maxclient
e. timeout
部署的各個節點伺服器時間盡量要同步，否則日誌的時序性會混亂。
Redis 建議使用 pipeline 和 multi-keys 操作，減少 RTT 次數，提高請求效率。
自行搞定配置中心（zookeeper），方便客戶端對實例的連結存取。
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 分佈於不同的節點上時無法使用事務功能。
不能將一個包含較大鍵值物件（如hash、list等）的資料對應到不同的節點中，因為在資料分區中，鍵是最小的粒度。
不支援多資料庫空間，單機下的 redis 可以支援到 16 個資料庫，在叢集模式下只能使用 1 個資料庫空間，即 db 0。
複製結構只支援一層，從節點只能複製主節點，不支援巢狀樹狀複製結構。
避免產生 hot-key，導致主庫節點成為系統的短板。
避免產生 big-key，導致網卡撐爆、慢查詢等。
重試時間應該大於 cluster-node-time 時間。
Redis Cluster 不建議使用 pipeline 和 multi-keys 操作，減少 max redirect 產生的場景。
分享一份面試寶典《Java核心知識點整理.pdf》“，覆蓋了JVM、鎖、高並發、反射、Spring原理、微服務、Zookeeper、資料庫、資料結構等等”，還有Java208道面試題（含答案）加入（Java高級架構）705127209 即可免費取得！
Redis 自研的高可用解決方案，主要體現在配置中心、故障偵測和failover 的處理機制上，通常需要根據企業業務的實際線上環境來客製化。
優點：
高可靠性、高可用性；
#自主可控性高；
貼切業務實際需求，可縮性好，相容性好。
缺點：
實現複雜，開發成本高；
需要建立配套的周邊設施，如監控，網域服務，儲存元資料資訊的資料庫等；
維護成本高。
以上是Redis常見使用方式有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！
