一、前言

自建 Redis 系統是得物 DBA 團隊自研高性能分布式 KV 緩存系統，目前管理的 ECS 內存總容量超過數十TB，數百多個 Redis 緩存集群實例，數萬多個 Redis 數據節點，其中內存規格超過 1T 的大容量集群多個。

自建 Redis 系統采用 Proxy 架構，包含 ConfigServer、Proxy 等核心組件，還包括一個具備實例自動化部署、資源管理、診斷與分析等重要功能在內的完善的自動化運維平臺。

本文將從系統架構及核心組件、自建 Redis 支持的重要特性、自動化運維平臺的重要功能等多方面為大家介紹自建 Redis 系統。

二、自建 Redis 架構及核心組件

自建 Redis 分布式 KV 緩存系統由 ConfigServer、Redis-Proxy、Redis-Server 等核心組件構成，整體架構圖如下所示：

圖片

下面為大家逐一介紹自建 Redis 各核心組件支持的重要功能和特性。

ConfigServer

ConfigServer 是自建 Redis 系統中關鍵組件之一，跨多可用區多節點部署，采用 Raft 協議實現 ConfigServer 組件高可用；ConfigServer 主要負責三方面職責：

負責 Proxy 添加與刪除、Group 創建與刪除、Redis-Server 實例添加與刪除、Redis-Server 實例手動主從切換、水平擴容與數據遷移等功能操作。

集群拓撲發生變化時，主動向 Redi-Proxy 更新集群拓撲。

負責 Redis-Server 實例故障檢測與自動故障轉移（主節點故障后自動主從切換）。

ConfigServer 系統結構圖如下所示：

圖片

每個自建 Redis 集群會對應部署一組獨立的 ConfigServer 組件，并且每組 ConfigServer 采用至少三節點部署，分布在三個不同的可用區，保證自建 Redis 系統高可用：

• ConfigServer 多節點多可用區部署，保證了 ConfigServer 組件自身的高可用。
• 同時，也保證 Redis-Server 的高可用，任意一個可用區故障，剩余 ConfigServer 依然能高效完成 Redis-Server 的宕機判定、選主與故障 Failover。
• 相對于開源 Redis 原生 Cluster 模式，也不會因多數 Redis-Server 主節點故障而無法完成故障判定與 Failover。

故障檢測與轉移

ConfigServer 負責 Redis-Server 節點故障檢測與自動故障轉移，ConfigServer 會對每一個 Group 的 Master 節點進行定期探活，如果發現某一個 Group 的 Master 節點不可用，就會執行 Failover 流程，選擇該 Group 內一個可用的 Slave 節點提升為新的 Master 節點，保證該 Group 可繼續對外提供服務。

實現思路參考開源 Redis Sentinel，不過由于 ConfigServer 是 Golang 實現，而開源 Redis Sentinel 是使用 C 語言實現，所以在部分細節上略有不同。

多協程：在 Redis Sentinel 中，是在一個單線程中定時檢測所有 Redis-Server 節點，而由于 Golang 支持協程，在 ConfigServer 中是為實例的每個 Group 開啟一個協程，在協程中定時檢測該 Group 對應的 Redis-Server 狀態。

自定義通訊協議：在 Redis Sentinel 中，Sentinel 之間通過 Redis-Server 節點交換元數據信息，來發現負責同一個 Redis-Server 的 Sentinel 節點，以及交換觀察的節點狀態；而在 ConfigServer 中，ConfigServer 之間是采用自定義 TCP 協議直接通訊，交換信息更高效，也能縮短故障切換時間。

故障檢測

• 每個 ConfigServer 定期給該實例的所有 Redis-Server 節點發送 Ping 和 Info 命令，用于檢測節點的可用性和發現新的從節點。
• 當 ConfigServer 向 Redis-Server 節點發送命令超時時，將節點標記為主觀下線，并傳播節點的主觀下線狀態。
• ConfigServer Leader 節點發現某節點處于主觀下線時，會主動查詢其他 ConfigServer 對該節點的狀態判定，如果多數 ConfigServer 節點都將該 Redis-Server 節點標記為主觀下線，則 Leader 節點將該 Redis 節點標記為客觀下線，并發起故障轉移流程。

故障轉移

• 從故障 Redis 主節點的所有從節點中選擇一個最優的從節點，選擇策略包含：

過濾掉不健康的從節點，比如處于主觀下線或者客觀下線狀態。

選擇 Slave-Priority 最高的從節點。

選擇復制偏移量最大的從節點。

選擇 Runid 最小的從節點。

• 將選取出來的從節點提升為新的主節點，即向該節點執行 slaveof no one 命令。
• 將其他從節點設置為新主節點的從節點。
• 并保持對舊主節點的狀態關注，如果舊主節點恢復，將舊主節點也更新為新主節點的從節點。

Redis-Proxy

Redis-Proxy 組件是自建 Redis 系統中的代理服務，負責接受客戶端連接，然后轉發客戶端命令到后端相應的 Redis-Server 節點，使得后端 Redis-Server 集群部署架構對業務透明，Proxy 支持 Redis RESP 協議，業務訪問 Proxy 就像訪問一個單點 Redis 服務一樣，業務可以把一個自建 Redis 集群當作一個容量無限大的單點 Redis 實例即可。

自建 Redis 為每個實例部署一組獨立的 Proxy 節點，Proxy 是一個無狀態服務，可以很方便的進行水平擴容，提高業務訪問自建 Redis 系統的 QPS。

在自建 Redis 中，每個集群可能包含多個 Group，每個 Group 對應一組主從 Redis-Server 節點，每個 Group 負責一部分 Key，同時，整個集群劃分為 1024 個槽（slot），每個 Group 負責其中一部分槽（slot），用戶寫入的 Key 通過以下算法來計算對應的 slot，然后存儲到對應節點。

slot 計算公式： slot(key) = crc32(key) % 1024

圖片

Proxy 接收到用戶命令后，提取訪問的 Key，通過上面同樣算法計算相應的 slot，獲取負責該 slot 的對應 Redis-Server 實例的連接，再將用戶命令轉發到對應的 Redis-Server 實例上執行，讀取 Redis-Server 返回的結果發送給用戶。

DBA 團隊針對 Proxy 組件做了大量性能優化，相比市面上開源的支持 Redis RESP 協議的 Proxy 版本，臨時對象內存分配減少了約 20 倍，極大的減輕 GC 壓力以及 GC 消耗的 CPU；大量短鏈接場景下，QPS 提升約10%。

同時，自建 Redis-Proxy 還支持同城雙活、異步雙寫等特色功能。

同城雙活

自建 Redis 為了保證數據的高可用和高可靠，每個 Redis 實例中每個分組采用至少一主一從的部署方案，且主從節點分別部署在不同可用區，在默認的訪問模式下，業務讀寫都訪問主節點，從節點僅僅作為熱備節點。

為了提升業務在多可用區部署場景下訪問緩存性能與降低延遲，以及最大化利用從節點的價值，自建 Redis-Proxy 支持同城雙活功能。自建 Redis 同城雙活采用單寫就近讀的方案實現，實現原理圖如下所示：

圖片

注：需要通過以下方式之一來實現動態配置

• 通過容器的 ServiceName 實現同 AZ Proxy 節點優先訪問 (優先)。
• 通過云廠商的 PrivateZone 實現智能 DNS 解析(容器和非容器應用都行)。

Redis-Server

• 采用至少一主一從的部署方案，并且主從節點跨可用區部署，分別部署在與業務對應的可用區。

Redis-Proxy

• Redis-Proxy 同樣采用多可用區部署，與業務可用區相同。
• 各可用區 Proxy 將寫請求自動路由到主節點，依然寫主節點。
• 讀請求優先就近訪問本可用區從節點，本可用區無可用從節點時，支持自動訪問主節點或優先訪問其他可用區從節點。

異步雙寫

針對業務從云 Redis 遷移到自建 Redis、以及大集群拆分場景，對于數據可靠性要求高的業務，Proxy 支持雙寫功能。

以從云 Redis 遷移到自建 Redis 為例，遷移期間 Proxy 同時寫云 Redis 和自建 Redis，保證兩邊數據實時一致，從而可以隨時回滾，做到平滑遷移。

Proxy 雙寫功能具備以下特性：

• Proxy 雙寫功能采用異步雙寫操作實現，性能優異，雙寫操作對業務幾乎無影響。
• Proxy 支持轉發、只讀、雙寫等多種模式，業務接入自建 Redis 后，自建 Redis 通過在線動態更改配置，平滑的完成整個切換過程，無需業務頻繁更改配置或者重啟等。
• Proxy 雙寫支持云 Redis 優先或者自建 Redis 優先（以云 Redis 遷移為例），且可在線動態調整。
• 同時，提供數據比對工具，用于雙寫期間數據對比，隨時觀察兩邊數據一致性情況；數據對比支持多種策略，包括對比類型、對比長度或元素數量。

Redis-Server

Redis-Server 組件為開源 Redis 版本基礎上，增加槽 slot 同步遷移與異步遷移等相關功能；支持原生開源 Redis 的所有特性，比如支持 String、Hash、List、Set、ZSet 等常用數據結構，AOF 持久化、主從復制、Lua腳本等等。

Share-Nothing 架構：自建 Redis 系統中，Redis-Server 服務采用集群化部署，整個集群由多個 Group 共同組成，每個 Group 中包含一主 N 從多個 Redis-Server 實例，Group 之間的 Redis-Server 節點相互沒有通信，為 Share-Nothing 架構。同時，整個集群劃分為 1024 個槽（slot），每個 Group 負責其中一部分槽（slot），用戶寫入的 Key 通過上面提到的算法來計算對應的 slot，然后存儲到負責該 slot 的 Group 中的 Redis-Server 節點上。查詢 Key 時，通過同樣的算法去對應的節點上查詢。

Async-Fork 特性

在 Redis 中，在 AOF 文件重寫、生成 RDB 備份文件以及主從全量同步過程中，都需要使用系統調用 Fork 創建一個子進程來獲取內存數據快照，在 Fork() 函數創建子進程的時候，內核會把父進程的「頁表」復制一份給子進程，如果頁表很大，在現有常見操作系統中，復制頁表的過程耗時會非常長，那么在此期間，業務訪問 Redis 讀寫延遲會大幅增加。

自建 Redis 系統中，Redis-Server 通過優化并適配最新的支持 Async-Fork 特性的操作系統，極大的提升 Fork 操作性能：

• Fork 命令耗時大幅減小，并且不隨數據量增長而增長，基本穩定在 200 微秒左右；
• TP100 抖動得到明顯改善，TP100 值也不隨數據量增長而變大，基本在 1-2 毫秒左右；
• 相比原生 Redis Fork 耗時減少 98%。日常運維中，添加從節點、主從切換、RDB 離線分析等常見運維操作均對業務無感知，不會造成業務性能抖動。

圖片

圖片

注：該圖表使用了雙縱坐標詳細內容可閱讀《VLDB 頂會論文 Async-fork 解讀與 Redis 實踐》。

數據遷移

為什么需要做數據遷移？主要是為了水平擴容，自建 Redis 將每個集群實例劃分為固定數量的槽 slot，每個 Group 負責一部分槽，當進行水平擴容時，需要重新分配 slot 的分布，并且將一部分 slot 從原有節點遷移到新節點，同時將由 slot 負責的數據一起遷移到新節點。

數據遷移過程包括在源節點將 Key 對應的 Value 使用 Dump 命令進行序列化，然后將數據發送到目標節點，目標節點使用 Restore 命令將 Key 和 Value 存儲到本地 Redis 中，最后源節點將該 Key 刪除。

自建 Redis 支持同步遷移與異步遷移兩種方式。

圖片

圖片

同步遷移：即在上述整個遷移過程中，源端的 Migrate 命令處于阻塞狀態，直到目標端成功加載數據，并且返回成功，源節點刪除該 Key 后，Migrate 命令才響應客戶端成功。由于 Redis 數據操作是一個單線程模型，所有命令的處理的都在主線程中處理，因此 Migrate 命令會極大地影響其他正常業務的訪問。

異步遷移：Migrate 命令僅阻塞 Dump 序列化數據、并且異步發送到目標節點，然后即返回客戶端成功；目標節點接收到數據后，使用 Restore 命令進行保存，保存成功后，主動給源節點發送一個 ACK 命令，通知源節點將遷移的 Key 刪除。異步遷移減少源端 Migrate 命令的阻塞時間，減少了 slot 遷移過程中對業務的影響。

三、自動化運維平臺

自建 Redis 系統擁有功能完善的自動化運維平臺。其主要功能包括：緩存實例自動化部署、快速水平擴容與垂直擴容、多維度資源管理、診斷與分析等。

運維平臺架構

自建 Redis 自動化運維平臺包括Redis 管控平臺、Kv-Admin、Kv-Agent、Prometheus 等組件，部署架構如下圖所示：

圖片

Redis 管控平臺

Redis 管控平臺是自建 Redis 綜合運維管理平臺，自建 Redis 的可視化操作均在 Redis 管控平臺上完成，包括實例部署、擴容、數據遷移等在內的所有日常運維操作均可在管理平臺上完成。

Kv-Admin

Kv-Admin 是自動化運維平臺的核心組件，負責處理所有前端發送過來的請求，核心功能包括：

• 負責完成實例部署時任務調度、機器推薦、端口分配、SLB 推薦與綁定。
• 實例列表展示、實例基本信息查詢。
• 數據離線分析與保存。
• 資源池管理及生成資源報表。

Kv-Agent

每個 ECS 上會部署一個 Kv-Agent 組件，Kv-Agent 負責完成實例部署、實例啟停等操作；基于心跳元數據的 Exporter 自動注冊與解除；

同時，Kv-Agent 包含 Exporter 模塊，負責 Redis-Server 節點的監控信息采集，然后將數據規范化后通過端點暴露給 Prometheus。

APM / Prometheus

APM 監控平臺或者 Prometheus 負責從 Exporter 暴露的端點拉取監控數據；自建 Redis 監控與告警均接入公司 APM 平臺。

實例自動化部署

一個緩存實例的部署非常復雜，涉及機器選擇、配置文件準備、節點安裝與啟動、槽位分配、主從關系設置、SLB 分配與綁定、以及相關組件的部署等一系列動作。

自動化運維平臺支持安裝包版本管理，在部署頁面選擇合適的包版本、配置對應實例可用區、規格等基本信息后，一鍵操作即可完成 ConfigServer、Redis-Proxy、Redis-Server 等組件的部署，自動完成組件部署過程中涉及的上述機器推薦、配置文件準備、節點安裝與啟動等所有過程。

為了保證實例中所有組件的高可用，自動化部署過程中包含一些必要的部署規則：

• ConfigServer 組件會部署在三個不同的可用區。
• 避免同一個集群實例的多個 Redis-Server、Redis-Proxy 節點部署在相同的 ECS 上，每個 ECS 上可部署的同一個集群實例的 Server 或 Proxy 組件數量可配置。
• 每個 ECS 最多分配總內存容量的 90%，預留一定的數據增長空間。
• 根據 ECS 可用內存，優先推薦剩余可用內存多的 ECS。
• 根據 Group 數量，自動均衡分配每個 Group 負責的 slot 數量。
• 根據 SLB 近三天的流量峰值，自動綁定最優的 SLB。

實例擴容

當業務數據增長導致實例內存使用率超過一定閾值后，根據單節點分配的最大內存、實例的 Group 數量等情況綜合考慮，運維可選擇為實例進行垂直擴容或者水平擴容。

垂直擴容，即動態修改單節點的 Maxmemory 參數，提高單節點的容量。

水平擴容，即增加實例的 Group 數量，對應增加主從節點數量，然后重新進行 slot 分配和對應的數據遷移動作。

一般來說，當單節點規格小于 4G 時，會優先考慮垂直擴容，簡單快速，對業務無任何影響。

自動化運維平臺支持方便的垂直擴容和水平擴容操作。

對于垂直擴容，運維平臺支持批量調整實例 Redis-Server 節點的容量。

對于水平擴容，同實例初始部署一樣，運維平臺支持新增 Redis-Server 節點的自動化部署、主從關系設置等，同時支持按照實例總節點數重新自動均衡分配每個 Group 負責的 slot 數量，并自動完成數據遷移，數據遷移進度可視化。

資源管理

自建 Redis 運維平臺目前管理的 ECS 超過數千臺，運維平臺支持 ECS 資源批量添加、資源分配、資源鎖定、資源推薦等資源管理功能，以及提供資源利用率報表。

運維平臺支持 ECS 可用內存的管理與分配，運維平臺記錄每臺 ECS 的剩余可分配內存容量，Redis-Server 實例部署時，優先推薦剩余可分配內存多的 ECS，分配出去的 ECS 更新對應的可用內存容量。

Redis-Proxy 和 ConfigServer 部署時，優先推薦部署的實例數量較少的 ECS。

診斷與分析

計算實例綜合得分：運維平臺通過分析所有實例關鍵監控指標前一天的峰值，再根據各項指標的權重，每天自動計算所有實例的得分，根據各實例的得分即可快速了解各實例的使用健康度。

參與計算得分的關鍵指標包括：Proxy CPU、Redis CPU、Redis 內存使用率、Proxy 占用內存、Proxy GC 次數、最大 RT、Redis 流入流量、Redis 流出流量等。

慢日志：運維平臺支持 Redis-Server 記錄的慢日志和 Redis-proxy 記錄的慢日志查詢。

RDB 離線分析：運維平臺支持生成 RDB 文件，并自動進行數據離線分析。分析結果包含 Top100 Value 最大的 Key 和元素個數最多的 Key；每種類型 Key，不同 Key 前綴包含的 Key 數量等。

圖片

四、監控與告警

自建 Redis 系統接入 APM 監控平臺，提供了各種維度的監控指標和告警功能，及時對異常情況進行預警，當出現問題時，也能幫助快速定位問題。

監控

ECS：CPU、系統 Load、內存、網絡流量、網絡丟包、磁盤 IO 等。

Proxy：QPS、TP999/TP9999/TP100、連接數、CPU、 內存、GC、Goroutine 數量等。

Server：CPU、內存、網絡、連接數、QPS、Key 數量、命中率、訪問 RT等。

告警

自建 Redis 包含大量的告警指標：

• ECS CPU 使用率、內存使用率、系統 Load（5 分鐘平均值）、流量。
• SLB 流量。
• Server、Proxy、ConfigServer 節點宕機。
• 主節點缺失從節點、主節點可用區不一致、主從角色切換。

五、穩定性治理

資源隔離

自建 Redis 目前所有組件都是部署在 ECS 上，為了提高資源利用率節約成本，大部分業務域的 Redis 集群都是混布的。自建 Redis 運維平臺目前管理 ECS 超過數千臺，接入的業務也涵蓋營銷、風控、算法、投放、社區、大數據等等，每個業務的實例等級、QPS、流量等指標各有差異，少數業務 Redis 可能存在突發寫入流量高、Proxy CPU毛刺等現象，可能會引起相同 ECS 上其他實例性能抖動。

按標簽分類：為了方便資源隔離與資源分配時管理，所有 ECS 資源按標簽進行分類管理，針對特殊需求業務、大流量實例、通用資源池等劃分不同的資源標簽，實例部署時選擇合適的標簽、或者頻繁出現告警時調整到對應資源池進行隔離，避免相互影響。

Proxy CPU 限制：為了防止單個 Redis-Proxy 進程搶占過多 CPU 資源，Redis-Proxy 支持配置 Golang GOMAXPROCS 參數來設置單個進程允許使用的最大 CPU 核數。

巡檢

為了提前發現潛在的風險，除了日常告警外，我們支持自動巡檢工具和巡檢信息頁面，建立了定期巡檢機制。

實例綜合得分排名：運維平臺通過分析所有實例關鍵監控指標前一天的峰值，再根據各項指標的權重，每天自動計算所有實例的得分，在巡檢信息頁面進行展示，通過得分排序即可快速發現風險實例。

圖片

ECS 資源大盤：實時展示所有 Redis-Proxy 和 Redis-Server 使用 ECS 的重要指標，通過排序即可快速瀏覽各 ECS 各項重要指標，如 CPU 使用率、內存使用率、IOPS 使用率、磁盤讀取/寫入、上傳/下載帶寬等。

自動巡檢工具：定期檢查所有實例的配置、節點數量等基本信息，對于如從節點缺失、可用區不一致、節點配置不一致等異常情況進行提示。

故障演練

為了提高自建 Redis 系統在異常場景下的可用性、檢驗自建 Redis 系統在各異常場景的恢復時間，我們不定期進行多次故障演練。

故障演練涵蓋所有組件在ECS、網絡、磁盤等出現故障的場景，以及多個組件組合同時出現這些故障的場景。

經過故障演練檢驗，自建 Redis 系統 Redis-Server 主節點故障恢復時間 12s，Redis-Proxy 故障業務恢復時間 5s 內。

六、總結

本文詳細介紹了自建 Redis 架構和現有一些重要特性，我們還在持續不斷地迭代優化和豐富支持的特性，為我們的業務提供一個功能更強大、性能更優異的分布式緩存系統。未來我們還會迭代的方向可能包括且不限于：

• 目前 Redis-Server 為了兼容云上版本和分布式架構做了很多定制化，所以未使用最新社區版本，未來會升級到最新的社區版本如 7.0。
• 熱 Key 訪問一直是 Redis 使用中對業務影響較大的一個問題，未來我們考慮支持熱 Key 統計與讀熱 Key 本地緩存。
• Golang 版本 Proxy 在高 QPS 請求時，GC 是性能提升的一個瓶頸，未來考慮使用 Rust 重構 Proxy。