如何讓網站不下線而從 Redis 2 遷移到 Redis 3

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

在開始階段（或至少在升級之前）

我們的傳統緩存中每個緩存都包括一對 Redis 伺服器，使用 keepalive 確保始終有一個主節點監聽浮動 IPfloating 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 次甚至更高的擴展有關。

via: http://engineering.skybettingandgaming.com/2017/09/25/redis-2-to-redis-3/

作者：Craig Stewart 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出