本文來自微信團(tuán)隊(duì)工程師張文瑞的技術(shù)分享，由InfoQ編輯發(fā)布，下文有修訂和改動(dòng)。原文地址：infoq.cn/article/1-billion-bonus-from-the-clouds，感謝原作者的分享。
一、引言
與傳統(tǒng)意義上的紅包相比，手機(jī)端的紅包似乎更符合現(xiàn)在年輕一代的習(xí)慣。這其中，以春節(jié)發(fā)紅包最為流行。以微信為例，除夕全天微信用戶紅包總發(fā)送量可以達(dá)到百億個(gè)，紅包峰值收發(fā)量為比百萬個(gè)/秒。
本文將由微信團(tuán)隊(duì)工程師張文瑞分享微信春節(jié)搖一搖紅包技術(shù)背后的方方面面，希望能給同行們帶來啟發(fā)。
技術(shù)交流：
二、分享者
張文瑞：微信高級工程師，微信接入系統(tǒng)負(fù)責(zé)人。一直從事后臺系統(tǒng)設(shè)計(jì)開發(fā)，早期涉足傳統(tǒng)行業(yè)軟件，后投身互聯(lián)網(wǎng)。作為微信最早的后臺開發(fā)之一，見證了微信從零開始到逐漸發(fā)展壯大的過程。
王鵬程：微信支付商戶系統(tǒng)開發(fā)組組長，專家工程師。2008 年加入騰訊，6 年的電商經(jīng)驗(yàn)，做過 c2c、b2b2c、b2c 及 erp，2 年第三方支付開發(fā)經(jīng)驗(yàn)。
張文瑞還分享了微信其它方面的技術(shù)文章，您也可能感興趣：
三、系列文章
? 系列文章目錄：
? 其它相關(guān)文章：
四、搖一搖紅包系統(tǒng)組成
紅包系統(tǒng)由三部分組成：
- 1）信息流；
- 2）業(yè)務(wù)流；
- 3）資金流。
這三部分在組織架構(gòu)上由不同的后臺團(tuán)隊(duì)完成：
- 1）信息流——微信后臺；
- 2）業(yè)務(wù)流——微信支付后臺；
- 3）資金流——財(cái)付通后臺。
在平時(shí)，紅包系統(tǒng)主要處理個(gè)人會話中以消息形式發(fā)出的紅包，其中：
- 1）信息流主要包括用戶操作背后的請求通信和紅包消息在不同用戶和群中的流轉(zhuǎn)；
- 2）業(yè)務(wù)流是用戶請求引發(fā)的包紅包、搶紅包和拆紅包等的業(yè)務(wù)邏輯；
- 3）資金流則是紅包背后的資金轉(zhuǎn)賬和入賬等流程。
微信紅包系統(tǒng)在春節(jié)除夕活動(dòng)時(shí)和平時(shí)的實(shí)現(xiàn)不大一樣。在除夕活動(dòng)時(shí)，除了個(gè)人紅包外，紅包系統(tǒng)還要處理由后臺通過搖一搖集中下發(fā)的大量企業(yè)紅包。這里邊信息流的實(shí)現(xiàn)變化較大。
接下來簡單介紹一下 2016 年除夕活動(dòng)時(shí)的紅包系統(tǒng)架構(gòu)。
如上圖所示，搖一搖紅包系統(tǒng)架構(gòu)包括三個(gè)方面：
資源預(yù)下載：
在除夕，用戶通過搖一搖參與活動(dòng)，可以搖到紅包或其他活動(dòng)頁，這些頁面需要用到很多圖片、視頻或 H5 頁面等資源。在活動(dòng)期間，參與用戶多，對資源的請求量很大，如果都通過實(shí)時(shí)在線訪問，服務(wù)器的網(wǎng)絡(luò)帶寬會面臨巨大壓力，基本無法支撐；另外，資源的尺寸比較大，下載到手機(jī)需要較長時(shí)間，用戶體驗(yàn)也會很差。因此，我們采用預(yù)先下載的方式，在活動(dòng)開始前幾天把資源推送給客戶端，客戶端在需要使用時(shí)直接從本地加載。
搖 / 拆紅包：
除夕的搖一搖子系統(tǒng)是專門為活動(dòng)定制的，按時(shí)間軸進(jìn)行各項(xiàng)活動(dòng)，這里邊最重要、同時(shí)也是請求量最大的是搖紅包。從需求上看，系統(tǒng)需要完成兩個(gè)事：用戶可以通過搖一搖搶到紅包，紅包金額可以入到用戶的支付賬戶。在除夕，系統(tǒng)需要在很短時(shí)間內(nèi)將幾十億個(gè)紅包發(fā)放下去，對性能和可用性要求很高。考慮到涉及資金的業(yè)務(wù)邏輯比較復(fù)雜，還有很多數(shù)據(jù)庫事務(wù)處理，耗時(shí)會比較長，于是我們將搶紅包（信息流）和紅包的賬務(wù)邏輯（業(yè)務(wù)流和資金流）異步化。將前一部分處理流程盡可能設(shè)計(jì)得輕量，讓用戶可以很快搶到紅包，然后再異步完成剩下的賬務(wù)邏輯。
那么，搶紅包階段是怎樣做到既輕量又可靠呢？
1）零 RPC 調(diào)用：
在微信后臺系統(tǒng)中，一般情況下客戶端發(fā)起的請求都是通過接入服務(wù)轉(zhuǎn)發(fā)給具體的業(yè)務(wù)服務(wù)處理的，會產(chǎn)生 RPC 調(diào)用。但對于搖一搖請求，我們將搖一搖邏輯直接嵌入接入服務(wù)中，接入服務(wù)可以直接處理搖一搖請求，派發(fā)紅包。
2）零數(shù)據(jù)庫存儲：
按一般的系統(tǒng)實(shí)現(xiàn)，用戶看到的紅包在系統(tǒng)中是數(shù)據(jù)庫中的數(shù)據(jù)記錄，搶紅包就是找出可用的紅包記錄，將該記錄標(biāo)識為屬于某個(gè)用戶。在這種實(shí)現(xiàn)里，數(shù)據(jù)庫是系統(tǒng)的瓶頸和主要成本開銷。我們在這一過程完全不使用數(shù)據(jù)庫，可以達(dá)到幾個(gè)數(shù)量級的性能提升，同時(shí)可靠性有了更好的保障。
- 1）支付系統(tǒng)將所有需要下發(fā)的紅包生成紅包票據(jù)文件 ;
- 2）將紅包票據(jù)文件拆分后放到每一個(gè)接入服務(wù)實(shí)例中；
- 3）接收到客戶端發(fā)起搖一搖請求后，接入服務(wù)里的搖一搖邏輯拿出一個(gè)紅包票據(jù)，在本地生成一個(gè)跟用戶綁定的加密票據(jù)，下發(fā)給客戶端；
- 4）客戶端拿加密票據(jù)到后臺拆紅包，后臺的紅包簡化服務(wù)通過本地計(jì)算即可驗(yàn)證紅包，完成搶紅包過程。
3）異步化：
用戶搶到紅包后不會同步進(jìn)行后續(xù)的賬務(wù)處理，請求會被放入紅包異步隊(duì)列，再通過異步隊(duì)列轉(zhuǎn)給微信支付后臺，由微信支付后臺完成后續(xù)業(yè)務(wù)邏輯。
五、大規(guī)模集群中保證數(shù)據(jù)一致性
事實(shí)上網(wǎng)絡(luò)分裂很難從根本上避免，我們在設(shè)計(jì)系統(tǒng)時(shí)都是假設(shè)網(wǎng)絡(luò)分裂一定會出現(xiàn)，基于此思考應(yīng)該采用什么方案保障系統(tǒng)在網(wǎng)絡(luò)分裂時(shí)能正常運(yùn)作。
我們的方案是在每個(gè)數(shù)據(jù)中心都建設(shè)三個(gè)獨(dú)立的數(shù)據(jù)園區(qū)，可以做到在任意一個(gè)數(shù)據(jù)園區(qū)出現(xiàn)網(wǎng)絡(luò)分裂等故障，甚至徹底變成園區(qū)孤島后，另外兩個(gè)數(shù)據(jù)園區(qū)可以無損承接整個(gè)數(shù)據(jù)中心的請求。
三園區(qū)容災(zāi)的關(guān)鍵就是數(shù)據(jù)一致性：我們需要做到在分裂出去的那個(gè)數(shù)據(jù)園區(qū)的數(shù)據(jù)在其他園區(qū)有個(gè)強(qiáng)一致的副本，這樣請求落到其他兩個(gè)園區(qū)后，可以無損完成服務(wù)。
此外在故障園區(qū)恢復(fù)后，數(shù)據(jù)在所有園區(qū)還能自動(dòng)保持強(qiáng)一致。
微信后臺實(shí)現(xiàn)了基于 Quorum 算法，對數(shù)據(jù)有強(qiáng)一致性保證的存儲系統(tǒng)——KvSvr（這一存儲系統(tǒng)，詳見：《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》、《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（二）》）。
此外還有可以提供三園區(qū)強(qiáng)一致保證的可靠異步隊(duì)列，這次就應(yīng)用在這個(gè)紅包系統(tǒng)中。前邊提到的部署在接入服務(wù)的紅包文件實(shí)際上也是可以實(shí)現(xiàn)三園區(qū)容災(zāi)的，我們在每臺接入服務(wù)部署的紅包文件都會在其他數(shù)據(jù)園區(qū)有個(gè)備份。在某個(gè)數(shù)據(jù)園區(qū)故障時(shí)，我們可以在其他數(shù)據(jù)園區(qū)發(fā)放故障園區(qū)的紅包。
通常活動(dòng)紅包總量非常大，活動(dòng)形式也更豐富，我們會在以下方面做優(yōu)化。
1）服務(wù)性能：
為提升各個(gè)服務(wù)模塊的處理性能，我們通過壓測和 Profiler 分析，發(fā)現(xiàn)了不少性能瓶頸點(diǎn)，做了大量優(yōu)化。
2）業(yè)務(wù)支撐能力：
支持更加復(fù)雜的業(yè)務(wù)場景，并在客戶端和服務(wù)器都加入了很多可以后期靈活調(diào)整的預(yù)埋能力，以更好地服務(wù)產(chǎn)品運(yùn)營。
3）可用性：
不斷提升系統(tǒng)可用性是我們一直努力的目標(biāo)，以下 5 點(diǎn)很好地提高了系統(tǒng)的可用性。
[3.1] 系統(tǒng)容量評估與配額
對系統(tǒng)的容量需要有個(gè)準(zhǔn)確的評估與驗(yàn)證，并結(jié)合業(yè)務(wù)設(shè)計(jì)合理的配額方案和降級方案，盡可能保障系統(tǒng)不會過載。例如，我們評估并驗(yàn)證完系統(tǒng)每秒最大拆紅包量后，就可以在處理用戶搖一搖請求時(shí)，限制系統(tǒng)每秒最大發(fā)放紅包配額，這就間接保證了拆紅包量不會超出處理能力。
[3.2] 過載保護(hù)
服務(wù)如果出現(xiàn)過載了，必須有能力自保，不被壓垮，并且不擴(kuò)散到系統(tǒng)其他的服務(wù)。我們在后臺的服務(wù)框架層面具備通用的過載保護(hù)能力：服務(wù)如果處理不過來，就按請求的優(yōu)先級盡快丟掉超出處理能力的請求，保證服務(wù)的有效輸出；上游調(diào)用端在部分服務(wù)實(shí)例過載時(shí)，能自動(dòng)做負(fù)載均衡調(diào)整，將請求調(diào)整到負(fù)載較低的服務(wù)實(shí)例中；上游調(diào)用端發(fā)現(xiàn)大部分服務(wù)實(shí)例都出現(xiàn)過載，也可以主動(dòng)丟掉部分請求，減輕后端服務(wù)器的負(fù)擔(dān)。
[3.3] 減少關(guān)鍵路徑
減少核心用戶體驗(yàn)所涉及的步驟和模塊，集中力量保證關(guān)鍵路徑的可用性，從而在整體上提高可用性。我們把活動(dòng)紅包的信息流和業(yè)務(wù)流進(jìn)行異步化，就是基于這個(gè)考慮。跟用戶核心體驗(yàn)相關(guān)的搶紅包操作，在信息流中的接入服務(wù)、紅包簡化邏輯服務(wù)和紅包異步隊(duì)列（入隊(duì)）這三個(gè)服務(wù)模塊參與下即可完成。這三個(gè)服務(wù)模塊是可以比較容易用較低成本就做到高可用的，可以較好地規(guī)避業(yè)務(wù)流和資金流中幾十甚至上百個(gè)服務(wù)模塊可能出現(xiàn)的風(fēng)險(xiǎn)。
[3.4] 監(jiān)控指標(biāo)
我們需要對系統(tǒng)的真實(shí)負(fù)載情況有準(zhǔn)確及時(shí)的了解，就必須要有一套高效、可靠的監(jiān)控系統(tǒng)，同時(shí)還要有一套有效的監(jiān)控指標(biāo)，監(jiān)控指標(biāo)不是越多越好，太多了反而會影響判斷，必須要有能準(zhǔn)確反映問題的幾個(gè)核心指標(biāo)。在我們系統(tǒng)里，這些核心指標(biāo)一般在基礎(chǔ)框架集成，根據(jù)經(jīng)驗(yàn)來看，其中一個(gè)很有用的指標(biāo)是服務(wù)的最終系統(tǒng)失敗。
我們把服務(wù)的失敗分為兩類：邏輯失敗和系統(tǒng)失敗。系統(tǒng)失敗一般是服務(wù)暫時(shí)不可用導(dǎo)致，是可通過重試來自動(dòng)解決的，如果請求重試若干次仍然為系統(tǒng)失敗，就產(chǎn)生最終系統(tǒng)失敗。通過最終系統(tǒng)失敗通常可以快速定位到異常的服務(wù)，及時(shí)進(jìn)行處置。
[3.5] 人工介入
我們在紅包系統(tǒng)內(nèi)預(yù)置了很多配置開關(guān)，當(dāng)自動(dòng)運(yùn)作的過載保護(hù)無法發(fā)揮預(yù)期作用時(shí)，可以通過人工介入，使用這些保底的手動(dòng)開關(guān)迅速降低負(fù)載、恢復(fù)服務(wù)。
六、技術(shù)創(chuàng)新
實(shí)際上，類似的這種活動(dòng)用到的技術(shù)都是現(xiàn)成的，并不復(fù)雜。但為什么大家會覺得很難實(shí)現(xiàn)呢？
主要是因?yàn)橐?guī)模：用戶和請求的并發(fā)規(guī)模越大，就越難在系統(tǒng)的成本和可用性上達(dá)到平衡，也就是說越難實(shí)現(xiàn)一個(gè)低運(yùn)營成本、高服務(wù)可用性的系統(tǒng)。
在傳統(tǒng)的應(yīng)對這種有很大規(guī)模用戶參與的活動(dòng)的實(shí)現(xiàn)方案里，一般會采用在客戶端過濾請求，以某種概率（基于時(shí)間或互動(dòng)次數(shù)）發(fā)到服務(wù)器進(jìn)行處理，這樣服務(wù)器的壓力可以大幅降低。
我們認(rèn)為還可以做得更好，在這種活動(dòng)的技術(shù)方案上可以有所突破——在保持低成本的前提下，全量處理用戶的每次交互。這就大大降低了客戶端的實(shí)現(xiàn)風(fēng)險(xiǎn)（因?yàn)榭蛻舳说母潞透采w周期相對較長）。此外，服務(wù)器有了對用戶交互有了全面的控制能力和靈活調(diào)整的能力。
這些能力對活動(dòng)的運(yùn)營是非常可貴的。可以讓我們在活動(dòng)過程中，各種復(fù)雜用戶場景下，都能做到精細(xì)的調(diào)整，給了產(chǎn)品運(yùn)營很大的靈活性，以保證活動(dòng)效果和用戶體驗(yàn)。看看下面兩個(gè)例子。
我們可以精確控制和調(diào)整每次用戶交互出現(xiàn)什么結(jié)果，曝光哪個(gè)贊助商；
活動(dòng)過程中，有個(gè)很難預(yù)估的因素——參與人數(shù)。說不準(zhǔn)參與的用戶少了（或互動(dòng)次數(shù)少了），導(dǎo)致紅包很久都發(fā)不完？或者參與的用戶多了（或互動(dòng)次數(shù)多了），導(dǎo)致需要加快發(fā)放速度，更快速發(fā)完紅包？
于是我們對這個(gè)技術(shù)方案做了全面的思考和設(shè)計(jì)，最終實(shí)現(xiàn)了現(xiàn)在這個(gè)系統(tǒng)，可以用很低的成本實(shí)現(xiàn)極高的性能和可用性，在除夕活動(dòng)中得到了成功的應(yīng)用。
七、服務(wù)降級方案
我們曾經(jīng)對搖一搖 / 朋友圈紅包照片在 2016.1.26 的預(yù)熱活動(dòng)和 2016.2.7 的正式活動(dòng)都做了詳細(xì)的復(fù)盤。包括活動(dòng)過程中各項(xiàng)業(yè)務(wù)數(shù)據(jù)是否符合預(yù)期，各個(gè)模塊的表現(xiàn)是否符合預(yù)期等，并分析各種不符合預(yù)期表現(xiàn)的成因和解決措施。
在紅包系統(tǒng)的信息流、業(yè)務(wù)流和資金流都有很多保障用戶核心體驗(yàn)的降級方案。舉幾個(gè)信息流的降級方案的例子。
a） 如果某一個(gè)數(shù)據(jù)園區(qū)出現(xiàn)網(wǎng)絡(luò)分裂等故障，完全不可用了，部署在那里的紅包怎么發(fā)下去？
紅包文件雖然在園區(qū)間有冗余存儲，但基于性能和可用性考慮，我們并不打算在各園區(qū)間維護(hù)強(qiáng)一致的紅包發(fā)放記錄，做到記錄級的“斷點(diǎn)續(xù)發(fā)”，而是將紅包文件按時(shí)段進(jìn)行切分，降級為只做文件級的“斷點(diǎn)續(xù)發(fā)”。在某個(gè)園區(qū)不可用時(shí)，使用降級方案后，故障園區(qū)當(dāng)前發(fā)放時(shí)段的紅包文件不會接著發(fā)放，僅保證下一時(shí)段的紅包能通過其他園區(qū)正常發(fā)出去。
b）活動(dòng)過程中，如果用戶的交互量超過服務(wù)的處理能力了怎么辦？
正如前面所述，我們很難準(zhǔn)確估計(jì)參與用戶量及互動(dòng)次數(shù)。就本次活動(dòng)而言，在系統(tǒng)設(shè)計(jì)之初，我們評估有 2000 萬次 / 秒的峰值請求，并在系統(tǒng)最終實(shí)現(xiàn)和部署時(shí)預(yù)留了一定的余量，提供了評估值 2.5 倍（也就是 5000 萬次 / 秒峰值請求）的系統(tǒng)處理能力，除夕當(dāng)晚服務(wù)器處理請求峰值達(dá)到 2500 萬次 / 秒，服務(wù)實(shí)際負(fù)載低于 50%。但如果當(dāng)時(shí)用戶過多，互動(dòng)過于火爆，到達(dá)后臺的請求超過 5000 萬次 / 秒，系統(tǒng)就會進(jìn)入降級模式，客戶端可以在服務(wù)器的控制下，減少請求，防止服務(wù)器過載。
c）紅包發(fā)放速度過快，后端處理不過來怎么辦？
正如前面所述，用戶搶紅包是在信息流完成的，完成后請求放到紅包異步隊(duì)列再轉(zhuǎn)到業(yè)務(wù)流。如果領(lǐng)取紅包請求量過大，隊(duì)列會出現(xiàn)積壓，紅包的入賬會出現(xiàn)延時(shí)，但不會導(dǎo)致用戶請求失敗。
類似的降級方案還有很多，每個(gè)環(huán)節(jié)都有若干個(gè)不同的降級方案，有些是針對業(yè)務(wù)專門設(shè)計(jì)的（如 a 和 b），還有些是使用基礎(chǔ)組件 / 服務(wù) / 方案本身就具備的降級能力（如 c）。這些方案都遵循著一個(gè)原則：降級時(shí)，盡可能保證用戶的核心體驗(yàn)。
八、資金與紅包準(zhǔn)備的難點(diǎn)
除夕活動(dòng)資金和紅包準(zhǔn)備的難點(diǎn)總體來說有以下 4 點(diǎn)。
1）紅包的數(shù)量：
- a. 由于招商的不確定性，最終投入微信搖企業(yè)紅包的資金不可準(zhǔn)確預(yù)估；
- b. 不同的商戶其對品牌的曝光量的需求不同，有的要求多曝光，有的要求多關(guān)注，紅包金額或大或小，數(shù)量則或多或少；
- c. 從準(zhǔn)備到除夕當(dāng)天，期間各種變化，活動(dòng)方案變數(shù)很多。
紅包的數(shù)量可能從幾億到幾百億變化，資金與紅包的準(zhǔn)備需要能夠滿足需求的巨大變化。
2）資金的就位:
- a. 企業(yè)各行各業(yè)，營銷經(jīng)費(fèi)的審批流程不盡相同，資金最終支付到位時(shí)間前后差異很大，甚至有些在除夕前一周才會最終敲定支付到賬；
- b. 某些企業(yè)可能在最后階段停止合作；
- c. 某些企業(yè)可能在最后階段調(diào)整資金的使用方式。
以上情況會導(dǎo)致資金的到位時(shí)間不完全可控，本著盡可能多的資金能夠投入到活動(dòng)中的原則，希望可以盡可能壓縮活動(dòng)的準(zhǔn)備時(shí)間，讓更多的資金能夠上車。
3）資金預(yù)算的配置方案（資金劇本）：
- a. 按設(shè)想的活動(dòng)方案，紅包會分為三大類：圖片紅包、視頻紅包、品牌 logo 紅包。活動(dòng)方案較去年又有新的變化，特別是 logo 紅包的認(rèn)知度和接受度不確定，logo 紅包過度會否導(dǎo)致未領(lǐng)完而浪費(fèi)資金，不容易確定 logo 紅包的資金占比；
- b. 除夕當(dāng)天的活動(dòng)劇本可能會反復(fù)調(diào)整優(yōu)化，紅包時(shí)段的劃分可能修改，不同時(shí)段的資金投放量可能變化。
大筆資金、大量的紅包、復(fù)雜的活動(dòng)方案、善變的商戶要求，都可能反復(fù)調(diào)整，如果面對百億量級的紅包配置調(diào)整時(shí)，技術(shù)上如何實(shí)現(xiàn)縮短準(zhǔn)備時(shí)間，支持方便的變化。
4）資金的安全：
- a. 如何防止紅包的金額被篡改；
- b. 如何防止未被領(lǐng)取的紅包被入賬給用戶；
- c. 如何防止紅包金額重復(fù)入賬給用戶；
- d. 如何防止機(jī)器被攻破產(chǎn)生了不存在的紅包；
- e. 如何防止紅包被不同用戶重復(fù)領(lǐng)取；
- f. 如何在確保資金安全的情況下盡可能保證用戶的到賬體驗(yàn)（最好是實(shí)時(shí)或準(zhǔn)實(shí)時(shí)到賬）。
技術(shù)上必須做萬無一失的準(zhǔn)備，確保資金足夠安全，活動(dòng)順利完成。
九、微信搖企業(yè)紅包全過程
如果在除夕當(dāng)天搖的過程中按前邊提到的超級復(fù)雜的配置方案即時(shí)生成隨機(jī)紅包，這顯然是風(fēng)險(xiǎn)齊高邏輯奇復(fù)雜的。對待只許成功不許失敗的項(xiàng)目，主流程必須極簡高效，所以這里全部的資金和紅包數(shù)量都需要按方案規(guī)則提前切分和準(zhǔn)備好。
將預(yù)生成好的紅包數(shù)據(jù)（預(yù)紅包數(shù)據(jù)）進(jìn)行準(zhǔn)確的部署，搖紅包的資金和紅包準(zhǔn)備的整體流程方案有兩個(gè)選擇。
方案一：預(yù)紅包數(shù)據(jù)提供部署給微信的接入機(jī)和寫入紅包 DB，搖紅包過程由紅包接入機(jī)控制紅包的發(fā)放，拆紅包時(shí)修改紅包 DB 中的紅包數(shù)據(jù)；
方案二：預(yù)紅包數(shù)據(jù)只提供部署給微信接入機(jī)，搖紅包過程由紅包接入機(jī)控制紅包的發(fā)放，拆紅包直接 Insert 到紅包 DB。
第二個(gè)方案減少一次 DB 操作，如果是百億量級的紅包數(shù)據(jù)，可以極大減少數(shù)據(jù)導(dǎo)入、對賬等活動(dòng)準(zhǔn)備時(shí)間，特別是方案需要變更時(shí)。
十、充足準(zhǔn)備
10.1對資金預(yù)算和資金劇本進(jìn)行合理的建模
首先，面對如此大量的資金和復(fù)雜的資金劇本，如何準(zhǔn)確高效地管理和控制邏輯呢？要杜絕傻大黑粗，我們需要一個(gè)優(yōu)雅的解決方案——建模。
對資金預(yù)算和資金劇本進(jìn)行合理的建模，讓模型涵蓋、掌管、控制一切——讓工具基于模型進(jìn)行自動(dòng)化的處理和校驗(yàn)。
這里需要做的就是：
- 1）落地該模型的設(shè)計(jì)，讓一切圍著模型轉(zhuǎn)；
- 2）按規(guī)定的格式文件導(dǎo)入預(yù)算和配置，并進(jìn)行數(shù)據(jù)和邏輯合理性校驗(yàn)；
- 3）一切利用工具進(jìn)行處理，資金的支付、退款、紅包的隨機(jī)生成和多商戶隨機(jī)打散、預(yù)紅包文件分割、預(yù)紅包數(shù)據(jù)的校驗(yàn)，減少人為過程導(dǎo)致的潛在失誤；
- 4）優(yōu)化紅包隨機(jī)算法和文件處理方法，將紅包隨機(jī)分割和多商戶隨機(jī)打散算法的 n^2 時(shí)間復(fù)雜度優(yōu)化 n，壓測 30 億紅包的生成時(shí)間為 2~3 小時(shí)，極大縮減準(zhǔn)備時(shí)間，增加方案調(diào)整的回旋時(shí)間，可以讓更多的資金上車。
其次，前邊提到方案有如此多的變數(shù)、調(diào)整、變更，如何支持？還是回歸模型，建模時(shí)就要考慮支持同樣的預(yù)算多套資金配置方案。
同樣的資金預(yù)算，同時(shí)或依次生成多套預(yù)紅包數(shù)據(jù)文件，提前做多手準(zhǔn)備，方便方案變更。
再次，如此大量的資金就意味著如此大量的誘惑，會不會出問題呢？
- 1）方案預(yù)紅包數(shù)據(jù)未提前落地 DB，導(dǎo)致拆紅包時(shí)缺少一次紅包數(shù)據(jù)有效性的檢驗(yàn)；
- 2）預(yù)紅包數(shù)據(jù)存放在微信接入機(jī)上，存在被攻陷獲取或篡改的可能；
- 3）紅包數(shù)據(jù)在傳輸?shù)倪^程中存在系統(tǒng)異常或惡意攻擊，導(dǎo)致數(shù)據(jù)錯(cuò)誤特別是金額錯(cuò)誤的可能；
- 4）系統(tǒng)內(nèi)部可能存在惡意人員直接調(diào)用拆紅包的接口寫入不存在的紅包。
墨菲定律要求我們必須重視以上安全隱患，解決方案就是加密——對預(yù)紅包數(shù)據(jù)進(jìn)行加密，加密庫和解密庫獨(dú)立維護(hù)保證密鑰不被泄漏，通過工具生成預(yù)紅包數(shù)據(jù)時(shí)用密鑰進(jìn)行加密，預(yù)紅包數(shù)據(jù)在部署存儲和傳輸?shù)倪^程中保持加密狀態(tài)，僅在拆紅包的邏輯中編譯二進(jìn)制緊密庫進(jìn)行解密。
同時(shí)，雞蛋也不能放在一個(gè)籃子里，為了控制密鑰泄漏導(dǎo)致的影響，確保資金風(fēng)險(xiǎn)可控，整個(gè)預(yù)生成的紅包數(shù)據(jù)可能分別使用了幾百到幾千個(gè)密鑰進(jìn)行加密，一個(gè)密鑰加密的紅包資金量在 20~30 萬。解密庫還需要能設(shè)置密鑰 ID 的白名單和黑名單，確保未被使用的密鑰不能被利用，確認(rèn)泄漏的密鑰可以進(jìn)行攔截。
10.1極限壓縮
如果是百億個(gè)紅包，那么產(chǎn)生預(yù)紅包數(shù)據(jù)文件的大小不經(jīng)過壓縮是非常恐怖的，傳輸部署幾百 GB 或幾 TB 的數(shù)據(jù)是很艱苦的，一旦發(fā)生調(diào)整變更會變得非常艱難，所以需要對數(shù)據(jù)進(jìn)行極限的壓縮。
數(shù)據(jù)進(jìn)行極限的壓縮的實(shí)施內(nèi)容：
- 1）對于支付單號、商戶號、紅包賬戶等信息，由工具導(dǎo)成配置文件，配置到拆紅包邏輯中，加密的紅包數(shù)據(jù)中僅用一個(gè)批次 ID 表達(dá)；
- 2）拆分紅包 ID，部分分段同樣轉(zhuǎn)為 ID，解密庫解密后利用配置進(jìn)行還原；
- 3）加密部分（Ticket）：紅包 ID、金額、批次 ID、密鑰 ID，壓縮到 16 字節(jié)；
- 4）單條紅包記錄二進(jìn)制表達(dá)，壓縮到 26 字節(jié)。
10.2對賬
上面所有都做到就安全了么？真的就有人寫了一個(gè)不存在紅包進(jìn)來會怎樣？是否還有其他未考慮到的潛在風(fēng)險(xiǎn)？所以我們需要一個(gè)兜底——對賬，把一切都要對清楚才放心。
對賬后再入賬的時(shí)效在 30~60 分鐘，會造成不好的用戶體驗(yàn)。為了提升用戶體驗(yàn)，將大額的預(yù)紅包數(shù)據(jù)（占比 10% 左右）導(dǎo)入 KV（高速緩存），拆紅包時(shí)進(jìn)行即時(shí)校驗(yàn)，即時(shí)進(jìn)行轉(zhuǎn)賬入賬，未命中 KV 的紅包則等待對賬后異步完成入賬。
主要要點(diǎn)有：
- 1）資金配置與資金預(yù)算要總分對賬；
- 2）紅包數(shù)據(jù)文件與資金劇本進(jìn)行總分對賬；
- 3）紅包數(shù)據(jù)進(jìn)行全局去重驗(yàn)證；
- 4）紅包數(shù)據(jù)進(jìn)行解密驗(yàn)證和金額驗(yàn)證；
- 5）如果密鑰泄漏紅包金額等被篡改，兜底要進(jìn)行紅包 DB 中已拆紅包數(shù)據(jù)與預(yù)紅包數(shù)據(jù)的對賬后，才能實(shí)際進(jìn)行轉(zhuǎn)賬入賬。
十一、本文小結(jié)
未來我們可能還繼續(xù)會有類似的活動(dòng)，雖然我們已經(jīng)有了一個(gè)經(jīng)過實(shí)踐的可復(fù)用的技術(shù)方案，接下來我們希望能夠繼續(xù)優(yōu)化，并實(shí)現(xiàn)一些可復(fù)用的模塊和服務(wù)，可以快速應(yīng)用到下一次活動(dòng)或者其他業(yè)務(wù)場景中。例如，我們在當(dāng)初的 2015 年春節(jié)首次完成除夕活動(dòng)后，就把其中的資源預(yù)下載系統(tǒng)進(jìn)行了完善和通用化，隨后應(yīng)用在多個(gè)業(yè)務(wù)場景和后來的 2016 年除夕活動(dòng)中。未來可以有更多類似的系統(tǒng)和服務(wù)可以被復(fù)用和通用化。
（原文鏈接：https://www.infoq.cn/article/1-billion-bonus-from-the-clouds）
附錄1：有關(guān)微信、QQ的文章匯總
[1] QQ、微信團(tuán)隊(duì)原創(chuàng)技術(shù)文章：
《微信朋友圈千億訪問量背后的技術(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后臺喚醒實(shí)戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》
《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》
《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》
《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》
《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》
《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》
《騰訊團(tuán)隊(duì)分享：手機(jī)QQ中的人臉識別酷炫動(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ì)披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》
《月活8.89億的超級IM微信是如何進(jìn)行Android端兼容測試的》
《以手機(jī)QQ為例探討移動(dòng)端IM中的“輕應(yīng)用”》
《一篇文章get微信開源移動(dòng)端數(shù)據(jù)庫組件WCDB的一切！》
《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》
《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》
《微信后臺團(tuán)隊(duì)：微信后臺異步消息隊(duì)列的優(yōu)化升級實(shí)踐分享》
《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(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ò)層封裝庫，即將開源》
《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機(jī)千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(進(jìn)程保活篇)》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》
《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬連接背后的后臺解決方案》
《微信朋友圈海量技術(shù)之道PPT [附件下載]》
《微信對網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》
《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》
《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（二）》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》
《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》
《微信團(tuán)隊(duì)原創(chuàng)資源混淆工具：讓你的APK立減1M》
《微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實(shí)戰(zhàn)記錄》
《iOS版微信安裝包“減肥”實(shí)戰(zhàn)記錄》
《移動(dòng)端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測方案》
《微信“紅包照片”背后的技術(shù)難題》
《移動(dòng)端IM實(shí)踐：iOS版微信小視頻功能技術(shù)方案實(shí)錄》
《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（一）》
《移動(dòng)端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》
《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》
《移動(dòng)端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》
《移動(dòng)端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》
《移動(dòng)端IM實(shí)踐：iOS版微信的多設(shè)備字體適配方案探討》
《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術(shù)分享：百億級實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》
《騰訊TEG團(tuán)隊(duì)原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫TDSQL十年鍛造經(jīng)驗(yàn)分享》
《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》
《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》
《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《微信多媒體團(tuán)隊(duì)梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》
《騰訊音視頻實(shí)驗(yàn)室：使用AI黑科技實(shí)現(xiàn)超低碼率的高清實(shí)時(shí)視頻聊天》
《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實(shí)踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術(shù)研究學(xué)習(xí))》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（容災(zāi)方案篇）》
《騰訊技術(shù)分享：GIF動(dòng)圖技術(shù)詳解及手機(jī)QQ動(dòng)態(tài)表情壓縮技術(shù)實(shí)踐》
《微信團(tuán)隊(duì)分享：Kotlin漸被認(rèn)可，Android版微信的技術(shù)嘗鮮之旅》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》
>> 更多同類文章 ……
[2] 有關(guān)QQ、微信的技術(shù)故事：
《技術(shù)往事：微信估值已超5千億，雷軍曾有機(jī)會收編張小龍及其Foxmail》
《QQ和微信兇猛成長的背后：騰訊網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的這些年》
《閑話即時(shí)通訊：騰訊的成長史本質(zhì)就是一部QQ成長史》
《2017微信數(shù)據(jù)報(bào)告：日活躍用戶達(dá)9億、日發(fā)消息380億條》
《騰訊開發(fā)微信花了多少錢？技術(shù)難度真這么大？難在哪？》
《技術(shù)往事：創(chuàng)業(yè)初期的騰訊——16年前的冬天，誰動(dòng)了馬化騰的代碼》
《技術(shù)往事：史上最全QQ圖標(biāo)變遷過程，追尋IM巨人的演進(jìn)歷史》
《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》
《開發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》
《開發(fā)往事：微信千年不變的那張閃屏圖片的由來》
《開發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個(gè)月時(shí)）》
《一個(gè)微信實(shí)習(xí)生自述：我眼中的微信開發(fā)團(tuán)隊(duì)》
《首次揭秘：QQ實(shí)時(shí)視頻聊天背后的神秘組織》
《為什么說即時(shí)通訊社交APP創(chuàng)業(yè)就是一個(gè)坑？》
《微信七年回顧：歷經(jīng)多少質(zhì)疑和差評，才配擁有今天的強(qiáng)大》
《前創(chuàng)始團(tuán)隊(duì)成員分享：盤點(diǎn)微信的前世今生——微信成功的必然和偶然》
《即時(shí)通訊創(chuàng)業(yè)必讀：解密微信的產(chǎn)品定位、創(chuàng)新思維、設(shè)計(jì)法則等》
《QQ的成功，遠(yuǎn)沒有你想象的那么順利和輕松》
《QQ現(xiàn)狀深度剖析：你還認(rèn)為QQ已經(jīng)被微信打敗了嗎？》
《[技術(shù)腦洞] 如果把14億中國人拉到一個(gè)微信群里技術(shù)上能實(shí)現(xiàn)嗎？》
《QQ和微信止步不前，意味著即時(shí)通訊社交應(yīng)用創(chuàng)業(yè)的第2春已來？》
《那些年微信開發(fā)過的雞肋功能，及其帶給我們的思考》
《讀懂微信：從1.0到7.0版本，一個(gè)主流IM社交工具的進(jìn)化史》
《同為IM社交產(chǎn)品中的王者，QQ與微信到底有什么區(qū)別》
《還原真實(shí)的騰訊：從最不被看好，到即時(shí)通訊巨頭的草根創(chuàng)業(yè)史》
>> 更多同類文章 ……
附錄2：更多架構(gòu)方面的文章匯總
[1] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲架構(gòu)？》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實(shí)踐建議》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（容災(zāi)方案篇）》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》
>> 更多同類文章 ……
[2] 更多其它架構(gòu)設(shè)計(jì)相關(guān)文章：
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實(shí)踐》
《知乎技術(shù)分享：從單機(jī)到2000萬QPS并發(fā)的Redis高性能緩存實(shí)踐之路》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》
《達(dá)達(dá)O2O后臺架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請求背后的努力》
《優(yōu)秀后端架構(gòu)師必會知識：史上最全MySQL大表優(yōu)化方案總結(jié)》
《小米技術(shù)分享：解密小米搶購系統(tǒng)千萬高并發(fā)架構(gòu)的演進(jìn)和實(shí)踐》
《一篇讀懂分布式架構(gòu)下的負(fù)載均衡技術(shù)：分類、原理、算法、常見方案等》
《通俗易懂：如何設(shè)計(jì)能支撐百萬并發(fā)的數(shù)據(jù)庫架構(gòu)？》
>> 更多同類文章 ……
（本文已同步發(fā)布于：http://www.52im.net/thread-2533-1-1.html）