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 成為當(dāng)今速度最快的 NoSQL 數(shù)據(jù)庫.

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

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

0x02 Sentinel 原理

在講解 Redis 高可用計劃之前,我們先來看看 Redis 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. 當(dāng) failover 主備切換被觸發(fā)后,failover 并不會馬上進(jìn)行,還需要 Sentinel 中的大多數(shù) Sentinel 授權(quán)后才可以進(jìn)行 failover,即進(jìn)行 failover 的 Sentinel 會去獲得指定 quorum 個的 Sentinel 的授權(quán),成功后進(jìn)入 ODOWN 狀態(tài).如在 5 個 Sentinel 中配置了 2 個 quorum,比及 2 個 Sentinel 認(rèn)為 master 死了就執(zhí)行 failover.

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

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

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

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

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

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

4 是檢測機(jī)制,5 和 6 是 failover 機(jī)制,7 是更新設(shè)置裝備擺設(shè)機(jī)制.[1]

0x03 Redis 高可用架構(gòu)

講授完 Redis Sentinel 原理之后,接下來講授常用的 Redis 高可用架構(gòu).

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

• Redis Sentinel 集群 + VIP + 自界說腳本

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

• JedisSentinelPool,得當(dāng) Java

• PHP 基于 phpredis 自行封裝

• Redis Sentinel 集群 + Keepalived/Haproxy

• Redis M/S + Keepalived

• Redis Cluster

• Twemproxy

• Codis

接下來共同圖文逐個講解.

3.1 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)主域名.

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

長處：

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

• 腳本自界說,架構(gòu)可控

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

毛?。?/p>

• 維護(hù)本錢略高,Redis Sentinel 集群建議投入 3 臺機(jī)器以上

• 依附 DNS,存在解析延時

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

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

3.2 Redis Sentinel 集群 + VIP + 自界說腳本

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

長處：

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

• 腳本自界說,架構(gòu)可控

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

毛病：

• 維護(hù)本錢略高,Redis Sentinel 集群建議投入 3 臺機(jī)器以上

• 使用 VIP 增加維護(hù)本錢,存在 IP 混亂風(fēng)險

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

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

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

長處：

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

• DBA 維護(hù)本錢低

毛?。?/p>

• 依附客戶端支持 Sentinel

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

• 對利用有侵入性

3.4 Redis Sentinel 集群 + Keepalived/Haproxy

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

長處：

• 秒級切換

• 對利用透明

毛病：

• 維護(hù)本錢高

• 存在腦裂

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

3.5 Redis M/S + Keepalived

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

長處：

• 秒級切換

• 對利用透明

• 部署簡單,維護(hù)本錢低

毛?。?/p>

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

• 存在腦裂

3.6 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,每個實例負(fù)責(zé)一部分 slot.客戶端哀求對應(yīng)的數(shù)據(jù),若該實例 slot 沒有對應(yīng)的數(shù)據(jù),該實例會轉(zhuǎn)發(fā)給對應(yīng)的實例.另外,Redis 集群通過 Gossip 協(xié)議同步節(jié)點信息.

長處：

• 組件 all-in-box,部署簡單,節(jié)約機(jī)械資源

• 機(jī)能比 proxy 模式好

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

• 官方原生集群計劃,更新與支持有保障

毛病：

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

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

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

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

3.7 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 方案比較成熟了,之前我們團(tuán)隊長期使用此方案,但是效果并不是很抱負(fù).一方面是定位問題比較困難,另一方面是它對自動剔除節(jié)點的支持不是很友好.

長處：

• 開發(fā)簡單,對利用幾乎透明

• 歷史悠久,計劃成熟

毛?。?/p>

• 代理經(jīng)銷影響性能

• LVS 和 Twemproxy 會有節(jié)點機(jī)能瓶頸

• Redis 擴(kuò)容異常麻煩

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

3.8 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ù).

長處：

• 開發(fā)簡單,對利用幾乎透明

• 機(jī)能比 Twemproxy 好

• 有圖形化界面,擴(kuò)容容易,運維便利

毛病：

• 代理經(jīng)銷依舊影響性能

• 組件過多,必要很多機(jī)器資源

• 修改了 Redis 代碼,導(dǎo)致和官方無法同步,新特性跟進(jìn)遲緩

• 開發(fā)團(tuán)隊準(zhǔn)備主推基于 Redis 改革的 reborndb

0x04 最佳實踐

所謂的最佳實踐,都是最得當(dāng)具體場景的實踐.

主推以下計劃：

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

• Redis Sentinel 集群 + VIP + 自界說腳本

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

• Redis Sentinel 集群建議使用 >= 5 臺機(jī)械

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

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

• 自定義腳本建議采用 Python 實現(xiàn),擴(kuò)展方便

• 自定義腳本必要注意判斷當(dāng)前的 Sentinel 角色

• 自界說腳本傳入?yún)?shù)：<service_name> <role> <comment> <from_ip> <from_port> <to_ip> <to_port>

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

• 加速 SSH 連接,建議封閉以下兩個參數(shù)

• UseDNS no

• GSSAPIAuthentication no

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

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