前言
Redis 作為最常用的 key-value 服務，一直為我們帶來了高性能的保障。但程式嘛，總不可能一直運作下去，而我們所要做的就是将這些風險降到最低。
是以，高可用也是 Redis 必然要考慮的了，而随着 Redis 的廣泛使用，市面上也出現了有很多高可用方案。今天，就來好好認識下這些方案，或許也可以為我們自己的程式帶來靈感。
高可用機制
Redis 的高可用從總體上來講是通過 備援 + 故障轉移 來實作的，而對于備援和故障轉移又可以細化為：全部備援或部分備援；手動轉移或自動轉移。
全部備援+手動轉移的方案就是我們最熟悉的主從模式了；當手動轉移變為自動轉移時即哨兵模式。最後部分備援 + 自動轉移則是叢集模式。
由于 Redis 不像 mysql，在資料的完整性、一緻性上是沒有比較好的保障的，是以當我們在使用高可用方案時，對資料的一緻性就期望不了那麼高了，這是需要提前注意的。
主從模式
主從模式在高可用方案中是最常用的一種。往往我們會在不同的機器上部署着同一 Redis 程式。在這多台機器裡，我們會選擇一個節點作為主節點，它負責資料的寫入。其他節點作為從節點，定時的和主節點同步資料。一旦主節點不能使用了，那麼就可以在從節點中挑選一個作為主節點，重新上崗服務。
主從模式往往還能進行讀寫分離，将讀取資料的壓力分散到多個從節點上。
在 Redis 進行主從資料同步時，會執行 bgsave 指令以生成 RDB 檔案，同時會在緩沖區記錄增量的指令。
當 Redis 将 RDB 檔案同步給 Slave 後，會再次的将緩沖區的增量指令發送給從節點，從節點接收到這些資料後，就可以恢複到記憶體裡了。
從節點除了恢複資料外，它還維護了一個複制偏移量，表示主節點向從節點傳遞指令的位元組總數。這個複制偏移量會定時同步給主節點。
而主節點也有屬于自己的一個寫入偏移量，有了這 2 個參數後，主節點就知道要進行部分複制還是要全量複制了。
主從模式在出現故障時，需要人為進行幹預，而且從節點一多，主節點的同步壓力就會很大了。
哨兵模式
上面的主從模式需要人工的進行故障節點切換，這種方式對于追求完美的程式員來說，肯定是不夠的。是以有了自動切換的哨兵模式。
哨兵模式主要實作了下面幾個功能：
- 監控：不斷的檢測主從節點是否能正常工作。
- 自動轉移故障：當某個 master 不能正常工作時，Sentinel 會啟動一個故障轉移過程，将其中的一個副本提升為 master，并通知其他從節點對應新的 master 相關資訊。
- 通知：當某個節點出問題時，會告知所有節點。如果是新的主節點被選舉出來，還會告知已連接配接過來的用戶端程式關于主節點新的位址。
在哨兵模式中，會有一個或多個哨兵程式，對目前的 Redis 叢集進行監控。哨兵服務之間通過 gossip 協定進行通信。當需要進行故障轉移時，會通過選舉算法，選出一個 leader 來主導過程。
而這也意味着，Sentinel 程式不能選舉出 leader 的話，則不能繼續執行後續動作了。包括用戶端的請求，也會被阻塞住。
叢集
主從模式和哨兵模式都會在多台機器中存儲着同一份資料，這樣對于記憶體的使用率并不高。如果能夠将資料分散到各個節點上，同時配上主從模式，那麼就能高效使用記憶體了。叢集就是這麼個機制。
Redis 的叢集采用了哈希槽的概念，總共會有 16384 個哈希槽。這些哈希槽會被配置設定到各個節點上，比如：
- 節點 1 配置設定了 0 至 5500 的哈希槽。
- 節點 2 配置設定了 5501 至 11000 的哈希槽。
- 節點 3 配置設定了 11001 至 16384 的哈希槽。
當有 key 過來時，Redis 會對其進行 CRC16(key) % 16384 的運算，看目前的 key 要分散到哪個哈希槽上，再根據目前的哈希槽定位到對應的節點上。這樣就完成了一次 key-value 的存儲了。
讀取也是按這規則來，不同的是，如果運算結果所對應的節點不在目前節點上，則會轉發給對應的節點去處理。
當有節點進行新增或删除時，會重新劃分這些哈希槽，當然，影響的隻會是周圍節點，不會造成整個叢集不可用。
在這些節點背後還有屬于它們的從節點，一旦主節點不可用，那麼這些從節點就會被啟用，以保證系統的正常運作。
總結
從主從到哨兵再到叢集，它們的實施難度是從易到難。一般對于大多數項目來講，主從模式就足夠應付了。如果并發量比較高，資料量也很大，那再來考慮叢集。畢竟，項目架構是在不斷演變的，往往有了具體的使用場景，好的方案才能發揮出對應的價值。