深入理解Redis

什麼是 Redis？

Redis （“REmote DIctionary Service”）是一個開源的鍵值對資料庫伺服器。

Redis 更準確的描述是一個數據結構伺服器。 Redis 的這種特殊性質讓它在開發人員中很受歡迎。

Redis不是通過迭代或者排序方式處理資料，而是一開始就按照資料結構方式組織。 早期，它的使用很像 Memcached，但隨著 Redis 的改進，它在許多其他用例中變得可行，包括髮布-訂閱機制、流(streaming)和佇列。

主要來說，Redis 是一個記憶體資料庫，用作另一個“真實”資料庫（如 MySQL 或 PostgreSQL）前面的快取，以幫助提高應用程式效能。 它通過利用記憶體的高速訪問速度，從而減輕核心應用程式資料庫的負載，例如：

• 不經常更改且經常被請求的資料
• 任務關鍵性較低且經常變動的資料。

上述資料的示例可以包括會話或資料快取以及儀表板的排行榜或彙總分析。

但是，對於許多用例場景，Redis 都可以提供足夠的保證，可以將其用作成熟的主資料庫。 再加上 Redis 外掛及其各種高可用性 (HA) 設定，Redis 作為資料庫對於某些場景和工作負載變得非常有用。

另一個重要方面是 Redis 模糊了快取和資料儲存之間的界限。 這裡要理解的重要一點是，相比於使用 SSD 或 HDD 作為儲存的傳統資料庫，讀取和操作記憶體中資料的速度要快得多。

最初，Redis 最常被比作 Memcached，後者當時缺乏任何非易失性持久化。

這是當前兩個快取之間的功能細分。

雖然現在擁有多種配置方式將資料持久化到磁碟，但當時首次引入持久化時，Redis 是使用快照方式，通過非同步拷貝記憶體中的資料方式來做持久化。 不幸的是，這種機制的缺點是可能會在快照之間丟失資料。

Redis 自 2009 年成立到現在已經變的很成熟。我們將介紹它的大部分架構和拓撲，以便你可以將 Redis 新增到你的資料儲存系統庫中。

Redis 架構

在開始討論 Redis 內部結構之前，讓我們先討論一下各種 Redis 部署及其權衡取捨。

我們將主要關注以下這些設定：

• 單個 Redis 例項
• Redis 高可用性
• Redis 哨兵
• Redis 叢集

根據你的用例和規模，決定使用哪一種設定。

單個 Redis 例項

單個 Redis 例項是最直接的 Redis 部署方式。 它允許使用者設定和執行小型例項，從而幫助他們快速發展和加速服務。 但是，這種部署並非沒有缺點。 例如，如果此例項失敗或不可用，則所有客戶端對 Redis 的呼叫都將失敗，從而降低系統的整體效能和速度。

如果有足夠的記憶體和伺服器資源，這個例項可以很強大。 主要用於快取的場景可能會以最少的設定獲得顯著的效能提升。 給定足夠的系統資源，你可以在應用程式執行的同一機器上部署此 Redis 服務。

在管理系統內的資料方面，瞭解一些 Redis 概念是必不可少的。 傳送到 Redis 的命令首先在記憶體中處理。 然後，如果在這些例項上設定了永續性，則在某個時間間隔上會有一個fork程序，來生成資料持久化 RDB（Redis 資料的非常緊湊的時間點表示）快照或 AOF（僅附加檔案）。

這兩個流程可以讓 Redis 擁有長期儲存，支援各種複製策略，並啟用更復雜的拓撲。 如果 Redis 未設定為持久化資料，則在重新啟動或故障轉移時資料會丟失。 如果在重啟時啟用了持久化，它會將 RDB 快照或 AOF 中的所有資料載入回記憶體，然後例項可以支援新的客戶端請求。

話雖如此，讓我們看看你可能會用到的更多分散式 Redis 設定。

Redis 高可用性

Redis 的另一個流行設定是主從部署方式，從部署保持與主部署之間資料同步。 當資料寫入主例項時，它會將這些命令的副本傳送到從部署客戶端輸出緩衝區，從而達到資料同步的效果。 從部署可以有一個或多個例項。 這些例項可以幫助擴充套件 Redis 的讀取操作或提供故障轉移，以防 main 丟失。

我們現在已經進入了一個分散式系統，因此需要在此拓撲中考慮許多新事物。 以前簡單的事情現在變得複雜了。

Redis 複製

Redis 的每個主例項都有一個複製 ID 和一個偏移量。 這兩條資料對於確定副本可以繼續其複製過程的時間點或確定它是否需要進行完整同步至關重要。 對於主 Redis 部署上發生的每個操作，此偏移量都會增加。

更明確地說，當 Redis 副本例項僅落後於主例項幾個偏移量時，它會從主例項接收剩餘的命令，然後在其資料集上重放，直到同步完成。如果兩個例項無法就複製 ID 達成一致，或者主例項不知道偏移量，則副本將請求全量同步。這時主例項會建立一個新的 RDB 快照並將其傳送到副本。在此傳輸之間，主例項會緩衝快照截止和當前偏移之間的所有中間更新指令，這樣在快照同步完後，再將這些指令傳送到副本例項。這樣完成後，複製就可以正常繼續。

如果一個例項具有相同的複製 ID 和偏移量，則它們具有完全相同的資料。現在你可能想知道為什麼需要複製 ID。當 Redis 例項被提升為主例項或作為主例項從頭開始重新啟動時，它會被賦予一個新的複製 ID。這用於推斷此新提升的副本例項是從先前哪個主例項複製出來的。這允許它能夠執行部分同步（與其他副本節點），因為新的主例項會記住其舊的複製 ID。

例如，兩個例項（主例項和從例項）具有相同的複製 ID，但偏移量相差幾百個命令，這意味著如果在例項上重放這些偏移量後面的命令，它們將具有相同的資料集。 現在，如果複製 ID 完全不同，並且我們不知道新降級（或重新加入）從節點的先前複製 ID（沒有共同祖先）。 我們將需要執行昂貴的全量同步。

相反，如果我們知道以前的複製 ID，我們就可以推斷如何使資料同步，因為我們能夠推斷出它們共享的共同祖先，並且偏移量對於部分同步再次有意義。

Redis 哨兵（Sentinel）

Sentinel 是一個分散式系統。 與所有分散式系統一樣，Sentinel 有幾個優點和缺點。 Sentinel 的設計方式是，一組哨兵程序協同工作以協調狀態，從而為 Redis 提供高可用性。 畢竟，你不希望保護你免受故障影響的系統有自己的單點故障。

Sentinel 負責一些事情。 首先，它確保當前的主例項和從例項正常執行並做出響應。 這是必要的，因為哨兵（與其他哨兵程序）可以在主節點和/或從節點丟失的情況下發出警報並採取行動。 其次，它在服務發現中發揮作用，就像其他系統中的 Zookeeper 和 Consul 一樣。 所以當一個新的客戶端嘗試向 Redis 寫東西時，Sentinel 會告訴客戶端當前的主例項是什麼。

因此，哨兵不斷監控可用性並將該資訊傳送給客戶端，以便他們能夠在他們確實進行故障轉移時對其做出反應。

以下是它的職責：

• 監控——確保主從例項按預期工作。
• 通知 — 通知系統管理員 Redis 例項中的事件。
• 故障轉移管理——如果主例項不可用並且足夠多的（法定數量）節點同意這是真的，Sentinel 節點可以啟動故障轉移。
• 配置管理——Sentinel 節點還充當當前主 Redis 例項的發現服務。

以這種方式使用 Redis Sentinel 可以進行故障檢測。 此檢測涉及多個哨兵程序同意當前主例項不再可用。 這個協議過程稱為 Quorum。 這可以提高魯棒性並防止一臺機器行為異常導致無法訪問主 Redis 節點。

此設定並非沒有缺點，因此我們將在使用 Redis Sentinel 時介紹一些建議和最佳實踐。

你可以通過多種方式部署 Redis Sentinel。 老實說，要提出任何明智的建議，我需要有關你的系統的更多背景資訊。 作為一般指導，我建議在每個應用程式伺服器旁邊執行一個哨兵節點（如果可能的話），這樣你也不需要考慮哨兵節點和實際使用 Redis 的客戶端之間的網路可達性差異。

你可以將 Sentinel 與 Redis 例項一起執行，甚至可以在獨立節點上執行，只不過它會按照別的方式處理，從而會讓事情變得更復雜。 我建議至少執行三個節點，並且至少具有兩個法定人數（quorum）。 這是一個簡單的圖表，分解了叢集中的伺服器數量以及相關的法定人數和可容忍的可持續故障。

這會因系統而異，但總體思路是不變的。

讓我們花點時間思考一下這樣的設定會出現什麼問題。 如果你執行這個系統足夠長的時間，你會遇到所有這些。

1. 如果哨兵節點超出法定人數怎麼辦？
2. 如果網路分裂將舊的主例項置於少數群體中怎麼辦？ 這些寫入會發生什麼？ （劇透：當系統完全恢復時它們會丟失）
3. 如果哨兵節點和客戶端節點（應用程式節點）的網路拓撲錯位會發生什麼？

沒有永續性保證，特別是持久化到磁碟的操作（見下文）是非同步的。 還有一個麻煩的問題，當客戶發現新的primary時，我們失去了多少寫給一個不知道的primary？ Redis 建議在建立新連線時查詢新的主節點。 根據系統配置，這可能意味著大量資料丟失。

如果你強制主例項將寫入複製到至少一個副本例項，有幾種方法可以減輕損失程度。 請記住，所有 Redis 複製都是非同步的，這是有其權衡的考慮。 因此，它需要獨立跟蹤確認，如果至少有一個副本例項沒有確認它們，主例項將停止接受寫入。

Redis 叢集

我相信很多人都想過當你無法將所有資料儲存在一臺機器上的記憶體中時會發生什麼。 目前，單個伺服器中可用的最大 RAM 為 24TIB，這是目前AWS線上列出來的。 當然，這很多，但對於某些系統來說，這還不夠，即使對於快取層也是如此。

Redis Cluster 允許 Redis 的水平擴充套件。

首先，讓我們擺脫一些術語約束； 一旦我們決定使用 Redis 叢集，我們就決定將我們儲存的資料分散到多臺機器上，這稱為分片。 所以叢集中的每個 Redis 例項都被認為是整個資料的一個分片。

這帶來了一個新的問題。 如果我們向叢集推送一個key，我們如何知道哪個 Redis 例項（分片）儲存了該資料？ 有幾種方法可以做到這一點，但 Redis Cluster 使用演算法分片。

為了找到給定key的分片，我們對key進行雜湊處理，並通過對總分片數量取模。 然後，使用確定性雜湊函式，這意味著給定的key將始終對映到同一個分片，我們可以推斷將來讀取特定key的位置。

當我們之後想在系統中新增一個新的分片時會發生什麼？ 這個過程稱為重新分片。

假設鍵 'foo'之前對映到分片 0， 在引入新分片後它可能會對映到分片 5。 但是，如果我們需要快速擴充套件系統，移動資料來達到新的分片對映，這將是緩慢且不切實際的。 它還對 Redis 叢集的可用性產生不利影響。

Redis Cluster 為這個問題設計了一種解決方案，稱為 Hashslot，所有資料都對映到它。 有16K雜湊槽。 這為我們提供了一種在叢集中傳播資料的合理方式，當我們新增新的分片時，我們只需在系統之間移動雜湊槽。 通過這樣做，我們只需要將 hashlot 從一個分片移動到另一個分片，並簡化將新的主例項新增到叢集中的過程。

這可以在沒有任何停機時間和最小的效能影響的情況下實現。 讓我們通過一個例子來談談。

M1 包含從 0 到 8191 的雜湊槽。

M2 包含從 8192 到 16383 的雜湊槽。

因此，為了對映“foo”，我們採用一個確定性的鍵（foo）雜湊，並通過雜湊槽的數量（16K）對其進行修改，從而得到 M2 的對映。 現在假設我們添加了一個新例項 M3。 新的對映將是

M1 包含從 0 到 5460 的雜湊槽。

M2 包含從 5461 到 10922 的雜湊槽。

M3 包含從 10923 到 16383 的雜湊槽。

現在對映到 M2 的 M1 中對映雜湊槽的所有鍵都需要移動。 但是雜湊槽的各個鍵的雜湊不需要移動，因為它們已經被劃分到雜湊槽中。 因此，這一級別的誤導（misdirection）解決了演算法分片的重新分片問題。

Gossiping協議

Redis Cluster 使用 gossiping 來確定整個叢集的健康狀況。 在上圖中，我們有 3個M 個節點和 3 個 S 節點。 所有這些節點不斷地進行通訊以瞭解哪些分片可用並準備好為請求提供服務。 如果足夠多的分片同意 M1 沒有響應，他們可以決定將 M1 的副本 S1 提升為主節點以保持叢集健康。 觸發此操作所需的節點數量是可配置的，並且必須正確執行此操作。 如果操作不當並且在分割槽的兩邊相等時無法打破平局，則可能會導致叢集被拆分。 這種現象稱為裂腦。 作為一般規則，必須擁有奇數個主節點和兩個副本，以實現最穩健的設定。

Redis 持久化模型

如果我們要使用 Redis 儲存任何型別的資料同時要求安全儲存，瞭解 Redis 是如何做到這一點很重要。 在許多用例中，如果你丟失了 Redis 儲存的資料，這並不是世界末日。 將其用作快取或在其支援實時分析的情況下，如果發生資料丟失，則並非世界末日。

在其他場景中，我們希望圍繞資料永續性和恢復有一些保證。

無持久化

無持久化：如果你願意，可以完全禁用持久化。 這是執行 Redis 的最快方式，並且沒有永續性保證。

RDB檔案

RDB（Redis 資料庫）：RDB 持久化以指定的時間間隔執行資料集的時間點快照。

這種機制的主要缺點是快照之間的資料會丟失。 此外，這種儲存機制還依賴於主程序的fork，在更大的資料集中，這可能會導致服務請求的瞬間延遲。 話雖如此，RDB 檔案在記憶體中的載入速度要比 AOF 快得多。

AOF

AOF（Append Only File）：AOF 持久化記錄伺服器接收到的每個寫入操作，這些操作將在伺服器啟動時再次被執行，重建原始資料集。

這種永續性的方法能夠確保比 RDB 快照更持久，因為它是一個僅附加檔案。 隨著操作的發生，我們將它們緩衝到日誌中，但它們還沒有被持久化。 該日誌與我們執行的實際命令一致，以便在需要時進行重放。

然後，如果可能，我們使用 fsync 將其重新整理到磁碟（當此執行可配置時），它將被持久化。 缺點是格式不緊湊，並且比 RDB 檔案使用更多的磁碟。

為什麼不兼得？

RDB + AOF：可以將 AOF 和 RDB 組合在同一個 Redis 例項中。 如果你願意的化，可以以速度換取持久化是一種折衷方法。 我認為這是設定 Redis 的一種可接受的方式。 在重啟的情況下，請記住如果兩者都啟用，Redis 將使用 AOF 來重建資料，因為它是最完整的。

Forking

現在我們瞭解了持久化的型別，讓我們討論一下我們如何在像 Redis 這樣的單執行緒應用程式中實際執行它。

在我看來，Redis 最酷的部分是它如何利用forking和寫時複製來高效地促進資料持久化。

Forking是作業系統通過建立自身副本來建立新程序的一種方式。 這樣，你將獲得一個新的程序 ID 和一些其他資訊和控制代碼，因此新forking的程序（子程序）可以與原始程序父程序通訊。

現在事情變得有趣了。 Redis 是一個分配了大量記憶體的程序，那麼它如何在不耗盡記憶體的情況下進行復制呢？

當你 fork 一個程序時，父程序和子程序共享記憶體，並且在該子程序中 Redis 開始快照 (Redis) 程序。 這是通過一種稱為 寫時複製 的記憶體共享技術實現的——該技術在建立分叉時傳遞對記憶體的引用。 如果在子程序持久化到磁碟時沒有發生任何更改，則不會進行新的分配。

在發生更改的情況下，核心會跟蹤對每個頁面的引用，如果某個頁面有多個更改，則將更改寫入新頁面。 子程序完全不知道更改以及具有一致的記憶體快照的事情。 因此，在只使用了一小部分記憶體的情況下，我們能夠非常快速有效地獲得潛在千兆位元組記憶體的時間點快照！

如果你喜歡這個，我們還有更多這樣的內容！ 我們努力使所有這些細緻入微的主題易於理解，並突出你會遇到它們的地方！

註冊或與你認為可以從本文中受益的人分享將不勝感激。

我希望你學到了一些關於 Redis 如何在我們的系統中執行的有用知識！ 我們鼓勵您提供反饋，您可以在 Twitter 上聯絡我@ myusuf3 ！

原文連結：（翻譯：王歡）