《百億次QQ紅包背后的運維實力》要點：
本文介紹了百億次QQ紅包背后的運維實力，希望對您有用。如果有疑問，可以聯(lián)系我們。

 

作者簡介

周小軍

騰訊SNG社交網(wǎng)絡(luò)運營中心高級運維工程師

資深運維專家,擁有十幾年的IT運維經(jīng)驗,擅長互聯(lián)網(wǎng)網(wǎng)站架構(gòu)、云計算平臺及運維、自動化運維開發(fā)等領(lǐng)域,具有十萬臺級規(guī)模的基礎(chǔ)設(shè)施規(guī)劃及運營能力,騰訊學(xué)院講師. 目前在騰訊社交網(wǎng)絡(luò)運營中心負(fù)責(zé)數(shù)據(jù)運維和接入運維工作.

前言

本文來自于?GOPS 2017 深圳站的演講“從騰訊社交平臺春節(jié)大活動的背后看運維自動化”.

2016年除夕夜,QQ 在線用戶峰值 2.6億,這一晚全球QQ用戶共刷了 72 900 000 000 次紅包.我們好奇什么樣的運維技術(shù)才能撐得住如此巨大的流量沖擊,帶著這個疑問,聽騰訊運維老兵為我們揭開謎底.

一、活動背景

運維有三座大山：大活動、大變更、大故障.這幾個運維場景是最消耗運維人力的.特別是大活動,非常考驗彈性能力,對運維自動化挑戰(zhàn)很大.

我今天所分享的主題就是深入百億次紅包大活動的背后,解析騰訊運維的方法體系,了解織云平臺如何幫助運維實現(xiàn)大活動高效運維,如何減少運維人海戰(zhàn)術(shù).

過年大家都刷過微信紅包和 QQ 紅包,QQ 紅包的業(yè)務(wù)主要有幾種產(chǎn)品形態(tài)：刷一刷紅包、拼手氣紅包、AR紅包和空間紅包等.2016年跨年除夕這天有2.6億的在線用戶刷了729億次的紅包.這么大的體量給整個架構(gòu)體系帶來的沖擊是非常大的.

今天將從”刷一刷紅包”的業(yè)務(wù)架構(gòu)、活動背景、計劃擴容、壓測和演習(xí)、運維策略及活動現(xiàn)場這幾個方面來分享我們的活動型背后的運維支撐工作,希望給大家在產(chǎn)品大活動時提供參考和幫助.

挑戰(zhàn)

大活動前的二個月,產(chǎn)品會給研發(fā)和運維提供詳細(xì)的產(chǎn)品運營指標(biāo),今年春節(jié)前”刷一刷”紅包所規(guī)劃的產(chǎn)品指標(biāo)預(yù)估為峰值每秒800萬,同時活動及節(jié)假日也帶來相關(guān)QQ消息量和空間說說量2-5倍的上漲.

根據(jù)運營指標(biāo),運維按歷史性能數(shù)據(jù)、容量模型和業(yè)務(wù)架構(gòu),評估出春節(jié)活動需要2萬臺虛擬機和3千臺數(shù)據(jù)庫服務(wù)器擴容支撐.

節(jié)前恰好遇到廠商內(nèi)存供貨問題,服務(wù)器供應(yīng)非常緊張,采購比原計劃延期了一個多月.甚至有個別型號的服務(wù)器到春節(jié)封網(wǎng)前一天才到貨.緊張的設(shè)備供給運維增加了擴容壓力.

二、活動計劃

2.1 日歷表

運維有2個月時間來準(zhǔn)備和實施紅包活動,上圖是活動日程表.在確定產(chǎn)品策略和活動方案后,12月進入資源采購流程,元旦前后進入擴容部署.

業(yè)務(wù)擴容有兩周時間,到1月的中旬,也就是離春節(jié)還有2周的時間開始進行業(yè)務(wù)和模塊壓測,以及活動演習(xí)及預(yù)案,大年三十我們開始進入活動現(xiàn)場.

在活動現(xiàn)場,產(chǎn)品、開發(fā)和運維全部在第一線保障紅包,一直堅守到大年初一的凌晨一兩點鐘.

2.2活動梳理

由于活動涉及業(yè)務(wù)多,模塊核心鏈條關(guān)系錯蹤復(fù)雜,運維在前期的活動梳理中,要做好基礎(chǔ)能力、外部服務(wù)壓力和支撐等復(fù)雜的評估準(zhǔn)備工作.

支撐工作梳理包括內(nèi)網(wǎng)專線穿越流量梳理,因為業(yè)務(wù)均為多地部署(深圳、天津和上海),同城也有幾個大的核心IDC,業(yè)務(wù)不僅有同城跨IDC 部署,也有跨城異地部署,評估同城、跨城的專線容量是容量評估重點之一,如果超出閾值有什么應(yīng)急方案,跨城調(diào)度與容災(zāi)怎么做,柔性與過載保護策略等,這些都是運維要考慮的核心保障工作.

三、擴容

3.1 刷一刷紅包架構(gòu)

在分享擴容之前,我先從刷一刷紅包的系統(tǒng)架構(gòu)開始,先讓大家對業(yè)務(wù)進一步的了解.

業(yè)務(wù)架構(gòu)由抽獎系統(tǒng)、消息系統(tǒng)和支付系統(tǒng)三個核心架構(gòu)組成.

• 接入層SSO統(tǒng)一接入：手Q自身系統(tǒng)與客戶端唯一連接.
• 抽獎主邏輯：含抽獎相關(guān)邏輯、數(shù)據(jù)上報等、排行榜、訂單管理等.路由采用L5(自研內(nèi)部路由系統(tǒng)簡稱)的HASH一致性功能,保證同一個用戶的不同請求會落到同一臺機器.
• 存儲：中獎記錄和獎品等信息統(tǒng)一存儲.統(tǒng)一使用公共組件Grocery(自研NoSQL分布式存儲系統(tǒng))進行存儲.
• 禮包發(fā)貨：現(xiàn)金外的其他獎品發(fā)貨,包括公司內(nèi)外業(yè)務(wù)的禮券.
• 公眾號消息：負(fù)責(zé)用戶中獎以及發(fā)貨通知.
• 支付系統(tǒng)：現(xiàn)金和獎品發(fā)貨,還包括后端的銀行接口等.
• CDN 資源：用于獎品圖片信息等資源下載.

根據(jù)這三個層,架構(gòu)分成無狀態(tài)層和有狀態(tài)層,無狀態(tài)層為接入層和邏輯層；有狀態(tài)層即數(shù)據(jù)存儲層,數(shù)據(jù)持久化存儲.

擴容包括無狀態(tài)層和有狀態(tài)層的設(shè)備擴容.

上圖是系統(tǒng)的架構(gòu)圖

3.2 無狀態(tài)服務(wù)自動擴容

3.2.1 傳統(tǒng)擴容流程

下面講一下怎么做無狀態(tài)的擴容,這是傳統(tǒng)的擴容流程,傳統(tǒng)運維的擴容流程一般是通過腳本來部署.我們把流程拆解下,可以看到它主要由以下核心步驟組成,包括部署操作系統(tǒng)、服務(wù)部署、配置下發(fā)、業(yè)務(wù)模塊關(guān)聯(lián)、業(yè)務(wù)代碼包發(fā)布、業(yè)務(wù)權(quán)限管理、啟動服務(wù)、模塊測試、服務(wù)上線和加入監(jiān)控告警.

藍(lán)色圓圈是流程執(zhí)行的時間消耗,這里一臺設(shè)備約消耗半小時.如果擴容一千臺機器需要兩個人/月.如果用腳本或開源運維工具批量的擴容,一個模塊按一人一天,這樣的工作量還是非常繁瑣的,非常依賴人海.

藍(lán)色圓圈是流程執(zhí)行的時間消耗,這里一臺設(shè)備約消耗半小時.如果擴容一千臺機器需要兩個人/月.如果用腳本或開源運維工具批量的擴容,一個模塊按一人一天,這樣的工作量還是非常繁瑣的,非常依賴人海.

藍(lán)色圓圈是流程執(zhí)行的時間消耗,這里一臺設(shè)備約消耗半小時.如果擴容一千臺機器需要兩個人/月.如果用腳本或開源運維工具批量的擴容,一個模塊按一人一天,這樣的工作量還是非常繁瑣的,非常依賴人海.

3.2.2 全自動擴容

在我們強大的織云自動化運維平臺支撐下,我們的業(yè)務(wù)模塊都是一鍵式擴容模式,也稱一鍵上云.一個模塊下的上百臺設(shè)備,整個擴容流程跑完只消耗5分鐘時間.

我們來看一下我們這邊是怎么做的,這是我們基于CMDB的全自動擴容,CMBD 是我們非常核心的擴容系統(tǒng),包括資產(chǎn)、模塊、業(yè)務(wù)對象、軟件包、配置等等的數(shù)據(jù)信息都在這里面.

新部署服務(wù)器從 CMBD 獲取屬性以后,會進入到服務(wù)包的部署,之后到告警屏蔽,下面有發(fā)布自檢,會檢測裝的包是否正常的.然后到業(yè)務(wù)測試,灰度上線,體檢報告.整個流程效率比較高,一般來講部署一臺設(shè)備或一個模塊也就5分鐘,因為它是并發(fā)來做擴容的.織云已經(jīng)把運維操作抽象成幾百個流程.

整個春節(jié)期間走了700多次擴容流程,每天都有上百個業(yè)務(wù)模塊并行,春節(jié)我們擴容了200多個模塊,平均一個模塊是100多臺設(shè)備.

上圖是織云的一鍵上云頁面,左邊是管理列表,右邊是服務(wù)器屬性.包括它屬于哪個模塊,IP是多少,什么機型,運營狀態(tài),操作系統(tǒng),監(jiān)控等等.

當(dāng)我們點擊”新增設(shè)備”按紐,下面就是擴容流程,就會彈出一個界面,會顯示出要擴什么樣的機型,系統(tǒng)支持Docker、虛擬機等等五種類型.下面就是設(shè)備責(zé)任人,IDC等等.點擊發(fā)布完,就會根據(jù)參考IP自動化把擴容批量IP走完整個流程.

剛剛說到我們擴容的最后流程是變更體檢報告,變更體檢報告是變更系統(tǒng)和監(jiān)控系統(tǒng)的融合,依賴于變更系統(tǒng)的變更日志和監(jiān)控系統(tǒng)的監(jiān)控數(shù)據(jù)和監(jiān)控告警.變更系統(tǒng)需要把每次現(xiàn)網(wǎng)變更記錄下來,變更體檢報告根據(jù)這個記錄,取得變更設(shè)備和變更對象列表,然后分析這些變更對象的監(jiān)控數(shù)據(jù),得出最終結(jié)果.

體檢報告的檢測結(jié)果為正常,需關(guān)注,異常.正常表示本次變更正常；需關(guān)注表示此次變更中有一些監(jiān)控指標(biāo)波動比較大,需要相關(guān)人員關(guān)注下,對業(yè)務(wù)本身沒有造成重要影響；異常表示本次變更造成了現(xiàn)網(wǎng)故障,需要立即回滾.正常的體檢報告不發(fā)送任何通知,需關(guān)注的體檢報告發(fā)送郵件通知,異常的體檢報告既發(fā)送郵件也發(fā)送短信通知.

檢查項大體可分為兩類：基礎(chǔ)特性檢查項,業(yè)務(wù)檢查項.

• 基礎(chǔ)特性檢查項是指與機器相關(guān)的監(jiān)控項,如cpu,流量,包量等.
• 業(yè)務(wù)檢查項則是與業(yè)務(wù)相關(guān)的服務(wù)間調(diào)用(簡稱模調(diào)),自動化測試等.

體檢周期為5、10、20、30分鐘.

7個檢查特性包括CPU、網(wǎng)外卡流量、內(nèi)外網(wǎng)卡包量、CPU超過80%的設(shè)備數(shù)、自動化測試告警、模調(diào)告警等,并分別進行評分.評分為0則正常,小于一定值則需要關(guān)注,總分大于一定值為異常.

上圖里面,變更5分鐘,告警數(shù),容量告警、DLP 告警都是零,第10分鐘也是這個告警,到了第20分鐘出現(xiàn)四條模調(diào)告警,就觸發(fā)一條告警信息給運維,運維通過郵件把這個發(fā)給業(yè)務(wù)負(fù)責(zé)人.保證這個變更是閉環(huán),從設(shè)備的申請到發(fā)布自檢到報告都是一個閉環(huán)的流程,這個運維是非常高效的.

剛才說過的傳統(tǒng)的擴容跟織云擴容的對比,傳統(tǒng)擴容基于用 Excel 或 Word 來管理業(yè)務(wù)信息和資源信息,稍進步一點的用數(shù)據(jù)庫來管理.運維要登錄跳板機或總控臺,在總控臺用命令行或頁面跑各種安裝腳本,腳本之間需要人工確認(rèn).

比如說裝一個 MySQL,安裝完成以后要手工把IP、端口等信息粘貼到下一個腳本或流程來由運維繼續(xù)執(zhí)行,腳本間沒有全流程概念,需要人工去更新信息.一個業(yè)務(wù)工程師同時只能做一個模塊的變更或擴容,如果并發(fā)同時做多個變更,極易出錯出現(xiàn)故障.

織云高效的實踐是,它是以運維標(biāo)準(zhǔn)化為基石,以 CMDB 為核心的自動化運維平臺.通過 Web 界面的一鍵式上云,基于業(yè)務(wù)原子任務(wù)和流程引擎,形成一個完整的運維流程,最后并行執(zhí)行.一個模塊一個人5到10分鐘就可以做完所有操作.

高效擴容的背后是基于一套標(biāo)準(zhǔn)化的理念.包括分層標(biāo)準(zhǔn)化、可運維規(guī)范、軟件標(biāo)準(zhǔn)化,并且標(biāo)準(zhǔn)化以 CMDB 落地.

我們以 CMDB 為核心,把資產(chǎn)配置、硬件配置、軟件配置、運營配置,比如說這個IP是在哪個地方部署的,因為我們有容災(zāi),還有權(quán)限的管理,我們模組之間有管理,把這些配置都打包到 CMDB 里面,通過引擎實現(xiàn)自動化發(fā)布機制.到線上服務(wù)以后,后面還會有監(jiān)控告警、一致性、變更體檢等等閉環(huán)的服務(wù).從 CMDB 到線上服務(wù),整個流程都是閉環(huán)的.

這是運維標(biāo)準(zhǔn)化的實踐.把架構(gòu)、配置、監(jiān)控、軟件包、工具等等先實現(xiàn)標(biāo)準(zhǔn)化,然后落實到 CMDB 配置中心,通過工具或流程快速交付.標(biāo)準(zhǔn)化是要落地,如果沒有這些跟 CMDB 的實踐,標(biāo)準(zhǔn)化就是一個紙面的東西,是沒有辦法實現(xiàn)的,這四步缺一不可.

3.3 有狀態(tài)層的自動擴容

剛才講到無狀態(tài)的擴容,現(xiàn)在是講有狀態(tài)的數(shù)據(jù)層擴容.通常來講,數(shù)據(jù)層擴容是 DBA 工作中工作量最大、最易出故障的變更.但在我們這邊,數(shù)據(jù)層擴容已經(jīng)實現(xiàn)了與無狀態(tài)層一樣的靈活性.

我們的數(shù)據(jù)層分兩層架構(gòu),上層是無狀態(tài)接入機,負(fù)責(zé)數(shù)據(jù)路由配置,下層是存儲機,負(fù)責(zé)數(shù)據(jù)存儲.

接入機擴容跟無狀態(tài)層的擴容方法類似.

存儲層通過數(shù)據(jù)搬遷,同時并行修改接入機路由表來實現(xiàn)擴容.

存儲層擴容的原理是,我們首先把記錄 KEY HASH 1萬到桶,桶再分配到存儲機的存儲單元,通常是 1GB 一個內(nèi)存存儲單元,一臺 64GB 內(nèi)存的存儲機有56個存儲單元.

桶是搬遷最小單元,通過桶搬遷方式來實現(xiàn)記錄的擴縮容,整個桶搬遷是全自動化,運維只要指定一臺或一批目標(biāo)存儲機,桶和記錄就會自動搬遷分布到目標(biāo)存儲機之上,搬遷過程中代理機的路由表是實時更新的,因此搬遷過程中業(yè)務(wù)的訪問不受任何影響,只是搬遷過程中的KEY不能刪除,但這個過程只有數(shù)秒時間,業(yè)務(wù)基本無感知.

上圖是數(shù)據(jù)層的架構(gòu),存儲層分內(nèi)存存儲和固態(tài)盤存儲二級,數(shù)據(jù)可以自動根據(jù)冷熱規(guī)則在內(nèi)存和存儲之間分布,以節(jié)省內(nèi)存成本.目前我們共有2萬多臺 DB,人均管理兩千多臺 DB,存儲機擴容的效率很高,但由于數(shù)據(jù)搬遷速度較慢,通常是一臺 64GB 內(nèi)存的內(nèi)存存儲機在生產(chǎn)環(huán)境下需要1小時完成搬遷,因此3千臺 DB 花了兩三周時間來完成擴容.

四、壓測和演習(xí)

運維擺脫了設(shè)備擴容的人海戰(zhàn)術(shù)后,就像特種部隊一樣,把精力聚焦到有價值的工作中,譬如業(yè)務(wù)架構(gòu)評審、資源評估和規(guī)劃,壓測及演習(xí)、應(yīng)急預(yù)案、監(jiān)控等等和業(yè)務(wù)相關(guān)的事情,這是業(yè)務(wù)運維應(yīng)該更關(guān)注的地方.

4.1 紅包容量評估

如何評估活動容量?我們會根據(jù)四個維度來評估容量.首先是IDC 的容量,像電力、機柜、專線的容量等等.以服務(wù)器為維度,會關(guān)注四個核心指標(biāo),CPU、網(wǎng)絡(luò)的磁盤IO、網(wǎng)卡流量、網(wǎng)卡包量,判斷這個設(shè)備的整體容量水平.這是基礎(chǔ)的維度.

業(yè)務(wù)這邊,我們會有業(yè)務(wù)維度的評估,譬如紅包業(yè)務(wù)的每秒紅包容量.根據(jù)設(shè)備的能力來推導(dǎo)出業(yè)務(wù)容量的水平,譬如模塊單機能抗3千個 QPS,假設(shè)模塊下有一百臺設(shè)備,那么該模塊的 QPS 就能支撐30萬 QPS,并且這個容量負(fù)載必須是線性的增長.

4.2 紅包壓測

容量完成擴容前后,我們會多次對模塊和業(yè)務(wù)進行壓測,來評估容量基準(zhǔn)值,擴容之后的水位能否支持到業(yè)務(wù)高峰.

我們通過演習(xí)的方式來模擬實際的用戶請求.

我們的業(yè)務(wù)是多地部署的,譬如 QQ 是分布到深圳、上海和天津三地.那么,我們把全國流量調(diào)度到其中一地,譬如深圳,觀察容量、延遲等指標(biāo),因為我們業(yè)務(wù)關(guān)鍵鏈路會有幾十個模塊,在這個過程中,有些模塊如果有問題會出現(xiàn)異常或告警,比如說有些模塊 CPU 會過熱,會上到 80%-90% 的高水位,或者失敗率開始增加.業(yè)務(wù)會根據(jù)這些模塊的容量,根據(jù)高負(fù)荷的模塊做一些性能的優(yōu)化或擴容.保證這些模塊負(fù)載都是合理范圍.

第二部分是線上灰度,我們會逐漸放開搶紅包的活動,譬如對華南區(qū)域的用戶放開”刷一刷紅包”的入口,用戶有提示先去刷,刷的時候發(fā)現(xiàn)這個產(chǎn)品的測試是否符合預(yù)期,關(guān)鍵模塊的容量是不是達(dá)到我們的標(biāo)準(zhǔn).我們會有灰度逐步放量,最后全部放量.還有一個小年夜的多時段,比如說在晚上定點來分別放開”刷一刷”這個活動的流量.

這是有一個壓測出問題的例子,我們在壓測的時候發(fā)現(xiàn)有一些存儲機的網(wǎng)卡流量被壓爆了,這是一臺網(wǎng)卡流量的巔峰,平時是 200-300Mb 的水平,到了壓測的時候壓滿 1Gb 的帶寬.我們分析發(fā)現(xiàn),這個是存儲器上有熱 KEY,然后我們根據(jù)壓測出的情況繼續(xù)推動各種優(yōu)化.

4.3 紅包演習(xí)

上圖是紅包演習(xí)的范例,我們把手Q的深圳 IDC 1000 萬用戶調(diào)到天津去,以模擬深圳的IDC掛后天津的壓力.運維日常以及節(jié)假日前會通過各種調(diào)度來做各種演習(xí).

五、運維策略

5.1 業(yè)務(wù)錯峰部署

業(yè)務(wù)策略多變,之前評估供給的設(shè)備不一定能滿足實際產(chǎn)品指標(biāo),因此我們還做了業(yè)務(wù)錯峰部署,在一批服務(wù)器上同時部署了紅包和空間的服務(wù),一臺機器會部署兩套服務(wù).在紅包活動時這些設(shè)備用于紅包活動,紅包活動結(jié)束后,通過調(diào)度快速把機器調(diào)度到空間服務(wù)進程上,這樣錯峰來重用服務(wù)器計算資源.

大家可能會覺得這種切換風(fēng)險比較高,后來經(jīng)過我們的驗證,我們的調(diào)度能力還是確保這些多設(shè)備的復(fù)用達(dá)到我們的預(yù)期.我們通過技術(shù)的方式來做,即可以做到業(yè)務(wù)錯峰,也可以進行擴容.

5.2 柔性保護

在活動過程中還有很多服務(wù)故障,我們還需要對服務(wù)的柔性做一些測驗.我把我們”刷一刷紅包”分層,針對每個層出現(xiàn)的問題做一切特殊的過載保護.比如說QQ用戶,如果8點準(zhǔn)點開放給用戶,同時會有2億的用戶涌入這個架構(gòu),系統(tǒng)的峰值會非常高.

在用戶層我們做了錯峰的開放,譬如在20：00到05分把用戶隨機放進來,把請求隨機分布在300秒?yún)^(qū)間.

如果接入層這邊出現(xiàn)容量和負(fù)載過高,我們會在這里隨機丟棄一些請求,根據(jù)用戶UIN的HASH進行隨機丟包.

如果是銀行這邊的接口出現(xiàn)瓶頸,我們會降低現(xiàn)金的的派發(fā)速度等等.消息系統(tǒng)出現(xiàn)瓶頸,我們會設(shè)置一定比例的用戶不發(fā)送消息.每一個層都會跟研發(fā)一起考慮這個容量出現(xiàn)問題的時候怎么做柔性保護

這是我們運維這邊一鍵下發(fā)屬性的界面(見PPT),我們可以選擇不同的模塊,然后選擇柔性的配置表,通過一鍵下發(fā)的方式將柔性策略實時下發(fā),并實時生效.

六、活動現(xiàn)場

6.1 看監(jiān)控

前面的擴容、壓測和應(yīng)急預(yù)案等已經(jīng)做完了,到了春節(jié)活動現(xiàn)場,運維主要有三類工作,一是看現(xiàn)場視圖,二是擴容過熱模塊,三是處理熱KEY.

有些業(yè)務(wù)模塊,通過壓測手段是沒有辦法模擬現(xiàn)網(wǎng)的,在現(xiàn)網(wǎng)情況下會出現(xiàn)容量超過閾值的情況.運維會通過視圖或告警快速發(fā)現(xiàn),經(jīng)過簡單評估后從備用資源池中緊急提取設(shè)備,對模塊進行擴容,把容量負(fù)載降到正常水位.

這是大年30運維部門的現(xiàn)場(見PPT),大家都在看視圖和快速擴容模塊,這是我們運維主要做的事情.

上力量是織云的運維核心視圖(見PPT),可以看到集成了各業(yè)務(wù)核心視圖,包括紅包大盤、紅包相關(guān)模塊告警,QQ 核心模塊容量,紅包視圖等等,運維主要是看這些視圖,看告警來保證活動是正常的.

6.2 現(xiàn)場挑戰(zhàn)-熱KEY

數(shù)據(jù)存儲在活動高峰面臨的挑戰(zhàn)之一是熱 KEY.即某一些熱點記錄的訪問量過大,高峰期甚至上漲百倍.

我們有幾種常用方法來處理熱KEY.首先是拆記錄,比如說這個記錄的訪問量非常大,每秒有十幾萬,我們會把 KEY 的 Value 分拆成多份,分布到不同的表實例.

其二是限制記錄的長度,有些 KEY 的 Value 很長,在熱點訪問時會給存儲機內(nèi)存拷貝、網(wǎng)卡造成壓力.我們會查找出過長的 KEY-Value,讓業(yè)務(wù)通過字段壓縮、刪除冗余字段等方式來減少記錄長度.

第三是把千兆的存儲機換成萬兆的存儲機,讓網(wǎng)卡流量突破1Gb限制,在現(xiàn)網(wǎng)萬兆存儲機能跑到 5-6Gb 的水平.

第四是記錄打散,快速通過搬遷方式,把集中的熱點 KEY 分布到十幾臺存儲機來支撐.

最后,業(yè)務(wù)在前端可能會有幾十臺邏輯設(shè)備,業(yè)務(wù)可在邏輯設(shè)備上用內(nèi)存做前端緩存,減少對后端存儲機的訪問.

七、回顧

回顧整個紅包的活動策略,萬臺級設(shè)備擴容僅用了2天時間,極大解救了運維.運維從擴縮容的工作量中解脫出來后,可以把更多的時間和精力更深入理解業(yè)務(wù),為業(yè)務(wù)在質(zhì)量、成本和速度幾個方面給用戶提供更多的價值,為業(yè)務(wù)保駕護航.

原文來自微信公眾號：高效運維

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/2710.html