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