[[206583]]

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

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

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

新的應用程序

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

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

幸運的是，這個時候，Redis 3.2 出來了，而且內置了原生集群，消除了對單一 sentinel 集群需要。

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

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

向前進

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

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

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

現在?

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

未來怎么樣?

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