一、背景和概況
在2015年末,為了解決各類業(yè)務(wù)大量的排行榜的需求,我們基于redis實現(xiàn)了一個通用的排行榜服務(wù),良好解決了各類業(yè)務(wù)的痛點,但是隨著業(yè)務(wù)發(fā)展到2016年中,其中一個業(yè)務(wù)就申請了數(shù)百萬排行榜,并隨著增長趨勢,破千萬指日可待,同時各業(yè)務(wù)也希望能直接使用redis豐富數(shù)據(jù)結(jié)構(gòu)來解決更多問題(如存儲關(guān)關(guān)系鏈、地理位置等)。
當時面臨的問題與挑戰(zhàn)如下:
-
排行榜服務(wù)無法支撐千萬級排行榜數(shù)(排行榜到redis實例映射關(guān)系存儲在zookeeper,zookeeper容量瓶頸)
-
單機容量無法滿足關(guān)系鏈等業(yè)務(wù)需求
-
排行榜和關(guān)系鏈大部分大于1M,同時存在超大key(>512M),需支持超大key遷移
-
SNG的Grocery存儲組件,支持redis協(xié)議,但又存在單key value大小1M的限制
-
SNG數(shù)據(jù)運維組未提供redis集群版接入服務(wù),在零運維的支持下如何高效治理眾多業(yè)務(wù)集群?
面對以上挑戰(zhàn),經(jīng)過多維度的方案選型對比,最終選擇了基于codis(3.x版本),結(jié)合內(nèi)部需求和運營環(huán)境進行了定制化改造,截止到目前,初步實現(xiàn)了一個支持單機/分布式存儲、平滑擴縮容、超大key遷移、高可用、業(yè)務(wù)自動化接入調(diào)度部署、多維度監(jiān)控、配置管理、容量管理、運營統(tǒng)計的redis服務(wù)平臺,在CMEM、Grocery不能滿足業(yè)務(wù)需求的場景下,接入了SNG增值產(chǎn)品部等五大部門近30+業(yè)務(wù)集群(圖一),350+實例, 2T+容量。
下文將從方案選型、整體架構(gòu)、自動化接入、數(shù)據(jù)遷移、高可用、運營實踐等方面詳細介紹我們在生產(chǎn)環(huán)境中的實踐情況。
圖一 部分接入業(yè)務(wù)列表
二、方案選型
Redis因其豐富的數(shù)據(jù)結(jié)構(gòu)、易用性越來越受到廣大開發(fā)者歡迎,根據(jù)DB-Engines的最新統(tǒng)計,已經(jīng)是穩(wěn)居數(shù)據(jù)庫產(chǎn)品的top10(見圖一)。
云計算服務(wù)產(chǎn)商AWS、AZURE、阿里云、騰訊云都提供了Redis產(chǎn)品,各云計算產(chǎn)商主流方案都是基于開源Redis內(nèi)核做定制化優(yōu)化,解決Redis不足之處,在提升Redis穩(wěn)定性、性能的同時最大程度兼容開源Redis。單機主備版各廠商差異不大,都是基于原生Redis內(nèi)核,但是集群版,AWS使用的原生的Redis自帶的Cluster Mode模式(加強版),,阿里云基于Proxy、原生Redis內(nèi)核實現(xiàn),路由等元存儲數(shù)據(jù)保存在RDS,架構(gòu)類似Codis, 騰訊云集群版是基于內(nèi)部Grocery。了解完云計算產(chǎn)商解決方案,再看業(yè)界開源、公司內(nèi)部,上文提到我們面臨問題之一就是單機容量瓶頸,因此需要一款集群版產(chǎn)品,目前業(yè)界開源的主流的Redis集群解決方案有Codis,Redis Cluster,Twemproxy,公司內(nèi)部的有SNG Grocery、IEG的TRedis,從以下幾個維度進行對比,詳細結(jié)果如表一所示(2016年10月時數(shù)據(jù)):

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