本文為CSDN的《程序員》雜志原創(chuàng)文章，下文有修訂和改動(dòng)”。

1、引言

南方企業(yè)一直有過年找老板“逗利是”的習(xí)俗，每年春節(jié)后開工的第一天，騰訊大廈都會(huì)排上長(zhǎng)長(zhǎng)的隊(duì)伍，集體上樓找老板們領(lǐng)紅包。按照廣東習(xí)俗，已經(jīng)結(jié)婚的同事也要給未婚同事發(fā)紅包，這一天騰訊員工就在春茗和尋找紅包中度過。

由此孵化了一個(gè)內(nèi)部項(xiàng)目，通過微信來收發(fā)紅包，把這個(gè)公司全員娛樂活動(dòng)與最活躍的IM平臺(tái)微信結(jié)合起來。最初這個(gè)項(xiàng)目并沒有預(yù)期對(duì)外，但是入口不小心開放后，成為了現(xiàn)象級(jí)產(chǎn)品。2014年開始爆發(fā)性增長(zhǎng)，每年的發(fā)放量都是上一年的若干倍。根據(jù)騰訊公布的數(shù)據(jù)，到2016年春節(jié)，已經(jīng)是每秒十萬次支付，每天近十億訂單的系統(tǒng)。

微信紅包本質(zhì)是小額資金在用戶帳戶流轉(zhuǎn)，有發(fā)、搶、拆三大步驟。在這個(gè)過程中對(duì)事務(wù)有高要求，所以訂單最終要基于傳統(tǒng)的RDBMS，這方面是它的強(qiáng)項(xiàng)，最終訂單的存儲(chǔ)使用互聯(lián)網(wǎng)行業(yè)最通用的MySQL數(shù)據(jù)庫(kù)。支持事務(wù)、成熟穩(wěn)定，我們的團(tuán)隊(duì)在MySQL上有長(zhǎng)期技術(shù)積累。但是傳統(tǒng)數(shù)據(jù)庫(kù)的擴(kuò)展性有局限，需要通過架構(gòu)解決。

補(bǔ)充說明：本文對(duì)應(yīng)的演講PPT詳見《微信紅包數(shù)據(jù)架構(gòu)演變(PPT) [附件下載]》。

技術(shù)交流：

二、分享者

莫曉東：微信支付高級(jí)DBA，擁有豐富的數(shù)據(jù)架構(gòu)和運(yùn)維實(shí)戰(zhàn)經(jīng)驗(yàn)，擅長(zhǎng)大規(guī)模MySQL數(shù)據(jù)庫(kù)集群的架構(gòu)、優(yōu)化和高可用。2010年起在騰訊從事DBA工作，目前專注于微信社交支付的存儲(chǔ)層運(yùn)維和架構(gòu)優(yōu)化。

三、系列文章

? 系列文章目錄：

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》（* 本文）

《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐》

《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》

《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵春節(jié)紅包的設(shè)計(jì)、容災(zāi)、運(yùn)維、架構(gòu)等》

《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對(duì)2020年春節(jié)紅包的技術(shù)實(shí)踐》

《社交軟件紅包技術(shù)解密(十一)：最全解密微信紅包隨機(jī)算法(含演示代碼)》

《社交軟件紅包技術(shù)解密(十二)：解密抖音春節(jié)紅包背后的技術(shù)設(shè)計(jì)與實(shí)踐》

《社交軟件紅包技術(shù)解密(十三)：微信團(tuán)隊(duì)首次揭秘微信紅包算法，為何你搶到的是0.01元》

? 其它相關(guān)文章：

《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》

《QQ 18年：解密8億月活的QQ后臺(tái)服務(wù)接口隔離技術(shù)》

《月活8.89億的超級(jí)IM微信是如何進(jìn)行Android端兼容測(cè)試的》

《開源libco庫(kù)：?jiǎn)螜C(jī)千萬連接、支撐微信8億用戶的后臺(tái)框架基石 [源碼下載]》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(PPT講稿) [附件下載]》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》

《微信海量用戶背后的后臺(tái)系統(tǒng)存儲(chǔ)架構(gòu)(視頻+PPT) [附件下載]》

《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬連接背后的后臺(tái)解決方案》

《微信朋友圈海量技術(shù)之道PPT [附件下載]》

《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》

《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（二）》

《微信“紅包照片”背后的技術(shù)難題》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》

4、前端流量控制

發(fā)十億紅包，難在哪里？

• 1）大量用戶在同一時(shí)間發(fā)搶紅包，瞬間產(chǎn)生每秒數(shù)萬次的請(qǐng)求，除夕可能成百千萬次；
• 2）這個(gè)量級(jí)的請(qǐng)求如果不加以疏導(dǎo)處理直接到達(dá)后臺(tái)，必定會(huì)導(dǎo)致后端服務(wù)過載甚至崩潰。

主要思路是縮短關(guān)鍵業(yè)務(wù)流程，分離可以通過異步、緩存等方式解決的問題，減輕系統(tǒng)壓力，加快響應(yīng)速度，在存儲(chǔ)層前面建上一座大壩。

CGI無狀態(tài)：

接入層無狀態(tài)，邏輯層也無狀態(tài)，可以方便地水平擴(kuò)展。但依賴MySQL事務(wù)保證交易完整，保證紅包系統(tǒng)的精簡(jiǎn)，減少瓶頸的存在。

資源靜態(tài)化：

利用騰訊強(qiáng)大的基礎(chǔ)資源優(yōu)化部署，盡量把動(dòng)態(tài)內(nèi)容轉(zhuǎn)為靜態(tài)資源。靜態(tài)資源和CGI分離，靜態(tài)資源通過CDN就近接入，減少用戶和CGI的交互，減少內(nèi)網(wǎng)、訪問延時(shí)和數(shù)據(jù)請(qǐng)求。

業(yè)務(wù)流程異步化：

微信紅包的發(fā)、搶、拆背后都有多個(gè)內(nèi)部環(huán)境，關(guān)鍵流程精簡(jiǎn)，非關(guān)鍵流程和后續(xù)業(yè)務(wù)邏輯進(jìn)入異步隊(duì)列進(jìn)行處理，減少了用戶的等待時(shí)間，也極大降低了峰值雪崩的概率。繁多的非關(guān)鍵鏈路也不會(huì)影響到主流程。

過載保護(hù)：

前端保護(hù)后端，能在前端處理，就不傳遞到后端：

• 1）前端需要按后端能力做削峰限流；
• 2）客戶端、接入層、邏輯層逐層控制流量；
• 3）前端更容易容錯(cuò)處理，全力保護(hù)存儲(chǔ)層。

微信的過載保護(hù)在客戶端已提前預(yù)埋了策略，在連接失敗或超時(shí)情況下會(huì)有相應(yīng)提示，減少用戶重復(fù)請(qǐng)求次數(shù)。接入層針對(duì)頻繁發(fā)出請(qǐng)求的客戶端限制響應(yīng)速度，并對(duì)系統(tǒng)負(fù)載劃分出若干等級(jí)，達(dá)到不同閾值時(shí)引導(dǎo)客戶端使用不同限速速率；在異常情況出現(xiàn)時(shí)，異步限流降速減輕服務(wù)器端壓力防止過載。

多級(jí)讀緩存：

發(fā)一個(gè)群紅包，搶紅包的請(qǐng)求量遠(yuǎn)大于發(fā)紅包，如果已經(jīng)領(lǐng)過完全可以拒絕。邏輯層增加緩存，類似可以緩存的請(qǐng)求都緩存起來，進(jìn)一步減少存儲(chǔ)層流量。

訂單寫緩存：

訂單系統(tǒng)有很多請(qǐng)求不會(huì)真正完成全流量，創(chuàng)建這些廢單不但浪費(fèi)存儲(chǔ)資源，還會(huì)擠占邏輯層和數(shù)據(jù)層的處理能力，影響其他交易。訂單在完成支付前可以先落在緩存中，完成支付后再持久化。

5、存儲(chǔ)層的高可用設(shè)計(jì)

在數(shù)百倍千倍的業(yè)務(wù)增長(zhǎng)下，存儲(chǔ)層很難簡(jiǎn)單無限擴(kuò)容，一方面設(shè)備成倍增加的成本巨大，另一方面存儲(chǔ)層瓶頸堆積不一定能解決問題。

讀寫分離：

寫請(qǐng)求需要在主機(jī)上，實(shí)時(shí)讀也需要走主機(jī)。有大量對(duì)延時(shí)不那么敏感，又影響性能的查詢，完全可以放到從機(jī)。讀寫分離策略是MySQL分布式的入門，簡(jiǎn)潔地提高了系統(tǒng)容量。

水平切分：

數(shù)據(jù)的水平切分，實(shí)質(zhì)就是分庫(kù)分表；選取一張數(shù)據(jù)表按照主要緯度把數(shù)據(jù)拆分開。實(shí)現(xiàn)存儲(chǔ)層的平行擴(kuò)展。有效降低了單臺(tái)數(shù)據(jù)庫(kù)機(jī)器的負(fù)載，也減小了服務(wù)不可用的可能性。單臺(tái)數(shù)據(jù)庫(kù)宕機(jī)只會(huì)導(dǎo)致部分?jǐn)?shù)據(jù)不能訪問。主要需要考慮路由規(guī)則的選定，方便擴(kuò)縮容以及數(shù)據(jù)的均衡分布。

垂直切分：

數(shù)據(jù)表除了水平切分，行內(nèi)數(shù)據(jù)可以按屬性進(jìn)一步分開。核心表只保留最關(guān)鍵的字段，保證數(shù)據(jù)文件短小緊湊。以紅包為例，昵稱和祝福語這類較長(zhǎng)的信息，不屬于核心數(shù)據(jù)，完全可以切分到別的機(jī)器上，進(jìn)一步提升核心數(shù)據(jù)庫(kù)的容量。不同數(shù)據(jù)適合的存儲(chǔ)類型也不一樣，這類重復(fù)率高的長(zhǎng)字符串更適合NoSQL存儲(chǔ)，對(duì)存儲(chǔ)空間和性能都是節(jié)約極大。

空間換時(shí)間：

按不同維度組織表，比如按訂單屬性和用戶屬性進(jìn)行組織；適應(yīng)不同的請(qǐng)求場(chǎng)景，避免復(fù)雜的查詢。不同維度的表可以通過對(duì)賬對(duì)齊，非核心表可以適當(dāng)冗余，減少多次請(qǐng)求。

鎖的優(yōu)化：

多人爭(zhēng)搶紅包通過數(shù)據(jù)庫(kù)事物來保證，必然存在競(jìng)爭(zhēng)MySQL行鎖。核心事物必須盡量精簡(jiǎn)，避免死鎖。同一個(gè)訂單的所有請(qǐng)求，盡量在邏輯層進(jìn)程預(yù)排隊(duì)后通過一個(gè)連接發(fā)送請(qǐng)求到數(shù)據(jù)庫(kù)。

冷熱分離：

核心數(shù)據(jù)庫(kù)存放高頻數(shù)據(jù)，其他數(shù)據(jù)可以定時(shí)移到成本低的冷數(shù)據(jù)庫(kù)中。這樣可以為核心數(shù)據(jù)庫(kù)使用最好的SSD設(shè)備，快速設(shè)備容量較小較貴，不可能在全量數(shù)據(jù)上使用。同時(shí)可以保證數(shù)據(jù)表的容量不會(huì)一直積累，大表也會(huì)導(dǎo)致性能下降。

6、異地多活

當(dāng)系統(tǒng)足夠大時(shí)，就必須開始考慮異地部署的問題，讓數(shù)據(jù)盡可能離用戶更近。而且進(jìn)一步的高可用不能局限在同一地域，必須跨數(shù)據(jù)中心跨城多活才能抵御系統(tǒng)性風(fēng)險(xiǎn)。因?yàn)榭绯堑膸资撩胙訒r(shí)，微信紅包的異地活動(dòng)設(shè)計(jì)為多數(shù)據(jù)中心相互獨(dú)立。非災(zāi)難灰度不會(huì)將其他數(shù)據(jù)中心的數(shù)據(jù)導(dǎo)入到線上。

就近接入：

以微信紅包系統(tǒng)的異步部署為例，第一個(gè)好處是用戶就近接入，減少跨城的穿越流量。根據(jù)發(fā)送者的地域標(biāo)志數(shù)據(jù)落地到不同數(shù)據(jù)中心，在不同地域?qū)崿F(xiàn)業(yè)務(wù)閉環(huán)。

數(shù)據(jù)分離：

當(dāng)前的網(wǎng)絡(luò)技術(shù)限制，使用光纖也無法保證跨城數(shù)據(jù)的同步延時(shí)問題。所以微信紅包的跨城數(shù)據(jù)中心并不進(jìn)行數(shù)據(jù)實(shí)時(shí)同步。不同區(qū)域各自承載業(yè)務(wù)流量，地域上實(shí)現(xiàn)平衡，各地的訂單數(shù)據(jù)各自獨(dú)立存儲(chǔ)。

異地容災(zāi)：

如果出現(xiàn)地域性故障，我們需要有機(jī)制去保證服務(wù)可用性。有了異步部署，假如深圳出現(xiàn)系統(tǒng)性故障，那么我們可以直接把請(qǐng)求接入上海。各數(shù)據(jù)中心獨(dú)立部署，如果某地系統(tǒng)達(dá)到最大容量，可以進(jìn)行跨地域分流。

7、有損服務(wù)和柔性降級(jí)

我們遇到最多的問題就是海量請(qǐng)求，通過分布式系統(tǒng)來實(shí)現(xiàn)海量請(qǐng)求，根據(jù)CAP理論不能同時(shí)保證一致性和高可用，必須有取舍。我們首先保證可用性，同時(shí)實(shí)現(xiàn)最終一致性。有以下原則。

有損服務(wù)：

要追求高可用性，可以犧牲部分?jǐn)?shù)據(jù)一致性和完整性從而保證核心功能。在資源一定的前提下，滿足用戶的核心需求。微信紅包的核心點(diǎn)是搶、拆紅包，系統(tǒng)必須盡最大可能保證核心步驟流暢，但在瓶頸時(shí)立即降級(jí)防止引起系統(tǒng)雪崩。但是要保證數(shù)據(jù)能最終對(duì)齊，金融屬性的系統(tǒng)數(shù)據(jù)安全硬要求。

柔性可用：

柔性可用是在有損服務(wù)價(jià)值觀支持下的方法，結(jié)合具體場(chǎng)景提供不同級(jí)別的用戶體驗(yàn)，保證盡可能成功返回關(guān)鍵數(shù)據(jù)。把握用戶在每一個(gè)場(chǎng)景中的核心需求，設(shè)計(jì)不同層次滿足核心訴求的辦法。系統(tǒng)首先要實(shí)現(xiàn)容災(zāi)和自動(dòng)切換；其次邏輯資源應(yīng)該隔離；服務(wù)過載時(shí)必須自動(dòng)快速拒絕。

8、結(jié)束語

本文簡(jiǎn)單介紹了微信紅包的存儲(chǔ)層服務(wù)設(shè)計(jì)準(zhǔn)則，在業(yè)務(wù)從起步到小跑再到騰飛的過程中，背后的海量服務(wù)能力將對(duì)其最終成敗有著越來越深遠(yuǎn)的影響。在互聯(lián)網(wǎng)爆發(fā)性增長(zhǎng)中，海量服務(wù)能力決定項(xiàng)目成敗，必須在項(xiàng)目初期就做好海量服務(wù)的準(zhǔn)備。

附錄1：有關(guān)微信、QQ的文章匯總

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《微信團(tuán)隊(duì)分享：微信移動(dòng)端的全文檢索多音字問題解決方案》

《騰訊技術(shù)分享：Android版手機(jī)QQ的緩存監(jiān)控與優(yōu)化實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》

《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《iOS后臺(tái)喚醒實(shí)戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場(chǎng)景》

《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊團(tuán)隊(duì)分享：手機(jī)QQ中的人臉識(shí)別酷炫動(dòng)畫效果實(shí)現(xiàn)詳解》

《騰訊團(tuán)隊(duì)分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》

《微信團(tuán)隊(duì)分享：微信Android版小視頻編碼填過的那些坑》

《微信手機(jī)端的本地?cái)?shù)據(jù)全文檢索優(yōu)化之路》

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

《微信團(tuán)隊(duì)披露：微信界面卡死超級(jí)bug“15。。。。”的來龍去脈》

《QQ 18年：解密8億月活的QQ后臺(tái)服務(wù)接口隔離技術(shù)》

《月活8.89億的超級(jí)IM微信是如何進(jìn)行Android端兼容測(cè)試的》

《以手機(jī)QQ為例探討移動(dòng)端IM中的“輕應(yīng)用”》

《一篇文章get微信開源移動(dòng)端數(shù)據(jù)庫(kù)組件WCDB的一切！》

《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》

《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》

《微信后臺(tái)團(tuán)隊(duì)：微信后臺(tái)異步消息隊(duì)列的優(yōu)化升級(jí)實(shí)踐分享》

《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫(kù)損壞修復(fù)實(shí)踐》

《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》

《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫(kù)，即將開源》

《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開源》

（本文已同步發(fā)布于：http://www.52im.net/thread-2568-1-1.html）