Redis 高可用架構(gòu)最佳實踐

作者：溫國兵

來源：https://www.sohu.com/a/150426358_505802

1 、題記

Redis 是一個開源的使用 ANSI C 語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value 數(shù)據(jù)庫，并提供多種語言的 API。

如今，互聯(lián)網(wǎng)業(yè)務(wù)的數(shù)據(jù)正以更快的速度在增長，數(shù)據(jù)類型越來越豐富，這對數(shù)據(jù)處理的速度和能力提出了更高要求。Redis 是一種開源的內(nèi)存非關(guān)系型數(shù)據(jù)庫，給開發(fā)人員帶來的體驗是顛覆性的。在自始至終的設(shè)計過程中，都充分考慮高性能，這使得 Redis 成為當今速度最快的 NoSQL 數(shù)據(jù)庫。

????

考慮高性能的同時，高可用也是很重要的考慮因素。互聯(lián)網(wǎng) 7x24 無間斷服務(wù)，在故障期間以最快的速度 Failover，能給企業(yè)帶來最小的損失。

那么，在實際應(yīng)用中，都有哪些高可用架構(gòu)呢？架構(gòu)之間有何優(yōu)劣？我們應(yīng)該怎么取舍？有哪些最佳實踐？

在講解 Redis 高可用方案之前，我們先來看看 Redis Sentinel 原理(https://redis.io/topics/sentinel)是怎么樣的。

1. Sentinel 集群通過給定的配置文件發(fā)現(xiàn) master，啟動時會監(jiān)控 master。通過向 master 發(fā)送 info 信息獲得該服務(wù)器下面的所有從服務(wù)器。

2. Sentinel 集群通過命令連接向被監(jiān)視的主從服務(wù)器發(fā)送 hello 信息 (每秒一次)，該信息包括 Sentinel 本身的 IP、端口、id 等內(nèi)容，以此來向其他 Sentinel 宣告自己的存在。

3. Sentinel 集群通過訂閱連接接收其他 Sentinel 發(fā)送的 hello 信息，以此來發(fā)現(xiàn)監(jiān)視同一個主服務(wù)器的其他 Sentinel；集群之間會互相創(chuàng)建命令連接用于通信，因為已經(jīng)有主從服務(wù)器作為發(fā)送和接收 hello 信息的中介，Sentinel 之間不會創(chuàng)建訂閱連接。

4. Sentinel 集群使用 ping 命令來檢測實例的狀態(tài)，如果在指定的時間內(nèi)（down-after-milliseconds）沒有回復(fù)或則返回錯誤的回復(fù)，那么該實例被判為下線。

5. 當 failover 主備切換被觸發(fā)后，failover 并不會馬上進行，還需要 Sentinel 中的大多數(shù) Sentinel 授權(quán)后才可以進行 failover，即進行 failover 的 Sentinel 會去獲得指定 quorum 個的 Sentinel 的授權(quán)，成功后進入 ODOWN 狀態(tài)。如在 5 個 Sentinel 中配置了 2 個 quorum，等到 2 個 Sentinel 認為 master 死了就執(zhí)行 failover。

6. Sentinel 向選為 master 的 slave 發(fā)送 SLAVEOF NO ONE 命令，選擇 slave 的條件是 Sentinel 首先會根據(jù) slaves 的優(yōu)先級來進行排序，優(yōu)先級越小排名越靠前。如果優(yōu)先級相同，則查看復(fù)制的下標，哪個從 master 接收的復(fù)制數(shù)據(jù)多，哪個就靠前。如果優(yōu)先級和下標都相同，就選擇進程 ID 較小的。

7. Sentinel 被授權(quán)后，它將會獲得宕掉的 master 的一份最新配置版本號 (config-epoch)，當 failover 執(zhí)行結(jié)束以后，這個版本號將會被用于最新的配置，通過廣播形式通知其它 Sentinel，其它的 Sentinel 則更新對應(yīng) master 的配置。

1 到 3 是自動發(fā)現(xiàn)機制:

• 以 10 秒一次的頻率，向被監(jiān)視的 master 發(fā)送 info 命令，根據(jù)回復(fù)獲取 master 當前信息。

• 以 1 秒一次的頻率，向所有 redis 服務(wù)器、包含 Sentinel 在內(nèi)發(fā)送 PING 命令，通過回復(fù)判斷服務(wù)器是否在線。

• 以 2 秒一次的頻率，通過向所有被監(jiān)視的 master，slave 服務(wù)器發(fā)送當前 Sentinel master 信息的消息。

4 是檢測機制，5 和 6 是 failover 機制，7 是更新配置機制。[1]

講解完 Redis Sentinel 原理之后，接下來講解常用的 Redis?高可用架構(gòu)。

• Redis Sentinel 集群 + 內(nèi)網(wǎng) DNS + 自定義腳本

• Redis Sentinel 集群 + VIP + 自定義腳本

• 封裝客戶端直連 Redis Sentinel 端口

• JedisSentinelPool，適合 Java

• PHP 基于 phpredis 自行封裝

• Redis Sentinel 集群 + Keepalived/Haproxy

• Redis M/S + Keepalived

• Redis Cluster

• Twemproxy

• Codis

接下來配合圖文逐個講解。

1、Redis Sentinel 集群 + 內(nèi)網(wǎng) DNS + 自定義腳本

Redis Sentinel 集群 + 內(nèi)網(wǎng) DNS + 自定義腳本

上圖是已經(jīng)在線上環(huán)境應(yīng)用的方案。底層是 Redis Sentinel 集群，代理著 Redis 主從，Web 端連接內(nèi)網(wǎng) DNS 提供服務(wù)。內(nèi)網(wǎng) DNS 按照一定的規(guī)則分配，比如 xxxx.redis.cache/queue.port.xxx.xxx，第一個段表示業(yè)務(wù)簡寫，第二個段表示這是 Redis 內(nèi)網(wǎng)域名，第三個段表示 Redis 類型，cache 表示緩存，queue 表示隊列，第四個段表示 Redis 端口，第五、第六個段表示內(nèi)網(wǎng)主域名。

當主節(jié)點發(fā)生故障，比如機器故障、Redis 節(jié)點故障或者網(wǎng)絡(luò)不可達，Sentinel 集群會調(diào)用 client-reconfig-script 配置的腳本，修改對應(yīng)端口的內(nèi)網(wǎng)域名。對應(yīng)端口的內(nèi)網(wǎng)域名指向新的 Redis 主節(jié)點。

優(yōu)點：

秒級切換，在 10s 內(nèi)完成整個切換操作

腳本自定義，架構(gòu)可控

對應(yīng)用透明，前端不用擔心后端發(fā)生什么變化

缺點：

維護成本略高，Redis Sentinel 集群建議投入 3 臺機器以上

依賴 DNS，存在解析延時

Sentinel 模式存在短時間的服務(wù)不可用

服務(wù)通過外網(wǎng)訪問不可采用此方案

2、Redis Sentinel 集群 + VIP + 自定義腳本

Redis Sentinel 集群 + VIP + 自定義腳本

此方案和上一個方案相比，略有不同。第一個方案使用了內(nèi)網(wǎng) DNS，第二個方案把內(nèi)網(wǎng) DNS 換成了虛擬 IP。底層是 Redis Sentinel 集群，代理著 Redis 主從，Web 端通過 VIP 提供服務(wù)。在部署 Redis 主從的時候，需要將虛擬 IP 綁定到當前的 Redis 主節(jié)點。當主節(jié)點發(fā)生故障，比如機器故障、Redis 節(jié)點故障或者網(wǎng)絡(luò)不可達，Sentinel 集群會調(diào)用 client-reconfig-script 配置的腳本，將 VIP 漂移到新的主節(jié)點上。

優(yōu)點：

• 秒級切換，在 5s 內(nèi)完成整個切換操作

• 腳本自定義，架構(gòu)可控

• 對應(yīng)用透明，前端不用擔心后端發(fā)生什么變化

缺點：

• 維護成本略高，Redis Sentinel 集群建議投入 3 臺機器以上

• 使用 VIP 增加維護成本，存在 IP 混亂風(fēng)險

• Sentinel 模式存在短時間的服務(wù)不可用

• 3.3 封裝客戶端直連 Redis Sentinel 端口

3、封裝客戶端直連 Redis Sentinel 端口

部分業(yè)務(wù)只能通過外網(wǎng)訪問 Redis，上述兩種方案均不可用，于是衍生出了這種方案。Web 使用客戶端連接其中一臺 Redis Sentinel 集群中的一臺機器的某個端口，然后通過這個端口獲取到當前的主節(jié)點，然后再連接到真實的 Redis 主節(jié)點進行相應(yīng)的業(yè)務(wù)員操作。需要注意的是，Redis Sentinel 端口和 Redis 主節(jié)點均需要開放訪問權(quán)限。如果前端業(yè)務(wù)使用 Java，有 JedisSentinelPool 可以復(fù)用；如果前端業(yè)務(wù)使用 PHP，可以在 phpredis 的基礎(chǔ)上做二次封裝。

優(yōu)點：

• 服務(wù)探測故障及時

• DBA 維護成本低

缺點：

• 依賴客戶端支持 Sentinel

• Sentinel 服務(wù)器和 Redis 節(jié)點需要開放訪問權(quán)限

• 對應(yīng)用有侵入性

4、Redis Sentinel 集群 + Keepalived/Haproxy

Redis Sentinel 集群 + Keepalived/Haproxy

底層是 Redis Sentinel 集群，代理著 Redis 主從，Web 端通過 VIP 提供服務(wù)。當主節(jié)點發(fā)生故障，比如機器故障、Redis 節(jié)點故障或者網(wǎng)絡(luò)不可達，Redis 之間的切換通過 Redis Sentinel 內(nèi)部機制保障，VIP 切換通過 Keepalived 保障。

優(yōu)點：

• 秒級切換

• 對應(yīng)用透明

缺點：

• 維護成本高

• 存在腦裂

• Sentinel 模式存在短時間的服務(wù)不可用

5、Redis M/S + Keepalived

Redis M/S + Keepalived

此方案沒有使用到 Redis Sentinel。此方案使用了原生的主從和 Keepalived，VIP 切換通過 Keepalived 保障，Redis 主從之間的切換需要自定義腳本實現(xiàn)。

優(yōu)點：

• 秒級切換

• 對應(yīng)用透明

• 部署簡單，維護成本低

缺點：

• 需要腳本實現(xiàn)切換功能

• 存在腦裂

6、Redis Cluster

Redis Cluster

From: http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster

Redis 3.0.0 在 2015 年 4 月 2 日正式發(fā)布，距今已有兩年多的時間。Redis 集群采用 P2P 模式，無中心化。把 key 分成 16384 個 slot，每個實例負責(zé)一部分 slot。客戶端請求對應(yīng)的數(shù)據(jù)，若該實例 slot 沒有對應(yīng)的數(shù)據(jù)，該實例會轉(zhuǎn)發(fā)給對應(yīng)的實例。另外，Redis 集群通過 Gossip 協(xié)議同步節(jié)點信息。

優(yōu)點：

• 組件 all-in-box，部署簡單，節(jié)約機器資源

• 性能比 proxy 模式好

• 自動故障轉(zhuǎn)移、Slot 遷移中數(shù)據(jù)可用

• 官方原生集群方案，更新與支持有保障

缺點：

• 架構(gòu)比較新，最佳實踐較少

• 多鍵操作支持有限（驅(qū)動可以曲線救國）

• 為了性能提升，客戶端需要緩存路由表信息

• 節(jié)點發(fā)現(xiàn)、reshard 操作不夠自動化

7、Twemproxy

Twemproxy

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

多個同構(gòu) Twemproxy（配置相同）同時工作，接受客戶端的請求，根據(jù) hash 算法，轉(zhuǎn)發(fā)給對應(yīng)的 Redis。

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

優(yōu)點：

• 開發(fā)簡單，對應(yīng)用幾乎透明

• 歷史悠久，方案成熟

缺點：

• 代理影響性能

• LVS 和 Twemproxy 會有節(jié)點性能瓶頸

• Redis 擴容非常麻煩

• Twitter 內(nèi)部已放棄使用該方案，新使用的架構(gòu)未開源

8、Codis

Codis

From: https://github.com/CodisLabs/codis

Codis 是由豌豆莢開源的產(chǎn)品，涉及組件眾多，其中 ZooKeeper 存放路由表和代理節(jié)點元數(shù)據(jù)、分發(fā) Codis-Config 的命令；Codis-Config 是集成管理工具，有 Web 界面供使用；Codis-Proxy 是一個兼容 Redis 協(xié)議的無狀態(tài)代理；Codis-Redis 基于 Redis 2.8 版本二次開發(fā)，加入 slot 支持，方便遷移數(shù)據(jù)。

優(yōu)點：

• 開發(fā)簡單，對應(yīng)用幾乎透明

• 性能比 Twemproxy 好

• 有圖形化界面，擴容容易，運維方便

缺點：

• 代理依舊影響性能

• 組件過多，需要很多機器資源

• 修改了 Redis 代碼，導(dǎo)致和官方無法同步，新特性跟進緩慢

• 開發(fā)團隊準備主推基于 Redis 改造的 reborndb

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

主推以下方案：

• Redis Sentinel 集群 + 內(nèi)網(wǎng) DNS + 自定義腳本

• Redis Sentinel 集群 + VIP + 自定義腳本

以下是實戰(zhàn)過程中總結(jié)出的最佳實踐：

• Redis Sentinel 集群建議使用 >= 5 臺機器

• 不同的大業(yè)務(wù)可以使用一套 Redis Sentinel 集群，代理該業(yè)務(wù)下的所有端口

• 根據(jù)不同的業(yè)務(wù)劃分好 Redis 端口范圍

• 自定義腳本建議采用 Python 實現(xiàn)，擴展便利

• 自定義腳本需要注意判斷當前的 Sentinel 角色

• 自定義腳本傳入?yún)?shù)：

• 自定義腳本需要遠程 ssh 操作機器，建議使用 paramiko 庫，避免重復(fù)建立 SSH 連接，消耗時間

• 加速 SSH 連接，建議關(guān)閉以下兩個參數(shù)

• UseDNS no

• GSSAPIAuthentication no

• 微信或者郵件告警，建議 fork 一個進程，避免主進程阻塞

• 自動切換和故障切換，所有操作建議在 15s 以內(nèi)完成

你們公司用的哪種方案，歡迎留言區(qū)評論~

- END -

?推薦閱讀?

Kubernetes 是運維/開發(fā)工程師必須掌握的技能?
Jenkins vs GitLab CI：CI/CD工具之戰(zhàn)
搞懂 Nginx，這篇就夠了！
Linux系統(tǒng)常用命令速查手冊
Linux服務(wù)器高并發(fā)調(diào)優(yōu)實戰(zhàn)
互聯(lián)網(wǎng)公司招聘運維工程師【內(nèi)推】


點亮，服務(wù)器三年不宕機