降本增效 百TB級Redis自動化運維體系建設

　　 一、背景介紹

　　疫情三年對全球經濟造成了巨大沖擊，許多公司的業務量大幅下滑，旅遊業更是遭受了重創。在這樣的大環境下，公司為了降低運營成本，不得不採取一系列措施來縮減開支。其中，對於 DBA 這種運維團隊來說，降低成本最直接的方法就是減少機器的開銷。

　　在疫情期間，由於公司機票、酒店、火車票等核心業務流量的大幅減少， Redis 這種快取伺服器的記憶體使用量也驟然降低。於是，公司決定整合伺服器資源，對 Redis 叢集進行縮容降配，將多個例項集中部署到較少的機器上，從而騰出一部分空閒的伺服器進行下線處理。據統計，疫情期間下線的機器約佔 Redis 總資源的 30% 左右，這一舉措大大降低了公司的運營成本。

　　然而，隨著疫情得到控制，旅遊業開始快速復甦。到 2023 年春節期間，流量已經基本恢復到疫情前的水平。Redis 資源的使用率大幅增加，但伺服器的擴充速度卻遠遠跟不上業務增長的速度。尤其是在春節這樣的高峰期，導致伺服器剩餘可用資源和負載頻繁報警，給運維工作和服務穩定性帶來了巨大的壓力和挑戰。

　　為了應對這一現狀，自動化運維工具成為了緩解壓力的必要手段。透過開發和升級自動化平臺，DBA 可以更加高效地管理大量的資料庫伺服器，減少人工干預和錯誤率，從而更好地應對與日俱增的 Redis 需求和流量。　　

　　1.Redis 使用現狀

　　去哪兒網 Redis 目前部署在 IDC 機房，採用物理機進行單機多例項的主從混和部署，規模 百TB 級別，主從例項數 15000+ 。從疫情至今，例項數增長超過 50% ，記憶體佔用總量超過 60% 。

　　2.面臨的挑戰和問題

　　流量快速上漲：整體記憶體用量快速增長，Redis 請求量增加，CPU 負載告警頻繁。

　　業務上雲：物理距離增加，網路延時變大，業務訪問 Redis 超時變多。

　　業務容器化：業務容器化之後，機器數變多，Redis 連線數頻繁告警，存在打滿的風險。

　　業內機房故障：近兩年，業內多次出現的機房級別故障，造成重大損失，給我們敲響了警鐘，需要反思自己維護的服務是否真正具備跨機房容災的能力。

　　 二、去哪兒網 Redis 自動化運維體系

　　在介紹運維體系之前，首先了解我們的 Redis 叢集架構。

　　1.Redis 叢集架構　　

　　去哪兒網 Redis 叢集是一個分散式的高可用架構，整個架構主要由以下幾個重要部分組成：

　　Redis Server 節點：每個節點有一主一從兩個例項，多個節點組成一份完整的叢集資料，其中每個節點只有主庫對外提供服務，從庫僅僅用於節點高可用、資料持久化及定時備份。

　　Zookeeper 叢集：由五個zk節點組成，儲存Redis叢集名，每個叢集對應一個znode，用於Redis叢集配置變更後，通知客戶端進行重連。

　　Redis Sentinel 叢集：由五個 Sentinel 節點組成，用於 Reids Server 節點的高可用，主從切換、故障轉移、配置更新等。

　　配置中心：由五個 MySQL 節點組成的 PXC 叢集，用於儲存 Redis 叢集的分片資訊，即每個節點的 Master 例項資訊及分配 key 的一致性 hash 值範圍。

　　應用程式客戶端：配置叢集名和 zookeeper 地址，監聽 znode 變化，透過叢集名從配置中心獲取 Redis 拓撲結構。

　　2.Redis 自動化體系　　

　　我們的 Redis 自動化運維繫統主要由以下幾個功能模組構建而成：

　　1）資源管理

　　Redis資源池管理

　　Redis 機器資源池依託於 OPS 的服務樹，Redis 機器掛在對應的服務樹節點，當有新機器交付時，會在對應服務樹中新增，被資料庫運維平臺識別到，完成初始化後，便可以投入使用。

　　對於 Redis 叢集資源的歸屬，根據訪問機器所屬的業務 appcode 來劃分部門，一般情況下 Redis 資源基本不會跨部門使用，而且訪問的應用相對單一。

　　dbaAgent

　　採集機器資訊，實時更新例項部署情況、資源使用情況，業務連線機器。

　　提供一些運維指令碼，大 key、空閒 key 分析等。

　　提供介面，實現遠端呼叫，本地執行命令完成一系列的自動化流程。

　　在 Redis 叢集部署和遷移等過程中，準確的基礎資訊是不可或缺的。因此，必須確保基礎資訊的準確性，並將其視為其它運維工作的基準。

　　2）叢集部署

　　在 Redis 使用需求不斷增長的背景下，叢集部署是日常最為頻繁的操作。運維的效率在很大程度上依賴於部署工具的穩定性和效能。透過使用我們自主研發的 agent 工具取代之前的 salt-minion ，自動化流程的效能和穩定性得到了顯著提升。這大大減少了人為干預的時間，加快了交付速度，為我們的日常工作減輕了負擔。同時，這也確保了業務能夠快速獲得所需資源，從而保證了業務的連續性和高效性。

　　下圖左邊是自動化部署流程，根據填寫的引數，如叢集名、分片數、分配記憶體、機房選擇等，提交部署任務；提交之後，存入任務佇列等待排程，排程之後便開始部署，在某些情況下任務出錯可進行重試，基本不需要人為介入處理，最後進行資訊回填和交付。

　　右邊是執行部署的步驟，按照定義好的部署規則，依次對叢集的各個模組進行安裝部署。　　

　　部署規則

　　每對主從例項埠相同且唯一。

　　單例項記憶體不大於10G。

　　機器部署例項數低於CPU核心數的1.5倍。

　　機器選擇：使用記憶體不超過總記憶體使用中位數的10%。

　　同叢集在相同機器部署分片數不允許超過3個。

　　3）自動化遷移

　　在日常工作中，我們經常遇到機器故障或升級維護的情況，這時候需要對 Redis 例項進行遷移。另外，隨著業務增長，機器記憶體使用也會相應增加，為了確保有足夠的記憶體提供服務，我們也需要對 Redis 例項進行動態遷移和調整。

　　基於日常運維需求，我們的遷移平臺支援以下幾種遷移模式，滿足日常各場景的維護工作，遷移的規則仍然依照部署的規則實施，確保部署和使用的規範性：

　　① 單例項遷移

　　單個 Redis 分片點對點的遷移，從機器 A 遷移至 B ，遷移的節點為從節點，如果遇到主節點，需要先進行切換。

　　② 多例項遷移

　　多例項遷移故名思義是由一個個獨立的單例項組合而成，用於不同的運維場景，多例項的場景下，儘可能的分散機器遷移，提升遷移的並行度，減少等待時間。多例項遷移主要用於以下幾個場景：

　　③ 機器資源均衡遷移

　　在資源有限的情況下，面對業務線日益增長的需求，Redis資源超賣是不可避免的，必須採取一些有效措施來應對資源超賣引發的問題。疫情恢復初期，Redis記憶體分配總量超過了總機器記憶體的150%，業務高峰期時，不少機器記憶體使用大量增長。為了解決這一問題，需要快速調整Redis部署情況，將高使用率機器的例項遷移至使用率相對較低的機器上。當然，自動化程式在選擇遷移目標機器時，也必須遵循部署規則，確保每臺機器部署的Redis和使用情況保持相對均衡。

　　④ 叢集遷移

　　按照叢集維度叢集遷移，主要用於跨機房/跨雲改造。由於近期業內機房級別的故障頻發，公司對於服務跨機房/跨雲容災相當重視，因此對於原先未按照跨機房部署的叢集進行遷移改造，實現多機房部署。雲主機對於我們來說，可看作一個新的機房，實現Redis叢集的雲容災，將從庫部署遷移至雲主機即可。當然，雲主機若要提供服務，延遲自會比本地機房大，這又是另外一個值得討論的問題了。

　　⑤ 整機遷移

　　針對於機器故障、機器維護、升級、替換等場景，需要對單臺機器的所以例項進行遷移，遷移前需要將機器的所以主例項切換為從節點，一鍵生成遷移任務；故障遷移場景區別於主動維護，機器故障後，故障機器對外服務的主節點由哨兵觸發切換，自動化程式需要找到故障機器切換後的節點，這依賴於我們基礎資訊的維護與實時更新機制，能夠正確找到對應節點，在不同機器上部署從庫即可。

　　具體遷移流程如下，與叢集部署類似，填入引數後即可發起遷移任務，等待任務佇列進行排程；右圖為編排好的自動化遷移流程，按照傳入的引數順序執行，完成單個例項的遷移過程。　　

　　4）叢集擴縮容

　　Redis 是一個高效能的記憶體資料儲存系統，能夠隨著業務需求的變化而靈活地調整記憶體和流量負載。在疫情期間，為了降低成本，我們採取了縮容降配和下線操作。然而，隨著疫情的恢復和業務的快速增長，我們需要進行擴容以應對更高的需求。

　　去哪兒網使用的 Redis 叢集架構與原生 Redis 叢集有所不同，它採用客戶端分片的方式。因此，對於這種架構來說，擴縮容相對困難，無法像原生 Redis 叢集那樣透過簡單地新增新節點和重新分配資料槽位來實現。為了解決這個問題，我們採取了資料遷移的方法。

　　具體操作步驟如下：首先，將現有叢集的資料遷移到新的待擴縮容的叢集中；然後，交換新老叢集的名稱，以實現最終的擴縮容。這種方法有效且穩定，確保了資料的完整性和服務的連續性。

　　客戶端分片

　　去哪兒網的 Redis 叢集採用 hash 演算法對資料進行分片儲存。與原生 Redis 不同，它需要使用特定的客戶端。在讀寫資料時，客戶端會先計算出 key 的 hash 值，採用的是 murmurhash2 演算法，hash 範圍在 0～2**32 之間。根據叢集配置中心的拓撲資訊，客戶端能夠確定資料所在的分片，然後連線對應的分片進行讀寫操作。這一設計使得資料能夠在叢集中均勻分佈，提高系統的擴充套件性和可用性。Redis 配置資訊如下圖所示：　　

　　如何建立Redis連線

　　前文提及的去哪兒網 Redis 架構中，客戶端透過 zookeeper 叢集監聽對應叢集的 znode 資訊，並從訪問配置中心資料庫獲取叢集拓撲資訊，進而連線到 Redis 分片。當 Redis 叢集拓撲結構發生變化時，哨兵、自動化平臺等會觸發對應叢集的 znode-dversion 變化，進而使客戶端感知到並重新獲取叢集拓撲結構和重建連線。

　　RedisGate

　　RedisGate 是基於 Redis 原始碼改造，作為去哪兒網 Redis 叢集擴縮容的中介軟體角色，主要作用如下：

　　作為源端叢集的從庫，同步源叢集的資料。

　　作為目的端叢集的主庫，儲存目的端叢集的拓撲資訊；按照客戶端分片演算法，將資料分發到目的端叢集的各個分片，實現新老叢集資料同步，從而達到擴縮容的效果。

　　擴縮容架構如下：　　

　　程式碼實現如下：　　

　　擴縮容切換

　　使用 RedisGate 中介軟體實現源和目的端增量同步後，即可進行資料校驗，比對源和目的端的資料一致性。可從兩個維度進行比對，一是看源和目的 Key 的數量，但如果主庫資料過期時間較短，因為 Redis 的惰性刪除，往往會導致差異較大；此時可進行抽樣對比，scan、randomkey 等，抽取部分 key-value 進行比對。從原理上看，我們的擴縮容架構等同於 Redis 的級聯複製，因此同步延遲可等同 Redis 的主從級聯複製。

　　當資料達到增量同步後，需要考慮如何在業務不做任何變更的情況下，做到無損的切換到新叢集。前文提到的高可用切換依賴於 zookeeper，當叢集拓撲結構發生變化時，會更新 znode 的 dversion ，因此在擴容切換時，先是交換配置中心源和目的的叢集名（即修改源叢集的拓撲結構），然後觸發 znode 變更，從而通知客戶端重新獲取叢集拓撲結構，重建連線。擴容切換，可類比一次叢集的主從切換，對業務來說，需進行一次重連。經過上千次線上環境的實踐，方案可行性和穩定性已得到驗證，切換過程對於業務可以做到幾乎無感知。

　　自動化流程

　　從新建叢集、建立 RedisGate 資料同步、清理遷移環境等，整個流程已在平臺實現自動化，僅在觸發切換動作時，需人為介入點選確認，同時通知業務線完成擴縮容。

　　5）Redis巡檢系統

　　在提升系統穩定性方面，除日常的運維操作需遵循規範外，風險的預知也至關重要。為提前發現潛在風險，需要依賴於日常對線上服務的巡檢。我們的巡檢系統資料來源於監控系統和 agent 採集的資料。

　　透過例項、叢集、機器等多個維度，對各項指標進行採集和分析，如果達到我們預設的風險值，即將問題暴露出來，需進行進一步的分析處理。雖然日常告警也能揭示一些問題，但往往達到告警閾值時，故障可能已經發生。

　　因此，透過設定更低的閾值和進行更全面的分析，可以有效預防 Redis 叢集可能出現的各種問題。這樣，系統穩定性得到了進一步增強，確保了服務的連續性和可用性。

　　下圖展示了去哪兒 Redis 巡檢系統的相關流程及巡檢指標：　　

　　 三、總結與展望

　　以上詳述了去哪兒網 DBA 團隊如何使用和維護 Redis 叢集，並直面遇到的各種挑戰。透過自動化手段，我們實現了許多日常運維操作的規範化和標準化，如部署、遷移、擴縮容等。整個過程幾乎無需人工干預，從而顯著減輕了 DBA 的負擔，真正地達到了降本增效的目標。此外，自動化程式取代了人工操作，使得線上變更流程更為統一規範，消除了人為的不確定性，進而提升了 Redis 服務的整體穩定性。

　　儘管自動化為我們減輕了大量負擔，但仍面臨諸多挑戰。在我們公司，幾乎所有業務已順利遷移至雲端或具備隨時彈性上雲的能力，但部分敏感業務由於無法容忍雲端到本地機房的延遲，這便要求我們解決 Redis 的跨雲部署和就近訪問的問題。這是我們當前需要攻克的難題。

　　隨著 AI 技術的迅猛發展和廣泛應用，資料庫運維領域也需緊跟時代步伐。透過運用機器學習和人工智慧技術，我們可以實現更智慧的 Redis 監控和維護。儘管我們的巡檢系統已能提前發現潛在問題，但進一步的深度分析和處理仍需人工介入。為此，我們渴望利用 AI 技術，實現在風險被識別時即刻進行最佳化和自愈，這是我們對未來的憧憬，也是我們未來的工作重心。