大廠標配的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 的命令首先在記憶體中處理，然后，如果在這些實體上設定了持久性，則在某個時間間隔上會有一個fork行程，來生成資料持久化 RDB（Redis 資料的非常緊湊的時間點表示）快斬訓 AOF（僅附加檔案），

這兩個流程可以讓 Redis 擁有長期存盤，支持各種復制策略，并啟用更復雜的拓撲，如果 Redis 未設定為持久化資料，則在重新啟動或故障轉移時資料會丟失，如果在重啟時啟用了持久化，它會將 RDB 快斬訓 AOF 中的所有資料加載回記憶體，然后實體可以支持新的客戶端請求，

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

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

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

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

更明確地說，當 Redis 副本實體僅落后于主實體幾個偏移量時，它會從主實體接收剩余的命令，然后在其資料集上重放，直到同步完成，如果兩個實體無法就復制 ID 達成一致，或者主實體不知道偏移量，則副本將請求全量同步，這時主實體會創建一個新的 RDB 快照并將其發送到副本，

在此傳輸之間，主實體會緩沖快照截止和當前偏移之間的所有中間更新指令，這樣在快照同步完后，再將這些指令發送到副本實體，這樣完成后，復制就可以正常繼續，

如果一個實體具有相同的復制 ID 和偏移量，則它們具有完全相同的資料，現在你可能想知道為什么需要復制 ID，當 Redis 實體被提升為主實體或作為主實體從頭開始重新啟動時，它會被賦予一個新的復制 ID，

這用于推斷此新提升的副本實體是從先前哪個主實體復制出來的，這允許它能夠執行部分同步（與其他副本節點），因為新的主實體會記住其舊的復制 ID，

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

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

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

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

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

以下是它的職責：

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

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

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

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

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

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

沒有持久性保證，特別是持久化到磁盤的操作（見下文）是異步的，還有一個麻煩的問題，當客戶發現新的 primary 時，我們失去了多少寫給一個不知道的 primary？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 從一個分片移動到另一個分片，并簡化將新的主實體添加到集群中的程序，

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

因此，為了映射 “foo”，我們采用一個確定性的鍵（foo）散列，并通過散列槽的數量（16K）對其進行修改，從而得到 M2 的映射，現在假設我們添加了一個新實體 M3，新的映射將是：

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

Redis Cluster 使用 gossiping 來確定整個集群的健康狀況，在上圖中，我們有 3 個 M 個節點和 3 個 S 節點，所有這些節點不斷地進行通信以了解哪些分片可用并準備好為請求提供服務，

如果足夠多的分片同意 M1 沒有回應，他們可以決定將 M1 的副本 S1 提升為主節點以保持集群健康，觸發此操作所需的節點數量是可配置的，并且必須正確執行此操作，如果操作不當并且在磁區的兩邊相等時無法打破平局，則可能會導致集群被拆分，這種現象稱為裂腦，作為一般規則，必須擁有奇數個主節點和兩個副本，以實作最穩健的設定，

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

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

無持久化：如果你愿意，可以完全禁用持久化，這是運行 Redis 的最快方式，并且沒有持久性保證，

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

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

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

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

然后，如果可能，我們使用 fsync 將其重繪到磁盤（當此運行可配置時），它將被持久化，缺點是格式不緊湊，并且比 RDB 檔案使用更多的磁盤，

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

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

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

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

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

當你 fork 一個行程時，父行程和子行程共享記憶體，并且在該子行程中 Redis 開始快照（Redis）行程，這是通過一種稱為寫時復制的記憶體共享技術實作的——該技術在創建分叉時傳遞對記憶體的參考，如果在子行程持久化到磁盤時沒有發生任何更改，則不會進行新的分配，

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