一、前言

二、規模現狀

三、技術演進介紹

   1. 自建 Redis 系統架構

   2. 接入方式演進

   3. 同城雙活就近讀

   4. Redis-server 版本與能力

   5. 實例架構與規格

   6. proxy 限流

   7. 自動化運維

四、總結

一、前言

自建 Redis 上線 3 年多以來，一直圍繞著技術架構、性能提升、降低成本、自動化運維等方面持續進行技術演進迭代，力求為公司業務提供性能更高、成本更低的分布式緩存集群，通過自動化運維方式提升運維效率。

本文將從接入方式、同城雙活就近讀、Redis-server 版本與能力、實例架構與規格、自動化運維等多個方面分享一下自建 Redis 最新的技術演進。

二、規模現狀

隨著公司業務增長，自建 Redis 管理的 Redis 緩存規模也一直在持續增長，目前自建 Redis 總共管理 1000+集群，內存總規格 160T，10W+數據節點，機器數量數千臺，其中內存規格超過 1T 的大容量集群數十個，單個集群最大訪問 QPS 接近千萬。

圖片

三、技術演進介紹

自建Redis系統架構

下圖為自建Redis系統架構示意圖：

自建 Redis 架構示意圖

自建Redis集群由Redis-server、Redis-proxy、ConfigServer 等核心組件組成。

• Redis-server 為數據存儲組件，支持一主多從，主從多可用區部署，提供高可用、高性能的服務；
• Redis-proxy 為代理組件，業務通過 proxy 可以像使用單點實例一樣訪問 Redis 集群，使用更簡單，并且在Redis-proxy 上提供同區優先就近讀、key 維度或者命令維度限流等高級功能；
• ConfigServer 為負責 Redis 集群高可用的組件。

自建 Redis 接入方式支持通過域名+LB、service、SDK 直連（推薦）等多種方式訪問 Redis 集群。

自建 Redis 系統還包含一個功能完善的自動化運維平臺，其主要功能包括：

• Redis 集群實例從創建、proxy 與 server 擴縮容、到實例下線等全生命周期自動化運維管理能力；
• 業務需求自助申請工單與工單自動化執行；
• 資源（包含 ECS、LB）精細化管理與自動智能分配能力、資源報表統計與展示；
• ECS 資源定期巡檢、自動均衡與節點智能調度；
• 集群大 key、熱 key 等診斷與分析，集群數據自助查詢。

下面將就一些重要的最新技術演進進行詳細介紹。

接入方式演進

自建 Redis 提升穩定性的非常重要的一個技術演進就是自研 DRedis SDK，業務接入自建 Redis 方式從原有通過域名+LB 的方式訪問演進為通過 DRedis SDK 連接 proxy 訪問。

LB接入問題

在自建 Redis 初期，為了方便業務使用，使用方式保持與云 Redis 一致，通過 LB 對 proxy 做負載均衡，業務通過域名（域名綁定集群對應 LB）訪問集群，業務接入簡單，像使用一個單點 Redis 一樣使用集群，并且與云 Redis 配置方式一致，接入成本低。

隨著自建 Redis 規模增長，尤其是大流量業務日漸增多，通過 LB 接入方式的逐漸暴露出很多個問題，部分問題還非常棘手：

• 自建 Redis 使用的單個 LB 流量上限為5Gb，閾值比較小，對于一些大流量業務單個 LB 難以承接其流量，需要綁定多個LB，增加了運維復雜度，而且多個 LB 時可能會出現流量傾斜問題；
• LB組件作為訪問入口，可能會受到網絡異常流量攻擊，導致集群訪問受損；
• 由于Redis訪問均是TCP連接，LB摘流業務會有秒級報錯。

DRedis接入

自建Redis通過自研DRedis SDK，通過SDK直連 proxy，不再強依賴 LB，徹底解決 LB 瓶頸和穩定性風險問題，同時，DRedis SDK 默認優先訪問同可用區 proxy，天然支持同城雙活就近讀。

DRedis SDK系統設計圖如下所示：

圖片

Redis-proxy 啟動并且獲取到集群拓撲信息后，自動注冊到注冊中心；可通過管控白屏化操作向配置中心配置集群使用的 proxy 分組與權重、就近讀規則等信息；DRedis SDK 啟動后，從配置中心獲取到 proxy 分組與權重、就近讀規則，從注冊中心獲取到 proxy 節點信息，然后與對應 proxy 節點建立連接；應用通過 DRedis SDK 訪問數據時，DRedis SDK 通過加權輪詢算法獲取一個 proxy 節點（默認優先同可用區）及對應連接，進行數據訪問。

DRedis SDK并且對原生 RESP 協議進行了增強，添加了一部分自定義協議，支持業務靈活開啟就近讀能力，對于滿足就近讀規則的 key 訪問、或者通過注解指定的就近讀請求，DRedis SDK通過自定義協議信息，通知 proxy 在執行對應請求時，優先訪問同可用區 server 節點。

DRedis SDK 目前支持 Java、Golang、C++（即將上線）三種開發語言。

• Java SDK 基于 Redisson 客戶端二次開發，后續還會新增基于 Jedis 二次開發版本，供業務靈活選擇，并且集成到 fusion 框架中
• Golang SDK 基于 go-Redis v9 進行二次開
• C++ SDK 基于 brpc 二次開發

DRedis 接入優勢

業務通過 DRedis SDK 接入自建 Redis，在穩定性、性能等方面都能得到大幅提升，同時能降低使用成本。

社區某應用升級后，業務 RT 下降明顯，如下圖所示：

圖片

DRedis 接入現狀

DRedis SDK目前在公司內部大部分業務域的應用完成升級。

Java 和 Golang 應用目前接入上線超過300+。

同城雙活就近讀

自建 Redis 同城雙活采用中心寫就近讀的方案實現，可以降低業務多區部署時訪問 Redis RT。

同城雙活就近讀場景下，業務訪問 Redis 時，需要 SDK 優先訪問同可用區proxy，proxy 優先訪問同可用區 server節點，其中proxy優先訪問同區 server 節點由 proxy 實現，但是在自研 DRedis SDK 之前，LB 無法自動識別應用所在同區的 proxy 并自動路由，因此需要借助service 的同區就近路由能力，同城雙活就近讀需要通過容器 proxy+service 接入。

自建 Redis 自研 DRedis SDK 設計之初便考慮了同城雙活就近讀需求，DRedis 訪問 proxy 時，默認優先訪問同區proxy。

service接入問題

目前，自建 Redis server 和 proxy 節點基本都是部署在 ECS 上，并且由于 server 節點主要消耗內存，而 proxy 節點主要消耗 CPU，因此默認采用 proxy + server 節點混部的方式，充分利用機器的 CPU 和內存，降低成本。

而為了支持同城雙活就近讀，需要在容器環境部署 proxy，并創建 service，會帶來如下問題：

• 運維割裂，運維復雜度增加，除了需要運維 ECS 環境部署節點，額外增加了容器環境部署方式。
• 成本增加，容器環境 proxy 需要獨立機器部署，無法與 server 節點混部，造成成本增加。
• RT上升，節點 CPU 更高，從實際使用效果來看，容器環境 proxy 整體的 CPU 和響應 RT 都明顯高于 ECS 環境部署的節點。
• 訪問不均衡，service 接入時，會出現連接和訪問不均衡現象。
• 無法定制化指定僅僅少量特定key 或者 key 前綴、指定請求開啟就近讀。

DRedis接入

自建 Redis 自研 DRedis SDK 設計之初便考慮了同城雙活就近讀需求，DRedis 訪問 proxy 時，默認優先訪問同區proxy；當同可用區可用 proxy 數量小于等于1個時，啟用調用保護，DRedis會主動跨區訪問其他可用區 proxy 節點。

通過service接入方式支持同城雙活就近讀，是需要在 proxy 上統一開啟就近讀配置，開啟后，對全局讀請求均生效，所有讀請求都默認優先同區訪問。

由于 Redis 主從復制為異步復制，主從復制可能存在延遲，理論上在備可用區可能存在讀取到的不是最新數據。

某些特定業務場景下，業務可能在某些場景能夠接受就近讀，但是其他一些場景需要保證強一致性，無法接受就近讀，通過 service 接入方式時無法靈活應對這種場景。

DRedis SDK 提供了兩種方式供這種場景下業務使用：

• 支持指定 key 精確匹配或者 key 前綴匹配的方式，定向啟用就近讀。
• Java 支持通過聲明式注解（@NearRead）指定某次請求采用就近讀；Golang 新增 80 個類似 xxxxNearby 讀命令，支持就近讀。

使用以上兩種方式指定特定請求使用就近讀時，無需 proxy 上統一配置同區優先就近讀。默認情況下，所有讀請求訪問主節點，業務上對 RT 要求高、一致性要求低的請求可以通過以上兩種方式指定優先同區就近讀。

Redis-server版本與能力

在自建Redis 初期，由于業務在前期使用云Redis產品時均是使用Redis4.0 版本，因此自建 Redis 初期也是選擇 Redis4.0 版本作為主版本，隨著 Redis 社區新版本發布，結合當前業界使用的主流版本，自建Redis也新增了 Redis6.2 版本，并且將 Redis6.2 版本作為新集群默認版本。

圖片

不管是 Redis4.0 還是 Redis6.2 版本，均支持了多線程特性、實時熱 key 統計能力、水平擴容異步遷移 slot 能力，存量集群隨著日常資源均衡遷移調度，集群節點版本會自動升級到同版本的最新安裝包。

• 多線程特性

Redis6.2 版本支持 IO 多線程，在 Redis 處理讀寫業務請求數據時使用多線程處理，提高 IO 處理能力，自建 Redis 將多線程能力也移植到了 Redis4.0 版本，測試團隊測試顯示，開啟多線程，讀寫性能提升明顯。

圖片

多線程版本 VS 普通版本

圖片

多線程版本 VS 云產品5.0版本

• 實時熱 key 統計

自建 Redis4.0 和 Redis6.2 版本均支持 Redis 服務端實時熱 key 統計能力，管控臺白屏化展示，方便快速排查熱 key 導致的集群性能問題。方案詳細可閱讀《基于Redis內核的熱key統計實現方案》。

圖片

• 水平擴容異步遷移

自建 Redis 支持水平擴容異步數據遷移，解決大 key 無法遷移或者遷移失敗的穩定性問題，支持多 key 并發遷移，幾億 key 數據在默認配置下水平擴容時間從平均 4 小時縮短到 10 分鐘，性能提升 20 倍，對業務RT影響下降 90% 以上。

圖片

算法某實例 2.5 億 key 水平擴容花費時間和遷移過程對業務 RT 影響

實例架構與規格

Redis單點主備模式

自建 Redis 實例默認均采用集群架構，但是通過 proxy 代理屏蔽集群架構細節，集群架構對業務透明，業務像使用一個單點 Redis 實例一樣使用 Redis 集群。

但是集群架構下，由于底層涉及多個分片，不同 key 可能存在在不同分片，并且隨著水平擴容，key所在分片可能會發生變化，因此，集群架構下，對于一些多 key 命令（如 eval、evalsha、BLPOP等）要求命令中所有 key 必須屬于同一個slot。因此集群架構下，部分命令訪問與單點還是有點差異。

實際使用中，有少數業務由于依賴了一些開源的三方組件，其中可能由于存儲非常少量的數據，所以使用到 Redis 單點主備模式實例，因此，考慮到這種場景，自建 Redis 在集群架構基礎上，也支持了Redis 單點主備模式可供選擇。

一主多從規格

自建 Redis 支持一主多從規格用于跨區容災，提供更快的 HA 效率，當前支持一主一從（默認），一主兩從、一主三從 3 種副本規格，支持配置讀寫分離策略提升系統性能（一主多從規格下，開啟讀寫分離，可以有多個分片承接讀流量）。

一主一從

一主兩從

一主三從

• 一主一從時默認主備可用區各部署一個副本（master在主可用區）
• 一主兩從時默認主可用區部署一主一從，備可用區部署一從副本
• 一主三從時默認主可用區部署一主一從，備可用區部署兩從副本

proxy限流

為了應對異常突發流量導致的業務訪問性能下降，自建 Redis-proxy 支持限流能力。

有部分業務可能存在特殊的已知大key，業務中正常邏輯也不會調用查詢大 key 全量數據命令，如 hgetall、smembers 等，查詢大 key 全量數據會導致節點性能下降，極端情況下會導致節點主從切換，因此，自建Redis 也支持配置命令黑名單，在特定的集群，禁用某些特定的命令。

• 支持 key 維度限流，指定 key 訪問 QPS 閾值
• 支持命令維度限流，指定命令訪問 QPS 閾值
• 支持命令黑名單，添加黑名單后，該實例禁用此命令

自動化運維

自建 Redis 系統還包含一個功能完善的自動化運維平臺，一直以來，自建Redis一直在完善系統自動化運維能力，通過豐富的自動化運維能力，實現集群全生命周期自動化管理，資源管理與智能調度，故障自動恢復等，提高資源利用率、降低成本，提高運維效率。

圖片

• 資源池自動化均衡調度

自建 Redis 資源池支持按內存使用率自動化均衡調度、按內存分配率自動化均衡調度、按 CPU 使用率均衡調度、支持指定機器凌晨遷移調度（隱患機器提前維護）等功能，均衡資源池中所有資源的負載，提高資源利用率。

• 集群自動部署與下線

當業務提交集群申請工單審批通過后，判斷是否支持自建，如符合自建則自動化進行集群部署和部署結果校驗，校驗集群可用性后自動給業務交付集群信息，整個過程高效快速。

業務提交集群下線工單后，自動檢測是否滿足下線條件，比如是否存在訪問連接，如滿足下線條件，則自動釋放 proxy 資源，保留 7 天后自動回收 server 節點資源，在7 天內，如果存在特殊業務仍在使用的情況，還支持快速恢復使用。

• 資源管理

對 ECS 機器資源和 LB 資源進行打標，根據特殊業務需要做不同資源池的隔離調度，支持在集群部署與擴容時，資源自動智能化分配。

• 集群擴縮容

自建 Redis 支持 server 自動垂直擴容，業務申請集群時，可以選擇是否開啟自動擴容，如果開啟自動擴容，當集群內存使用率達到80%時，系統會自動進行垂直擴容，對業務完全無感，快速應對業務容量上漲場景。

ecs-proxy，docker-proxy擴容，server節點的擴縮容也支持工單自動化操作，業務提交工單后，系統自動執行。

• 工單自動化

當前80%以上的運維場景已完成工單自動化，如 Biz 申請、創建實例、密碼申請、權限申請、刪除key、實例升降配，集群下線等均完成工單自動化。業務提單審批通過后自動校驗執行，執行完成后自動發送工單執行結果通知。

• 告警自動化處理

系統會自動檢測機器宕機事件，如發現機器宕機重啟，會自動拉起機器上所有節點，快速恢復故障，提高運維效率。

關于自建 Redis 自動化運維能力提升詳細設計細節，后續會專門分享，敬請期待。

四、總結

本文詳細介紹了自建 Redis 最新技術演進，詳細介紹了自研 DRedis SDK優勢與目前使用現狀，以及 DRedis 在同城雙活就近讀場景下，可以更精細化的控制部分請求采用優先同區就近讀。

介紹了自建 Redis 目前支持最新的 Redis6.2版本，以及在 Redis4.0 和 Redis6.2 版本均支持多線程 IO 能力、實時熱 key 統計能力、水平擴容異步遷移能力。自建 Redis 除了支持集群架構，也支持單點主備架構實例申請，同時支持一主多從副本規格，可以提供可靠性和讀請求能力（讀寫分離場景下）。自建 Redis-proxy 也支持多種限流方式，包括 key 維度、命令維度等。

自建 Redis 自動化運維平臺支持強大的自動化運維能力，提高資源利用率，降低成本，提高運維效率。

自建 Redis 經過長期的技術迭代演進，目前支持的命令和功能上完全對比云 Redis，同時，自建 Redis 擁有其他一些特色的能力與優勢，比如不再依賴LB、支持自動垂直擴容、支持同區優先就近讀等。