一、背景和概況
在2015年末，為了解決各類業務大量的排行榜的需求，我們基于redis實現了一個通用的排行榜服務，良好解決了各類業務的痛點，但是隨著業務發展到2016年中，其中一個業務就申請了數百萬排行榜，并隨著增長趨勢，破千萬指日可待，同時各業務也希望能直接使用redis豐富數據結構來解決更多問題(如存儲關關系鏈、地理位置等)。
當時面臨的問題與挑戰如下：
- 排行榜服務無法支撐千萬級排行榜數(排行榜到redis實例映射關系存儲在zookeeper，zookeeper容量瓶頸)
- 單機容量無法滿足關系鏈等業務需求
- 排行榜和關系鏈大部分大于1M，同時存在超大key(>512M)，需支持超大key遷移
- SNG的Grocery存儲組件，支持redis協議，但又存在單key value大小1M的限制
- 高可用，需要支持redis主備自動切換
- SNG數據運維組未提供redis集群版接入服務，在零運維的支持下如何高效治理眾多業務集群？
面對以上挑戰，經過多維度的方案選型對比，最終選擇了基于codis(3.x版本)，結合內部需求和運營環境進行了定制化改造，截止到目前，初步實現了一個支持單機/分布式存儲、平滑擴縮容、超大key遷移、高可用、業務自動化接入調度部署、多維度監控、配置管理、容量管理、運營統計的redis服務平臺，在CMEM、Grocery不能滿足業務需求的場景下，接入了SNG增值產品部等五大部門近30+業務集群(圖一)，350+實例， 2T+容量。
下文將從方案選型、整體架構、自動化接入、數據遷移、高可用、運營實踐等方面詳細介紹我們在生產環境中的實踐情況。
圖一 部分接入業務列表
二、方案選型
Redis因其豐富的數據結構、易用性越來越受到廣大開發者歡迎，根據DB-Engines的最新統計，已經是穩居數據庫產品的top10（見圖一)。云計算服務產商AWS、AZURE、阿里云、騰訊云都提供了Redis產品，各云計算產商主流方案都是基于開源Redis內核做定制化優化，解決Redis不足之處，在提升Redis穩定性、性能的同時最大程度兼容開源Redis。單機主備版各廠商差異不大，都是基于原生Redis內核，但是集群版，AWS使用的原生的Redis自帶的Cluster Mode模式(加強版)，，阿里云基于Proxy、原生Redis內核實現，路由等元存儲數據保存在RDS，架構類似Codis， 騰訊云集群版是基于內部Grocery。了解完云計算產商解決方案，再看業界開源、公司內部，上文提到我們面臨問題之一就是單機容量瓶頸，因此需要一款集群版產品，目前業界開源的主流的Redis集群解決方案有Codis，Redis Cluster，Twemproxy，公司內部的有SNG Grocery、IEG的TRedis，從以下幾個維度進行對比，詳細結果如表一所示(2016年10月時數據)：
圖二 數據庫流行度排名
表一 Redis集群產品對比
云計算產商和業界開源、公司內部的解決方案從整體架構分類，分別是基于Proxy中心節點和無中心節點，在這點上我們更偏愛基于Proxy中心節點架構設計，運維成本更低、更加可控，從存儲引擎分類，分別是基于原生Redis內核和第三方存儲引擎（如Grocery的多階HASH+LinkTable、TRedis的Rocksdb)，在這點上我們更偏愛基于原生Redis內核，因為我們要解決業務場景就是Grocery和CMem無法滿足的地方，我們業務大部分使用的數據結構是ZSET且Key一般超過1M，幾十萬級元素的ZSET Key是常態，Grocery的Value 1M大小限制無法滿足我們的需求，同時我們需要ZSET的ZRank的時間復雜度是O(LogN)，基于RocksDb的存儲引擎時間復雜度是O(N)，因此這也是無法接受的。隨著業務發展，容量勢必會發生變化，因此擴縮容是常態，而TwemProxy并不支持平滑擴縮容，因此也無法滿足要求。最后，我們需要結合內部運營環境和需求做定制化改造，在零運維的支持下，通過技術手段，最大程度自動化治理、運營眾多多業務集群，而Codis代碼結構清晰，開發語言又是現在比較流行的Go，無論是運行性能、還是開發效率都較高效，因此我們最終選擇了Codis.
三、整體架構
基于Codis定制開發而成的Redis服務平臺整體架構如圖二所示，其包含以下組件：
- Proxy：實現了Redis協議，除少數命令不支持外，對外表現和原生Redis一樣。解析請求時，計算key對應的哈希槽，將請求分發到對應的Redis，業務通過L5/CMLB進行尋址。
- Redis： Redis在內存中實現了string/list/hash/set/zset等數據結構，對外提供數據讀寫服務、持久化等，默認一主一備部署。
- DashbOArd：提供管理集群的API和訪問元數據存儲的通用API（CURD操作，屏蔽后端元數據存儲差異）。
- Zk/Etcd/Mysql：第三方元數據存儲，保存集群的proxy、redis、各哈希槽對應的redis 地址等信息。
- HA：基于Redis Sentinel實現Redis主備高可用，部署在多個IDC，采用Quorum機制、狀態機進行主備自動切換。
- Scheduler：調度服務，負責對業務接入申請單進行自動調度部署、集群自動化擴容、各集群運營數據統計等。
- 運維管理系統： Web可視化管理集群，提供業務接入、集群管理、容量管理、配置管理等功能。
- CDB：存儲業務申請單、各節點容量等信息。
- Agent：負責定時監控和采集Redis、Proxy、Dashboard運行統計信息，上報到米格監控系統和CDB。
- HDFS：冷備集群，Redis冷備文件每天會定時上傳到HDFS，提供給業務下載和在主備皆故障的情況下做數據恢復使用。
圖三 整體架構
四、自動化接入
當面對成百上千乃至上萬個Redis實例時，人工根據業務申請單去過濾無效節點、篩選符合業務要求的節點、再從候選節點中找出最優節點等執行一些列繁瑣枯燥流程，這不僅會導致工作乏味、效率低，而且更會大大提升系統的不穩定性，引發運營事故。當繁瑣、復雜的流程變成自動化后，工作就會變得充滿樂趣，圖三是業務接入調度流程，用戶在運維管理系統提單接入后，調度器會定時從CDB中讀取待調度的業務申請單，首先是篩選過濾流程，此流程包含一系列模塊，在設計上是可以動態擴展，目前實現的篩選模塊如下：
Health： 健康探測模塊，過濾宕機、裁測下線的節點IP
Lable：標簽模塊，根據業務申請單匹配部署環境(測試、現網)、部署城市、業務模塊、Redis存儲類型(單機版、分布式存儲版）
Instance： 檢查當前節點上是否有空余的Redis實例(篩選Redis實例時)
Capacity： 檢查當前節點CPU、Memory是否超過安全閥值
Role：檢查當前節點角色是否滿足要求(如Redis實例所屬節點機器必須是Redis Node)，角色分為三類Proxy Node，Redis Node，Dashboard Node
以上篩選模塊，適用Proxy、Redis、Dashboard節點的篩選，在完成以上篩選模塊后，返回的是符合要求的候選節點，對候選節點我們又需要對其評分，從中評出最優節點，目前實現的評分模塊有最小內存調度、最大內存調度、最小CPU調度、隨機調度等。
圖四 業務接入調度流程
通過運行以上一系列篩選和評分模塊后，就可以準確、快速的獲取到新集群的Dashboard、Proxy、Redis的部署節點地址，但是離自動化交付給業務使用還差一個重要環節(部署)。目前主要是通過以下三個方面來解決自動化部署，其一，Codis本身是基于配置文件部署的，每新增一個業務集群必須在配置文件指定集群名字，新建一個PKG包，維護成本非常高，我們通過監聽指定網卡+核心配置項遷移到ZooKeeper，實現配置管理API化，同時部署包標準統一化。其二，在各節點上都會部署Agent，Agent會定時采集上報各節點信息入庫到容量表，無需人工干預，容量管理自動化，未使用的實例形成一個小型資源buffer池。其三，部署是個多階段的流程，需要分解成各狀態，并保證每個狀態都是可重入、冪等性的，當所有狀態完成后，則調度結束，某狀態失敗時，下次調度檢查到申請單非完成狀態，會自動重試失敗的流程，直至完成，拆分后的部署狀態流程圖如圖四所示。
通過以上兩個核心流程，自動化調度分配實例+自動化部署，我們可以將部署時間從最開始的15min+，優化到秒級，在大大提升工作效率的同時，提升了系統穩定性、避免了人為操作錯誤引起的運營事故。
圖五 自動化部署流程
五、數據遷移
擴縮容是存儲系統的常歸化操作，理想中的數據遷移應該是盡量不影響線上業務正常讀寫訪問、支持任意大小的Key、優異的遷移性能、保證遷移前后的數據一致性，但是Codis在2016年末的時候數據遷移功能差強人意。首先是遷移速度慢，其次是只支持同步遷移，較大的Key遷移會阻塞Redis主線程，影響線上業務正常讀寫，最后是不支持超大Key遷移(>512M)。雖然各種最佳實踐不斷強調需要避免大Key，的確大Key可能會是系統潛在的一個風險點(如大key刪除、遷移、熱點訪問等)，但是在不少業務場景下，業務層是無法高效、簡單的完成分Key的，Redis本身也在不斷的優化，降低大Key風險，比如4.0版本提供了異步刪除Key功能，倘若存儲層能快速完成大Key遷移，這不僅會大大簡化業務端的復雜度，更會提升Redis穩定性、可用性，但是內存型存儲系統在大Key遷移的上復雜度比非內存型存儲系統多一個數量級，這也是為什么Redis到現在還未實現大Key遷移和異步遷移的功能。
大Key若能拆分成小Key分批次異步遷移、并在遷移過程中該Key可讀、不可寫，只要遷移速度夠快，這對業務而言是可以接受的，在2016年末的時候我跟Codis核心作者spinlock交流了大key遷移的想法，令人驚喜膜拜的是，他在農歷春節期間就快馬加鞭實現了異步遷移原型，在這過程中我們協助其測試、反饋BUG和瓶頸、不斷改進、優化遷移性能，最終異步遷移不僅支持任意大小Key遷移，而且遷移性能相比同步遷移要快5-6倍，我們也是第一個在線上大規模應用實踐Redis異步遷移的，更令人可喜的是此異步遷移方案擊敗了Redis作者antirez之前計劃的多線程方案，將正式合入Redis 4.2版本。
在介紹異步遷移方案實現前，先介紹下Codis是如何保證過程中數據一致性和為什么同步遷移慢。如何保證遷移過程中各Proxy讀取到的數據一致性？Codis主要遷移流程如圖五所示，其采用了多階段狀態機實現，類似分布式事務中的多階段提交協議，其核心流程如下。
在運維管理系統上，提交遷移指令，Dashboard更新ZooKeeper上哈希槽狀態為待遷移，即返回(時序圖1，2，3步驟)。
Dashboard異步定時檢查ZooKeeper上是否有待遷移狀態的哈希槽，若有則首先進入準備中狀態，Dashboard將此狀態同時分發到所有Proxy，若有異常Proxy應答失敗，則無法進入遷移，狀態回退(時序圖4，5，6，7步驟)。
若所有Proxy應答成功，則進入準備就緒狀態，Dashboard將此狀態同時分發到所有Proxy，Proxy收到此狀態后，訪問此哈希槽中的Key的業務請求將被阻塞等待，若有Proxy應答失敗，則會立刻回退到上個狀態(時序圖8，9，10步驟)。
若所有Proxy應答成功，則進入遷移狀態，Dashboard將此狀態同時分發到所有Proxy，Proxy收到此狀態后，不再阻塞對遷移哈希槽中的Key訪問，若業務請求Key屬于待遷移哈希，首先會從遷移源Redis中讀取數據，寫到目的端Redis中去，然后再獲取/修改數據返回，這是其中一種遷移方式，被動遷移，Dashboard也會發起主動遷移，直至數據遷移結束(時序圖11，12，13，14，15步驟)。
通過多階段的狀態提交和細粒度、ms級別的鎖，Codis優雅的解決了遷移過程中的數據一致性。
圖六 Codis遷移狀態流程圖
圖七 Redis同步遷移流程
再看為什么同步遷移慢，圖七是遷移一個1000萬元素的ZSET耗時分析，當Client發起遷移指令后，源端將整個ZSET序列化成payload花費了10.27s，通過網絡傳輸給目的端Redis花費1.65s，目的端Redis收到數據后，將其反序列化成內存中的數據結構，花費了36.65s，最后源端Redis刪除遷移完成的Key又花費了6.11s，而整個遷移過程中，源端Redis是完全阻塞的，不能提供任何讀寫訪問。因此，異步遷移方案若要提升遷移性能，必須在以上四個流程上面做優化。
異步遷移的流程如圖八所示，面對同步遷移的四個核心點，異步遷移的解決方案如下：
- 拆分rdbSave(encoding)過程，解決同步序列化開銷。對于大key，不再使用rdbSave對數據進行encoding，而是通過指令拆解， redis中的數據結構(list，set，hash，zset)都可以等價的拆分成若干個添加指令，比如含有1000萬元素的zset，可以拆分成10萬個zadd指令，每個zadd指令添加100個數據
- 拆分Restore(network)過程，解決同步IO開銷。異步IO實現，發送數據不再阻塞。
- 拆分rdbLoad(decoding)過程，解決反序列號開銷。因源端發送過來的數據不再是rdb二進制數據，目的端redis無需再使用rdbLoad，只需將收到的添加指令數據直接更新到對應的內存數據結構即可，同時使用了一些trick，比如內存預分配，避免頻繁申請內存，double轉換成long long，提高遷移性能等。
- 異步刪除Key，解決同步刪除Key耗時問題。通過額外的工作線程異步刪除key，不再阻塞redis主線程。
圖八 Redis異步遷移流程
1000萬的ZSET，同步遷移需要54.87s，而異步遷移只需要8.3s，在不阻塞在線業務的前提下，性能提升6倍多，以我們生產環境某全球9000w排行榜為例，之前單機主備版加載到內存都需要20分鐘，而用異步跨機器遷移只需要180s左右， 更詳細的遷移介紹可參看附錄spinlock的Codis新版本特性介紹。
六、高可用
各組件中跟用戶請求相關性很強的組件分別是Proxy、Redis、元數據存儲(ZooKeeper)，相關性較弱的是Dashboard。
Proxy：多機多IDC部署，調度服務會根據IDC ID，自動打散相同proxy，盡量保證同一集群proxy部署在不同IDC，通過L5和CMLB進行容災。
Redis：基于Redis Sentinel進行主備自動化切換。
ZooKeeper：高可用分布式協調服務，一半以上節點存活即可提供服務，同時只有在Proxy啟動時和運行過程中發生數據遷移才會依賴ZooKeeper，絕大部分正常請求不受ZooKeeper 集群狀態影響。
Dashboard： 負責協調集群狀態變更及一致性，目前在設計上是個單點，但是只有在就集群運行過程中發生數據遷移才會依賴它，因此是弱相關性， 后續還可以優化成多節點部署，通過ZooKeeper的分布式鎖來保證只有一個節點能提供服務，當提供服務的節點故障時，通過一系列流程(如需通知Proxy，Dashboard變更等)實現Dashboard自動化故障切換。
重點介紹redis的主備自動切換流程，常見的Master-Slave存儲系統自動切換方案一般有如下三種：
- 基于ZooKeeper來做主備自動切換，如公司內部的TDSQL，在Mysql主備節點上部署Agent，在ZooKeeper集群上注冊臨時節點，當主機宕機時，Scheduler在檢測到臨時節點消失超過閥值后發起容災流程。
- 基于相互獨立的探測Agent實現，如MIG的DCache，IEG的TRedis。IEG TRedis將主備自動切換流程拆分成故障決策模塊（探測Redis存活）、故障同步模塊、故障監控模塊（double check）、故障切換表同步模塊(將待切換的實例放入隊列)、故障核心模塊( 切換路由)。
- 基于Quorum的分布式探測Agent，如Redis的Sentinel，Sentinel在新浪微博等公司已經進行了較大規模應用，Codis也是基于此實現主備自動切換，我們在此基礎上增加了告警和當網絡出現分區時，增加了一個降級操作，避免腦裂，其詳細流程圖八所示。
圖九 Redis主備自動切換流程
圖九流程簡要分析如下：
圖中三個Sentinel部署在不同的可用區，實際現網我們是部署了五個，覆蓋各大運營商IDC等，各Sentinel會定時向master/slave發送ping等請求探測master/slave存活，并通過gossip協議相互交流信息，同時各Proxy實時監聽Sentinel的狀態消息。（圖八1，2流程）
當master出現異常，Sentinel在一定時間(可配置，如2min，避免網絡抖動，誤切)內都持續無法訪問Master時，Sentinel就會認為此節點為主觀故障（S_DOWN），Sentinel會彼此通過gossip協議相互交換信息，當一半以上(可配置)的sentinel認為此master都故障后，此節點會被判斷為客觀故障(O_DOWN)，各Sentinel會選舉出一個Leader來執行主備切換，Leader首先從各備機中選擇一個最佳節點，算法是首選過濾掉與master斷線時間超過閥值的slave，其次優先選擇slave_priority較小的，若priority一樣，則選擇replication offset最大的，若offset也一致，則按字典順序排序選擇最小的runid.選擇出最佳候選master后，Leader會將其提升為master，同時向訂閱者發出+switch-master 事件，通過tnm2/uwork發出L0告警通知開發運維，然后更改其他備機主從關系，從新主機同步數據（圖八3，4，5流程）。
各個Proxy收到Sentinel的+switch-master event后，會遍歷所有sentinel查詢故障組最新master，當一半以上的sentinel返回了故障組新的master，Proxy則會切換路由，路由到組的請求，將發到新的master，主備自動切換完成。（圖八6流程）
但是在極端情況下若網絡出現分區，業務服務、個別Proxy跟Redis Master在同一個可用區，則會出現腦裂，為了避免此種情況，部署在Redis機器上的Agent會定時持續檢測與ZooKeeper連接是否通暢，若連接不上則會向Redis發送降級指令，不可讀寫（圖八7流程）。
七、運營實踐
1.多維度監控
Proxy/Dashboard/Redis機器上的Agent定時采集proxy、redis的qps、connection、memory_used等10幾個指標，上報到米格監控系統，針對核心監控指標配置閥值和波動告警。監控系統在線上數次捕捉到集群異常(如連接數超過閥值、某redis實例無備機等)，及時發出有效告警，提前發現問題、解決問題。同時，也不連VPN的情況下也可以便捷地通過手機快速查看監控曲線、定位問題等，大大提高工作效率。
圖十 Redis Ops曲線
圖十一 master/slave offset差異曲線
2 . 低負載優化
集群縮容和相同業務復用同集群
存儲機多實例部署，現在默認8個實例
通過Agent順序觸發個實例aof rewrite和rdb save，避免多個實例同時fork，從而提高存儲機內存使用率至最高80%
Proxy機器多實例部署(進行中)
3 .多租戶
小業務通過在key前綴增加業務標識，復用相同集群
大業務使用獨立集群，獨立機器
4.數據安全及備份
訪問所有Redis實例都需要鑒權
Proxy層可統計匯總所有寫請求指令
默認開啟AOF日志
定時上報Redis AOF、RDB文件到HDFS集群
八、總結
基于Codis為核心的Redis服務平臺高效解決了SNG大量業務的痛點(不限制Key大小，原生的Redis內核，高性能)，提高了開發效率，助力產品更快發展，但是因人力有限(半個開發投入，在業務項目人力緊張的時候，零投入)，還有若干待完善的地方，如不支持冷熱分離等。 在千呼萬喚中，目前公司內的存儲組自研的CKV+（基于共享內存實現Redis各類數據結構）的單機主從版也終于上線，集群版也在緊鑼密鼓的開發中，CKV+較好的解決了Redis內存使用率、跨IDC部署、數據備份及同步機制的一些不足之處，后續業務也將有更多的選擇！最后感謝antirez，spinlock的無私貢獻！
九、參考資料
Redis Documentation
Github Codis
Github Redis
Codis新版本特性介紹(spinlock)
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：大規模 codis 集群的治理與實踐
本文網址：http://www.guhuozai8.cn/html/solutions/14019321459.html
相關文章
