[[206583]]

我們在 Sky Betting&Gaming 中使用 Redis 作為共享內(nèi)存緩存，用于那些需要跨 API 服務(wù)器或者 Web 服務(wù)器鑒別令牌之類的操作。在 Core Tribe 內(nèi)，它用來幫助處理日益龐大的登錄數(shù)量，特別是在繁忙的時(shí)候，我們在一分鐘內(nèi)登錄數(shù)量會超過 20,000 人。這在很大程度上適用于數(shù)據(jù)存放在大量服務(wù)器的情況下(在 SSO 令牌用于 70 臺 Apache HTTPD 服務(wù)器的情況下)。我們最近著手升級 Redis 服務(wù)器，此升級旨在使用 Redis 3.2 提供的原生集群功能。這篇博客希望解釋為什么我們要使用集群、我們遇到的問題以及我們的解決方案。

在開始階段(或至少在升級之前)

我們的傳統(tǒng)緩存中每個緩存都包括一對 Redis 服務(wù)器，使用 keepalive 確保始終有一個主節(jié)點(diǎn)監(jiān)聽浮動 IP floating IP地址。當(dāng)出現(xiàn)問題時(shí)，這些服務(wù)器對需要很大的精力來進(jìn)行管理，而故障模式有時(shí)是非常各種各樣的。有時(shí)，只允許讀取它所持有的數(shù)據(jù)，而不允許寫入的從屬節(jié)點(diǎn)卻會得到浮動 IP 地址，這種問題是相對容易診斷的，但會讓無論哪個程序試圖使用該緩存時(shí)都很麻煩。

新的應(yīng)用程序

因此，這種情況下，我們需要構(gòu)建一個新的應(yīng)用程序，一個使用共享內(nèi)存緩存shared in-memory cache的應(yīng)用程序，但是我們不希望對該緩存進(jìn)行迂回的故障切換過程。因此，我們的要求是共享的內(nèi)存緩存，沒有單點(diǎn)故障，可以使用盡可能少的人為干預(yù)來應(yīng)對多種不同的故障模式，并且在事件恢復(fù)之后也能夠在很少的人為干預(yù)下恢復(fù)，一個額外的要求是提高緩存的安全性，以減少數(shù)據(jù)泄露的范圍(稍后再說)。當(dāng)時(shí) Redis Sentinel 看起來很有希望，并且有許多程序支持代理 Redis 連接，比如 twemproxy。這會導(dǎo)致還要安裝其它很多組件，它應(yīng)該有效，并且人際交互最少，但它復(fù)雜而需要運(yùn)行大量的服務(wù)器和服務(wù)，并且相互通信。

將會有大量的應(yīng)用服務(wù)器與 twemproxy 進(jìn)行通信，這會將它們的調(diào)用路由到合適的 Redis 主節(jié)點(diǎn)，twemproxy 將從 sentinal 集群獲取主節(jié)點(diǎn)的信息，它將控制哪臺 Redis 實(shí)例是主，哪臺是從。這個設(shè)置是復(fù)雜的，而且仍有單點(diǎn)故障，它依賴于 twemproxy 來處理分片，來連接到正確的 Redis 實(shí)例。它具有對應(yīng)用程序透明的優(yōu)點(diǎn)，所以我們可以在理論上做到將現(xiàn)有的應(yīng)用程序轉(zhuǎn)移到這個 Redis 配置，而不用改變應(yīng)用程序。但是我們要從頭開始構(gòu)建一個應(yīng)用程序，所以遷移應(yīng)用程序不是一個必需條件。

幸運(yùn)的是，這個時(shí)候，Redis 3.2 出來了，而且內(nèi)置了原生集群，消除了對單一 sentinel 集群需要。

它有一個更簡單的設(shè)置，但 twemproxy 不支持 Redis 集群分片，它能為你分片數(shù)據(jù)，但是如果嘗試在與分片不一致的集群中這樣做會導(dǎo)致問題。有參考的指南可以使其匹配，但是集群可以自動改變形式，并改變分片的設(shè)置方式。它仍然有單點(diǎn)故障。正是在這一點(diǎn)上，我將永遠(yuǎn)感謝我的一位同事發(fā)現(xiàn)了一個 Node.js 的 Redis 的集群發(fā)現(xiàn)驅(qū)動程序，讓我們完全放棄了 twemproxy。

因此，我們能夠自動分片數(shù)據(jù)，故障轉(zhuǎn)移和故障恢復(fù)基本上是自動的。應(yīng)用程序知道哪些節(jié)點(diǎn)存在，并且在寫入數(shù)據(jù)時(shí)，如果寫入錯誤的節(jié)點(diǎn)，集群將自動重定向該寫入。這是被選的配置，這讓我們共享的內(nèi)存緩存相當(dāng)健壯，可以沒有干預(yù)地應(yīng)付基本的故障模式。在測試期間，我們的確發(fā)現(xiàn)了一些缺陷。復(fù)制是在一個接一個節(jié)點(diǎn)的基礎(chǔ)上進(jìn)行的，因此如果我們丟失了一個主節(jié)點(diǎn)，那么它的從節(jié)點(diǎn)會成為一個單點(diǎn)故障，直到死去的節(jié)點(diǎn)恢復(fù)服務(wù)，也只有主節(jié)點(diǎn)對集群健康投票，所以如果我們一下失去太多主節(jié)點(diǎn)，那么集群無法自我恢復(fù)。但這比我們過去的好。

向前進(jìn)

隨著使用集群 Redis 配置的新程序，我們對于老式 Redis 實(shí)例的狀態(tài)變得越來越不適應(yīng)，但是新程序與現(xiàn)有程序的規(guī)模并不相同(超過 30GB 的內(nèi)存專用于我們最大的老式 Redis 實(shí)例數(shù)據(jù)庫)。因此，隨著 Redis 集群在底層得到了證實(shí)，我們決定遷移老式的 Redis 實(shí)例到新的 Redis 集群中。

由于我們有一個原生支持 Redis 集群的 Node.js Redis 驅(qū)動程序，因此我們開始將 Node.js 程序遷移到 Redis 集群。但是，如何將數(shù)十億字節(jié)的數(shù)據(jù)從一個地方移動到另一個地方，而不會造成重大問題?特別是考慮到這些數(shù)據(jù)是認(rèn)證令牌，所以如果它們錯了，我們的終端用戶將會被登出。一個選擇是要求網(wǎng)站完全下線，將所有內(nèi)容都指向新的 Redis 群集，并將數(shù)據(jù)遷移到其中，以希望獲得最佳效果。另一個選擇是切換到新集群，并強(qiáng)制所有用戶再次登錄。由于顯而易見的原因，這些都不是非常合適的。我們決定采取的替代方法是將數(shù)據(jù)同時(shí)寫入老式 Redis 實(shí)例和正在替換它的集群，同時(shí)隨著時(shí)間的推移，我們將逐漸更多地向該集群讀取。由于數(shù)據(jù)的有效期有限(令牌在幾個小時(shí)后到期)，這種方法可以導(dǎo)致零停機(jī)，并且不會有數(shù)據(jù)丟失的風(fēng)險(xiǎn)。所以我們這么做了。遷移是成功的。

剩下的就是服務(wù)于我們的 PHP 代碼(其中還有一個項(xiàng)目是有用的，其它的最終是沒必要的)的 Redis 的實(shí)例了，我們在這過程中遇到了一個困難，實(shí)際上是兩個。首先，也是最緊迫的是找到在 PHP 中使用的 Redis 集群發(fā)現(xiàn)驅(qū)動程序，還要是我們正在使用的 PHP 版本。這被證明是可行的，因?yàn)槲覀兩壍搅俗钚掳姹镜?PHP。我們選擇的驅(qū)動程序不喜歡使用 Redis 的授權(quán)方式，因此我們決定使用 Redis 集群作為一個額外的安全步驟 (我告訴你，這將有更多的安全性)。當(dāng)我們用 Redis 集群替換每個老式 Redis 實(shí)例時(shí)，修復(fù)似乎很直接，將 Redis 授權(quán)關(guān)閉，這樣它將會響應(yīng)所有的請求。然而，這并不是真的，由于某些原因，Redis 集群不會接受來自 Web 服務(wù)器的連接。 Redis 在版本 3 中引入的稱為“保護(hù)模式”的新安全功能將在 Redis 綁定到任何接口時(shí)將停止監(jiān)聽來自外部 IP 地址的連接，并無需配置 Redis 授權(quán)密碼。這被證明相當(dāng)容易修復(fù)，但讓我們保持警惕。

現(xiàn)在?

這就是我們現(xiàn)在的情況。我們已經(jīng)遷移了我們的一些老式 Redis 實(shí)例，并且正在遷移其余的。我們通過這樣做解決了我們的一些技術(shù)債務(wù)，并提高了我們的平臺的穩(wěn)定性。使用 Redis 集群，我們還可以擴(kuò)展內(nèi)存數(shù)據(jù)庫并擴(kuò)展它們。 Redis 是單線程的，所以只要在單個實(shí)例中留出更多的內(nèi)存就會可以得到這么多的增長，而且我們已經(jīng)緊跟在這個限制后面。我們期待著從新的集群中獲得改進(jìn)的性能，同時(shí)也為我們提供了擴(kuò)展和負(fù)載均衡的更多選擇。

未來怎么樣?

我們解決了一些技術(shù)性債務(wù)，這使我們的服務(wù)更容易支持，更加穩(wěn)定。但這并不意味著這項(xiàng)工作完成了，Redis 4 似乎有一些我們可能想要研究的功能。而且 Redis 并不是我們使用的唯一軟件。我們將繼續(xù)努力改進(jìn)平臺，縮短處理技術(shù)債務(wù)的時(shí)間，但隨著客戶群體的擴(kuò)大，我們力求提供更豐富的服務(wù)，我們總是會遇到需要改進(jìn)的事情。下一個挑戰(zhàn)可能與每分鐘超過 20,000次 登錄到超過 40,000 次甚至更高的擴(kuò)展有關(guān)。