要保證Redis不會掛掉，也就是提高Redis的高可用性，可以從這么幾個方面考慮。
集群式部署方式Redis單副本：也就是只部署一臺Redis，不需要節點之間的數據同步，架構簡單，部署方便；但是單臺機器畢竟是有風險的，按照題目中【海量數據】的場景，是不能達到高可用要求的。
Redis主從：主從實例可以部署在不同的物理服務器上，充分利用多臺服務器的資源，在主庫發生故障的時候，可以進行主備切換，從而保證系統的穩定運行，甚至可以做到讀寫分離，主庫專門用作寫操作，一臺或多臺備庫進行讀操作；但是當主庫發生故障的時候（如果沒有HA方案的話），是需要手動進行主備切換的。
Redis Sentinel：部署架構分為兩部分【Sentinel集群】和【數據集群】；Sentinel集群是由多個Sentinel節點組成的分布式集群，通常是2N+1臺服務器，可以實現故障發現和轉移、客戶端通知等功能；數據集群用于存儲數據；它能夠解決主從模式下的自動切換問題，并且數據集群是可以橫向擴展的；當然這個架構實現和部署起來，也更為復雜一些；并且這個架構不能做到讀寫分離。
Redis Cluster：Redis 3.0集群，是分布式集群解決方案之一，物理架構中配置2N個節點（主從一一對應），主節點提供讀寫操作，從節點作為備份；數據分布保存在多個節點上，是一種無中心的架構，如果有部分節點發生故障，能夠實現故障自動轉移和切換，用投票機制完成備庫升級為主庫（下文的Redis分片章節，還會介紹到Redis Cluster）。
Redis分片Redis在3.0之前只支持單實例，在此之前，在數據量比較大的情況，通常有幾種方案可以做到把數據分片保存到多臺服務器上。
客戶端分片：分片邏輯被放到了客戶端上，由客戶端根據路由規則，把數據保存不同的Redis實例中，讀取的時候也是根據規則，去對應的實例上讀取數據；但是當Redis實例數量發生變化的時候（增加實例或減少實例），需要手動地調整分片的規則程序；并且這種部署方式，也增加了運維的成本。
Redis代理組件：在這種架構中，客戶端不再直接訪問Redis實例，而是訪問代理組件，由它管理路由的規則；客戶端不需要關心有幾個Redis實例，數據被路由到哪個實例上；但是由于在客戶端和Redis之間增加了一層代理，多多少少也會產生一些性能上的損耗。
Redis Cluster：上文中提到的Redis 3.0集群，這里對數據的存儲和路由方式，再介紹幾句：Redis把所有的Key分成了16384個slot，每個Redis實例負責其中一部分slot；每個Redis都知道每個slot在哪個節點上存儲（實例節點定期做數據交換）；當客戶端訪問到一個Redis實例的時候，如果數據不在這個實例上，那么會通過重定向命令引導客戶端訪問數據所在的實例。
熱點數據挑戰單節點的極限雖然我們已經把數據分散保存到多臺Redis實例上了，但是如果有一個熱點數據被頻繁訪問，超過了單實例的服務器極限，那么該如何解決呢？通常的手段就是做讀寫分離，部署多臺只讀節點，對外提供服務。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。