作者介紹
雷孝龍， 去哪兒網資深DBA。2019年8月加入去哪兒網，負責公司的MySQL/Redis運維，以及自動化方案的設計與實施。曾就職於達夢資料庫、映客直播；擅長於資料庫管理、維護及最佳化等工作。
（文末有本期內容的直播回放&PPT獲取方式，不要錯過哦~）
分享概要
一、背景介紹
1.Redis使用現狀
2.面臨的挑戰和問題
二、去哪兒網Redis自動化運維體系
1.資源管理
2.集群部署
3.自動化遷移
三、總結與展望
一、背景介紹
疫情三年對全球經濟造成了巨大沖擊，許多公司的業務量大幅下滑，旅遊業更是遭受了重創。在這樣的大環境下，公司為了降低營運成本，不得不采取一系列措施來縮減開支。其中，對於 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 技術，實作在風險被辨識時即刻進行最佳化和自愈，這是我們對未來的憧憬，也是我們未來的工作重心。
來源丨公眾號：Qunar技術沙龍（ID：QunarTL）
dbaplus社群歡迎廣大技術人員投稿，投稿信箱：
[email protected]
獲取本期P PT， 請添加群秘微訊號：dbayuqing
↓點這裏 可 回看本期直播
