Redis 高可用性實踐

0×01 前言

Redis 是一個開源的使用 ANSI C 語言編寫、支援網路、可基於記憶體亦可持久化的日誌型、Key-Value 資料庫，並提供多種語言的 API。

如今，網路業務的資料正以更快的速度在成長，資料類型越來越豐富，這對資料處理的速度和能力提出了更高要求。 Redis 是一種開源的記憶體非關係型資料庫，帶給開發人員的體驗是顛覆性的。在自始至終的設計過程中，都充分考慮高效能，這使得 Redis 成為當今速度最快的 NoSQL 資料庫。

考慮高性能的同時，高可用也是很重要的考慮因素。網路 7×24 無間斷服務，在故障期間以最快的速度 Failover，能為企業帶來最小的損失。

那麼，在實際應用中，有哪些高可用架構呢？架構之間有何優劣？我們該怎麼取捨？有哪些最佳實務？

0×02 Sentinel 原理

在講解 Redis 高可用方案之前，我們先來看看 Redis Sentinel 原理是怎麼樣的。

1. Sentinel 叢集透過給定的設定檔發現 master，啟動時會監控 master。透過向 master 發送 info 資訊以獲得該伺服器下方的所有從伺服器。
2. Sentinel 叢集透過指令連線向被監視的主從伺服器發送 hello 訊息 (每秒一次)，該訊息包括 Sentinel 本身的 IP、連接埠、id 等內容，以此來向其他 Sentinel 宣告自己的存在。
3. Sentinel 叢集透過訂閱連接接收其他Sentinel 發送的hello 訊息，以此來發現監視同一個主伺服器的其他Sentinel；叢集之間會互相建立命令連接用於通信，因為已經有主從伺服器作為發送和接收hello 訊息的中介，Sentinel 之間不會建立訂閱連線。
4. Sentinel 集群使用 ping 命令來檢測實例的狀態，如果在指定的時間內（down-after-milliseconds）沒有回复或則返回錯誤的回复，那麼該實例被判為下線。
5. 當failover 主備切換被觸發後，failover 並不會馬上進行，還需要Sentinel 中的大多數Sentinel 授權後才可以進行failover，即進行failover 的Sentinel 會去獲得指定quorum 個的Sentinel 的授權，成功後進入ODOWN 狀態。如在 5 個 Sentinel 中配置了 2 個 quorum，等到 2 個 Sentinel 認為 master 死了就執行 failover。
6. Sentinel 向選為 master 的 slave 發送 SLAVEOF NO ONE 命令，選擇 slave 的條件是 Sentinel 首先會根據 slaves 的優先權來進行排序，優先級越小排名越靠前。如果優先權相同，則查看複製的下標，哪個從 master 接收的複製資料多，哪一個就靠前。如果優先權和下標都相同，就選擇進程 ID 較小的。
7. Sentinel 被授權後，它將會獲得宕掉的master 的一份最新配置版本號(config-epoch)，當failover 執行結束以後，這個版本號將會被用於最新的配置，透過廣播形式通知其它Sentinel，其它的Sentinel 則更新對應master 的配置。

1 到 3 是自動發現機制:

• 以 10 秒一次的頻率，向被監視的 master 發送 info 指令，根據回覆取得 master 目前資訊。
• 以 1 秒一次的頻率，向所有 redis 伺服器、包含 Sentinel 在內發送 PING 命令，透過回復判斷伺服器是否在線。
• 以 2 秒一次的頻率，透過向所有被監視的 master，slave 伺服器發送目前 Sentinel master 訊息的訊息。

4 是偵測機制，5 和 6 是 failover 機制，7 是更新設定機制。 [1]

0×03 Redis 高可用架構

講解完 Redis Sentinel 原理之後，接下來講解常用的 Redis 高可用架構。

• Redis Sentinel 叢集 + 內部網路 DNS + 自訂腳本
• Redis Sentinel 叢集 + VIP + 自訂腳本
• 封裝客戶端直連 Redis Sentinel 連接埠
  • JedisSentinelPool，適用於 Java
  • PHP 基於 phpredis 自行封裝
• Redis Sentinel 叢集 + Keepalived/Haproxy
• Redis M/S + Keepalived
• Redis Cluster
• Twemproxy
• Codis

接下來配合圖逐一講解。

3.1 Redis Sentinel 叢集 + 內網 DNS + 自訂腳本

上圖是已經在線上環境應用的方案。底層是 Redis Sentinel 集群，代理 Redis 主從，Web 端連接內部網路 DNS 提供服務。內網DNS 依照一定的規則分配，例如 xxxx.redis.cache/queue.port.xxx.xxx，第一個段表示業務簡寫，第二個段表示這是Redis 內網域名，第三個段表示Redis 類型，cache 表示緩存，queue 表示隊列，第四個段表示Redis 端口，第五、第六個段表示內網主域名。

當主節點發生故障，例如機器故障、Redis 節點故障或網路不可達，Sentinel 叢集會呼叫 client-reconfig-script 設定的腳本，修改對應連接埠的內網網域名稱。對應連接埠的內網域名指向新的 Redis 主節點。

優點：

• 秒級切換，在 10s 內完成整個切換操作
• 腳本自訂，架構可控制
• 對應用透明，前端不用擔心後端發生什麼變化

缺點：

• 維修成本略高，Redis Sentinel 集群建議投入 3 台機器以上
• 依賴 DNS，存在解析延遲
• Sentinel 模式存在短時間的服務不可用
• 服務透過外網存取不可採用此方案

3.2 Redis Sentinel 群集 + VIP + 自訂腳本

此方案和上一個方案相比，略有不同。第一個方案使用了內部網路 DNS，第二個方案把內部網路 DNS 換成了虛擬 IP。底層是 Redis Sentinel 集群，代理著 Redis 主從，Web 端透過 VIP 提供服務。在部署 Redis 主從的時候，需要將虛擬 IP 綁定到目前的 Redis 主節點。當主節點發生故障，例如機器故障、Redis 節點故障或網路不可達，Sentinel 叢集會呼叫 client-reconfig-script 配置的腳本，將 VIP 漂移到新的主節點上。

優點：

• 秒級切換，在 5s 內完成整個切換操作
• 腳本自訂，架構可控制
• 對應用透明，前端不用擔心後端發生什麼變化

缺點：

• 維修成本略高，Redis Sentinel 集群建議投入 3 台機器以上
• 使用 VIP 增加維修成本，有 IP 混亂風險
• Sentinel 模式存在短時間的服務不可用

3.3 封裝客戶端直連 Redis Sentinel 連接埠

部分業務只能透過外網存取 Redis，上述兩種方案皆不可用，於是衍生出了這種方案。 Web 使用客戶端連接其中一台 Redis Sentinel 叢集中的一台機器的某個端口，然後透過這個端口獲取到當前的主節點，然後再連接到真實的 Redis 主節點進行相應的業務員操作。需要注意的是，Redis Sentinel 連接埠和 Redis 主節點都需要開放存取權限。如果前端業務使用 Java，有 JedisSentinelPool 可以重複使用；如果前端業務使用 PHP，可以在 phpredis 的基礎上做二次封裝。

優點：

• 服務偵測故障及時
• DBA 維護成本低

缺點：

• 依賴客戶端支援 Sentinel
• Sentinel 伺服器和 Redis 節點需要開放存取權
• 對應用有侵入性

3.4 Redis Sentinel 群集 + Keepalived/Haproxy

底層是 Redis Sentinel 集群，代理 Redis 主從，Web 端透過 VIP 提供服務。當主節點發生故障，例如機器故障、Redis 節點故障或網路不可達，Redis 之間的切換透過 Redis Sentinel 內部機制保障，VIP 切換透過 Keepalived 保障。

優點：

• 秒級切換
• 對應用透明

缺點：

• 維護成本高
• 存在腦裂
• Sentinel 模式存在短時間的服務不可用

3.5 Redis M/S + Keepalived

此方案沒有使用到 Redis Sentinel。此方案使用了原生的主從和 Keepalived，VIP 切換透過 Keepalived 保障，Redis 主從之間的切換需要自訂腳本實現。

優點：

• 秒級切換
• 對應用透明
• 部署簡單，維護成本低

缺點：

• 需要腳本實現切換功能
• 存在腦裂

3.6 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 運算不夠自動化

3.7 Twemproxy

From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster

多個同構 Twemproxy（配置相同）同時工作，接受客戶端的請求，根據 hash 演算法，轉發給對應的 Redis。

Twemproxy 方案比較成熟了，之前我們團隊長期使用此方案，但是效果並不是很理想。一方面是定位問題比較困難，另一方面是它對自動剔除節點的支援不是很友善。

優點：

• 開發簡單，對應用幾乎透明
• 歷史悠久，方案成熟

缺點：

• 代理程式影響性能
• LVS 和 Twemproxy 會有節點效能瓶頸
• Redis 擴容非常麻煩
• Twitter 內部已放棄使用該方案，新使用的架構未開源

3.8 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

0×04 最佳實務

所謂的最佳實踐，都是最適合具體場景的實踐。

主推以下方案：

• Redis Sentinel 叢集 + 內部網路 DNS + 自訂腳本
• Redis Sentinel 叢集 + VIP + 自訂腳本

以下是實戰過程中總結出的最佳實踐：

• Redis Sentinel 叢集建議使用 >= 5 台機器
• 不同的大業務可以使用一套 Redis Sentinel 集群，代理該業務下的所有端口
• 依照不同的業務劃分好 Redis 連接埠範圍
• 自訂腳本建議採用 Python 實現，擴展便利
• 自訂腳本需要注意判斷目前的 Sentinel 角色
• 自訂腳本傳入參數：
• 自訂腳本需要遠端 ssh 操作機器，建議使用 paramiko 庫，避免重複建立 SSH 連接，消耗時間
• 加速 SSH 連接，建議關閉以下兩個參數
  • UseDNS no
  • GSSAPIAuthentication no
• 微信或郵件告警，建議 fork 一個進程，避免主程序阻塞
• 自動切換和故障切換，所有操作建議在 15s 以內完成

0×05 小結

此次活動分享了Redis 高可用的必要性、Sentinel 原理、Redis 高可用常用架構和實戰過程中總結出的最佳實踐，希望對讀者有所幫助，如果有需要後續交流的，可以添加我的微信（Wentasy），或寄email到：dbarobinwen@gmail.com

附 PPT 下載：https://github.com/dbarobin/slides

視訊回放：Redis 高可用架構最佳實踐

0×06 致謝

感謝聽雲和維運幫的精心組織，感謝大家冒著大雨前來參加此次活動。這次分享由 IT 大咖說出全程錄影，感謝 IT 大咖說的技術支援。

0×07 參考

[1] jyzhou (2016-06-12). Redis 複製、Sentinel 的搭建和原理說明. Retrieved from http://www.cnblogs.com/zhoujinyi/p/5570024.html.

以上是Redis 高可用性實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！