一文搞懂 Redis 架構演化之路

你好，我是 Kaito。

這篇文章我想和你聊一聊 Redis 的架構演化之路。

現如今 Redis 變得越來越流行，幾乎在很多項目中都要被用到，不知道你在使用 Redis 時，有沒有思考過，Redis 到底是如何穩定、高性能地提供服務的？

如果你對 Redis 已經有些瞭解，肯定也聽說過「數據持久化、主從複製、哨兵、分片集羣」這些概念，它們之間又有什麼區別和聯繫呢？

如果你存在這樣的疑惑，這篇文章，我會從 0 到 1，再從 1 到 N，帶你一步步構建出一個穩定、高性能的 Redis 集羣。

在這個過程中，你可以瞭解到 Redis 爲了做到穩定、高性能，都採取了哪些優化方案，以及爲什麼要這麼做？

掌握了這些原理，這樣平時你在使用 Redis 時，就能夠做到「遊刃有餘」。

從最簡單的開始：單機版 Redis

首先，我們從最簡單的場景開始。

假設現在你有一個業務應用，需要引入 Redis 來提高應用的性能，此時你可以選擇部署一個單機版的 Redis 來使用，就像這樣：

這個架構非常簡單，你的業務應用可以把 Redis 當做緩存來使用，從 MySQL 中查詢數據，然後寫入到 Redis 中，之後業務應用再從 Redis 中讀取這些數據，由於 Redis 的數據都存儲在內存中，所以這個速度飛快。

如果你的業務體量並不大，那這樣的架構模型基本可以滿足你的需求。是不是很簡單？

隨着時間的推移，你的業務體量逐漸發展起來了，Redis 中存儲的數據也越來越多，此時你的業務應用對 Redis 的依賴也越來越重。

突然有一天，你的 Redis 因爲某些原因宕機了，這時你的所有業務流量，都會打到後端 MySQL 上，MySQL 壓力劇增，嚴重的話甚至會壓垮 MySQL。

這時你應該怎麼辦？

我猜你的方案肯定是，趕緊重啓 Redis，讓它可以繼續提供服務。

但是，因爲之前 Redis 中的數據都在內存中，儘管你現在把 Redis 重啓了，之前的數據也都丟失了（假設沒開持久化）。重啓後的 Redis 雖然可以正常工作，但是由於 Redis 中沒有任何數據，業務流量還是都會打到後端 MySQL 上，MySQL 的壓力還是很大。

有沒有什麼好的辦法解決這個問題？

既然 Redis 只把數據存儲在內存中，那是否可以把這些數據也寫一份到磁盤上呢？

如果採用這種方式，當 Redis 重啓時，我們把磁盤中的數據快速「恢復」到內存中，這樣它就可以繼續正常提供服務了。

是的，這是一個很好的解決方案，這個把內存數據寫到磁盤上的過程，就是「數據持久化」。

數據持久化：有備無患

現在，你設想的 Redis 數據持久化是這樣的：

但是，數據持久化具體應該怎麼做呢？

我猜你最容易想到的一個方案是，Redis 每一次執行寫操作，除了寫內存之外，同時也寫一份到磁盤上，就像這樣：

沒錯，這是最簡單直接的方案。

但仔細想一下，這個方案有個問題：客戶端的每次寫操作，既需要寫內存，又需要寫磁盤，而寫磁盤的耗時相比於寫內存來說，肯定要慢很多！這勢必會影響到 Redis 的性能。

如何規避這個問題？

這時我們需要分析寫磁盤的細節問題了。

我們都知道，要把內存數據寫到磁盤，其實是分 2 步的：

  1. 程序寫文件的 PageCache（write）

  2. 把 PageCache 刷到磁盤（fsync）

具體就是下圖這樣：

數據持久化最粗暴的思路就是上面提到的那樣，寫完 Redis 內存後，同步寫 PageCache + fsync 磁盤，當然，這樣肯定因爲磁盤拖慢整個寫入速度。

如何優化？也很簡單，我們可以這樣做：Redis 寫內存由主線程來做，寫內存完成後就給客戶端返回結果，然後 Redis 用「另一個線程」去寫磁盤，這樣就可以避免主線程寫磁盤對性能的影響。

這種持久化方案，其實就是我們經常聽到的 Redis AOF（Append Only File）。

Redis AOF 持久化提供了 3 種刷盤機制：

  1. appendfsync always：主線程同步 fsync

  2. appendfsync no：由 OS fsync

  3. appendfsync everysec：後臺線程每間隔 1 秒 fsync

解決了數據實時持久化，我們還會面臨另一個問題，數據實時寫入 AOF，隨着時間的推移，AOF 文件會越來越大，那使用 AOF 恢復時變得非常慢，這該怎麼辦？

Redis 很貼心地提供了 AOF rewrite 方案，俗稱 AOF 「瘦身」，顧名思義，就是壓縮 AOF 的體積。

因爲 AOF 裏記錄的都是每一次寫命令，例如執行 set k1 v1，set k1 v2，其實我們只關心數據的最終版本 v2 就可以了。AOF rewrite 正是利用了這個特點，在 AOF 體積越來越大時（超過設定閾值），Redis 就會定期重寫一份新的 AOF，這個新的 AOF 只記錄數據的最終版本就可以了。

這樣就可以壓縮 AOF 體積。

除此之外，我們可以換個角度，思考一下還有什麼方式可以持久化數據？

這時你就要結合 Redis 的使用場景來考慮了。

回憶一下，我們在使用 Redis 時，通常把它用作什麼場景？

是的，緩存。

把 Redis 當做緩存來用，意味着儘管 Redis 中沒有保存全量數據，對於不在緩存中的數據，我們的業務應用依舊可以通過查詢後端數據庫得到結果，只不過查詢後端數據的速度會慢一點而已，但對業務結果其實是沒有影響的。

基於這個特點，我們的 Redis 數據持久化還可以用「數據快照」的方式來做。

那什麼是數據快照呢？

簡單來講，你可以這麼理解：

  1. 你把 Redis 想象成一個水杯，向 Redis 寫入數據，就相當於往這個杯子裏倒水

  2. 此時你拿一個相機給這個水杯拍一張照片，拍照的這一瞬間，照片中記錄到這個水杯中水的容量，就是水杯的數據快照

也就是說，Redis 的數據快照，是記錄某一時刻下 Redis 中的數據，然後只需要把這個數據快照寫到磁盤上就可以了。

它的優勢在於，只在需要持久化時，把數據「一次性」寫入磁盤，其它時間都不需要操作磁盤。

基於這個方案，我們可以「定時」給 Redis 做數據快照，把數據持久化到磁盤上。

這種方案就是我們經常聽到的 Redis RDB，RDB 採用「定時快照」的方式進行數據持久化，它的優點是：

  1. 持久化文件體積小（二進制 + 壓縮）

  2. 寫盤頻率低（定時寫入）

缺點也很明顯，因爲是定時持久化，數據肯定沒有 AOF 實時持久化完整，如果你的 Redis 只當做緩存，對於丟失數據不敏感（可從後端的數據庫查詢），那這種持久化方式是非常合適的。

如果讓你來選擇持久化方案，你可以這樣選擇：

  1. 業務對於數據丟失不敏感，選 RDB

  2. 業務對數據完整性要求比較高，選 AOF

理解了 RDB 和 AOF，我們再進一步思考一下，有沒有什麼辦法，既可以保證數據完整性，還能讓持久化文件體積更小，恢復更快呢？

回顧一下我們前面講到的，RDB 和 AOF 各自的特點：

  1. RDB 以二進制 + 數據壓縮方式存儲，文件體積小

  2. AOF 記錄每一次寫命令，數據最全

我們可否利用它們各自的優勢呢？

當然可以，這就是 Redis 的「混合持久化」。

要想數據完整性更高，肯定就不能只用 RDB 了，重點還是要放在 AOF 優化上。

具體來說，當 AOF 在做 rewrite 時，Redis 先以 RDB 格式在 AOF 文件中寫入一個數據快照，再把在這期間產生的每一個寫命令，追加到 AOF 文件中。

因爲 RDB 是二進制壓縮寫入的，這樣 AOF 文件體積就變得更小了。

因爲 AOF 體積進一步壓縮，你在使用 AOF 恢復數據時，這個恢復時間就會更短了！

Redis 4.0 以上版本才支持混合持久化。

注意：混合持久化是對 AOF rewrite 的優化，這意味着使用它必須基於 AOF + AOF rewrite。

這麼一番優化，你的 Redis 再也不用擔心實例宕機了，當發生宕機時，你就可以用持久化文件快速恢復 Redis 中的數據。

但這樣就沒問題了嗎？

仔細想一下，雖然我們已經把持久化的文件優化到最小了，但在恢復數據時依舊是需要時間的，在這期間你的業務應用無法提供服務，這怎麼辦？

一個實例宕機，只能用恢復數據來解決，那我們是否可以部署多個 Redis 實例，然後讓這些實例數據保持實時同步，這樣當一個實例宕機時，我們在剩下的實例中選擇一個繼續提供服務就好了。

沒錯，這個方案就是接下來要講的「主從複製：多副本」。

主從複製：多副本

你可以部署多個 Redis 實例，架構模型就變成了這樣：

我們這裏把實時讀寫的節點叫做 master，另一個實時同步數據的節點叫做 slave。

採用多副本的方案，它的優勢是：

  1. 縮短不可用時間：master 發生宕機，我們可以手動把 slave 提升爲 master 繼續提供服務

  2. 提升讀性能：讓 slave 分擔一部分讀請求，提升應用的整體性能

這個方案不錯，不僅節省了數據恢復的時間，還能提升性能。

但它的問題在於：當 master 宕機時，我們需要「手動」把 slave 提升爲 master，這個過程也是需要花費時間的。

雖然比恢復數據要快得多，但還是需要人工介入處理。一旦需要人工介入，就必須要算上人的反應時間、操作時間，所以，在這期間你的業務應用依舊會受到影響。

我們是否可以把這個切換的過程，變成自動化？

哨兵：故障自動切換

要想自動切換，肯定不能依賴人了。

現在，我們可以引入一個「觀察者」，讓這個觀察者去實時監測 master 的健康狀態，這個觀察者就是「哨兵」。

具體如何做？

  1. 哨兵每間隔一段時間，詢問 master 是否正常

  2. master 正常回復，表示狀態正常，回覆超時表示異常

  3. 哨兵發現異常，發起主從切換

有了這個方案，就不需要人去介入處理了，一切就變得自動化了，是不是很爽？

但這裏還有一個問題，如果 master 狀態正常，但這個哨兵在詢問 master 時，它們之間的網絡發生了問題，那這個哨兵可能會「誤判」。

這個問題怎麼解決？

既然一個哨兵會誤判，那我們可以部署多個哨兵，讓它們分佈在不同的機器上，讓它們一起監測 master 的狀態，流程就變成了這樣：

  1. 多個哨兵每間隔一段時間，詢問 master 是否正常

  2. master 正常回復，表示狀態正常，回覆超時表示異常

  3. 一旦有一個哨兵判定 master 異常（不管是否是網絡問題），就詢問其它哨兵，如果多個哨兵（設置一個閾值）都認爲 master 異常了，這才判定 master 確實發生了故障

  4. 多個哨兵經過協商後，判定 master 故障，則發起主從切換

所以，我們用多個哨兵互相協商來判定 master 的狀態，這樣，就可以大大降低誤判的概率。

哨兵協商判定 master 異常後，這裏還有一個問題：由哪個哨兵來發起主從切換呢？

答案是，選出一個哨兵「領導者」，由這個領導者進行主從切換。

問題又來了，這個領導者怎麼選？

想象一下，在現實生活中，選舉是怎麼做的？

是的，投票。

在選舉哨兵領導者時，我們可以制定這樣一個選舉規則：

  1. 每個哨兵都詢問其它哨兵，請求對方爲自己投票

  2. 每個哨兵只投票給第一個請求投票的哨兵，且只能投票一次

  3. 首先拿到超過半數投票的哨兵，當選爲領導者，發起主從切換

這個選舉的過程就是我們經常聽到的：分佈式系統領域中的「共識算法」。

什麼是共識算法？

我們在多個機器部署哨兵，它們需要共同協作完成一項任務，所以它們就組成了一個「分佈式系統」。

在分佈式系統領域，多個節點如何就一個問題達成共識的算法，就叫共識算法。

在這個場景下，多個哨兵共同協商，選舉出一個都認可的領導者，就是使用共識算法完成的。

這個算法還規定節點的數量必須是奇數個，這樣可以保證系統中即使有節點發生了故障，剩餘超過「半數」的節點狀態正常，依舊可以提供正確的結果，也就是說，這個算法還兼容了存在故障節點的情況。

共識算法在分佈式系統領域有很多，例如 Paxos、Raft，哨兵選舉領導者這個場景，使用的是 Raft 共識算法，因爲它足夠簡單，且易於實現。

好，到這裏我們先小結一下。

你的 Redis 從最簡單的單機版，經過數據持久化、主從多副本、哨兵集羣，這一路優化下來，你的 Redis 不管是性能還是穩定性，都越來越高，就算節點發生故障，也不用擔心了。

Redis 以這樣的架構模式部署，基本上就可以穩定運行很長時間了。

...

隨着時間的發展，你的業務體量開始迎來了爆炸性增長，此時你的架構模型，還能夠承擔這麼大的流量嗎？

我們一起來分析一下：

  1. 數據怕丟失：持久化（RDB/AOF）

  2. 恢復時間久：主從副本（副本隨時可切）

  3. 手動切換時間長：哨兵集羣（自動切換）

  4. 讀存在壓力：擴容副本（讀寫分離）

  5. 寫存在壓力：一個 mater 扛不住怎麼辦？

可見，現在剩下的問題是，當寫請求量越來越大時，一個 master 實例可能就無法承擔這麼大的寫流量了。

要想完美解決這個問題，此時你就需要考慮使用「分片集羣」了。

分片集羣：橫向擴展

什麼是「分片集羣」？

簡單來講，一個實例扛不住寫壓力，那我們是否可以部署多個實例，然後把這些實例按照一定規則組織起來，把它們當成一個整體，對外提供服務，這樣不就可以解決集中寫一個實例的瓶頸問題嗎？

所以，現在的架構模型就變成了這樣：

現在問題又來了，這麼多實例如何組織呢？

我們制定規則如下：

  1. 每個節點各自存儲一部分數據，所有節點數據之和纔是全量數據

  2. 制定一個路由規則，對於不同的 key，把它路由到固定一個實例上進行讀寫

數據分多個實例存儲，那尋找 key 的路由規則需要放在客戶端來做，具體就是下面這樣：

這種方案也叫做「客戶端分片」，這個方案的缺點是，客戶端需要維護這個路由規則，也就是說，你需要把路由規則寫到你的業務代碼中。

如何做到不把路由規則耦合在客戶端業務代碼中呢？

繼續優化，我們可以在客戶端和服務端之間增加一個「中間代理層」，這個代理就是我們經常聽到的 Proxy，路由轉發規則，放在這個 Proxy 層來維護。

這樣，客戶端就無需關心服務端有多少個 Redis 節點了，只需要和這個 Proxy 交互即可。

Proxy 會把你的請求根據路由規則，轉發到對應的 Redis 節點上，而且，當集羣實例不足以支撐更大的流量請求時，還可以橫向擴容，添加新的 Redis 實例提升性能，這一切對於你的客戶端來說，都是透明無感知的。

業界開源的 Redis 分片集羣方案，例如 Twemproxy、Codis 就是採用的這種方案。

這種方案的優點在於，客戶端無需關心數據轉發規則，只需要和 Proxy 打交道，客戶端像操作單機 Redis 那樣去操作後面的集羣，簡單易用。

架構演進到目前爲止，路由規則無論是客戶端來做，還是 Proxy 來做，都是「社區」演進出來的分片解決方案，它們的特點是集羣中的 Redis 節點，都不知道對方的存在，只有客戶端或 Proxy 纔會統籌數據寫到哪裏，從哪裏讀取，而且它們都依賴哨兵集羣負責故障自動切換。

也就是說我們其實就是把多個孤立的 Redis 節點，自己組合起來使用。

Redis 在 3.0 其實就推出了「官方」的 Redis Cluster 分片方案，但由於推出初期不穩定，所以用的人很少，也因此業界湧現出了各種開源方案，上面講到的 Twemproxy、Codis 分片方案就是在這種背景下誕生的。

但隨着 Redis Cluster 方案的逐漸成熟，業界越來越多的公司開始採用官方方案（畢竟官方保證持續維護，Twemproxy、Codis 目前都逐漸放棄維護了），Redis Cluster 方案比上面講到的分片方案更簡單，它的架構如下。

Redis Cluster 無需部署哨兵集羣，集羣內 Redis 節點通過 Gossip 協議互相探測健康狀態，在故障時可發起自動切換。

另外，關於路由轉發規則，也不需要客戶端自己編寫了，Redis Cluster 提供了「配套」的 SDK，只要客戶端升級 SDK，就可以和 Redis Cluster 集成，SDK 會幫你找到 key 對應的 Redis 節點進行讀寫，還能自動適配 Redis 節點的增加和刪除，業務側無感知。

雖然省去了哨兵集羣的部署，維護成本降低了不少，但對於客戶端升級 SDK，對於新業務應用來說，可能成本不高，但對於老業務來講，「升級成本」還是比較高的，這對於切換官方 Redis Cluster 方案有不少阻力。

於是，各個公司有開始自研針對 Redis Cluster 的 Proxy，降低客戶端的升級成本，架構就變成了這樣：

這樣，客戶端無需做任何變更，只需把連接地址切到 Proxy 上即可，由 Proxy 負責轉發數據，以及應對後面集羣增刪節點帶來的路由變更。

至此，業界主流的 Redis 分片架構已經成型，當你使用分片集羣后，對於未來更大的流量壓力，也都可以從容面對了！

總結

總結一下，我們是如何從 0 到 1，再從 1 到 N 構建一個穩定、高性能的 Redis 集羣的，從這之中你可以清晰地看到 Redis 架構演進的整個過程。

  1. 數據怕丟失：持久化（RDB/AOF）

  2. 恢復時間久：主從副本（副本隨時可切）

  3. 故障手動切換慢：哨兵集羣（自動切換）

  4. 讀存在壓力：擴容副本（讀寫分離）

  5. 寫存在壓力 / 容量瓶頸：分片集羣

  6. 分片集羣社區方案：Twemproxy、Codis（Redis 節點之間無通信，需要部署哨兵，可橫向擴容）

  7. 分片集羣官方方案：Redis Cluster （Redis 節點之間 Gossip 協議，無需部署哨兵，可橫向擴容）

  8. 業務側升級困難：Proxy + Redis Cluster（不侵入業務側）

至此，我們的 Redis 集羣才得以長期穩定、高性能的爲我們的業務提供服務。

希望這篇文章可以幫你更好的理解 Redis 架構的演進之路。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/3818RiO0gNF261AsS_1tVA

猜你喜歡