本文原文內(nèi)容引用自高可用架構(gòu)公眾號(hào)，內(nèi)容有整理和修訂。

1、引言

大家對(duì)下面這個(gè)排隊(duì)的場(chǎng)景應(yīng)該非常熟悉，這個(gè)是小米手機(jī)搶購(gòu)的用戶排隊(duì)交互圖，大家看到這些排隊(duì)的兔子時(shí)，說(shuō)明也有很多用戶在同一時(shí)間向小米搶購(gòu)系統(tǒng)提交了購(gòu)買請(qǐng)求。

▲ 小米手機(jī)搶購(gòu)排隊(duì)中...

小米搶購(gòu)系統(tǒng)后端服務(wù)面臨巨大的壓力，下圖可以反映小米搶購(gòu)系統(tǒng)面臨的瞬間峰值壓力。這張圖截取自某年米粉節(jié)大秒服務(wù)后端其中一組LB（負(fù)載均衡層）的每分鐘請(qǐng)求總數(shù)的情況（橫軸的時(shí)間是UTC時(shí)間），如大家可以想象到的一樣，峰值流量是普通情況下流量的近10倍。

▲ 某年米粉節(jié)大秒服務(wù)后端其中一組負(fù)載均衡層的QPS統(tǒng)計(jì)情況

以上就是小米搶購(gòu)活動(dòng)時(shí)后端服務(wù)集群面臨的壓力。小米搶購(gòu)系統(tǒng)從2011年底誕生到成長(zhǎng)為一個(gè)扛過(guò)2次米粉節(jié)和多次爆品首發(fā)的高性能、高可靠的峰值系統(tǒng)，經(jīng)歷了很多次大大小小的架構(gòu)演進(jìn)，本次分享將為大家解密該系統(tǒng)的技術(shù)演進(jìn)、設(shè)計(jì)思路、實(shí)踐總結(jié)等，希望能帶給您啟發(fā)。

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

2、分享者

馬利超：小米科技的系統(tǒng)研發(fā)與大數(shù)據(jù)工程師，2013年畢業(yè)于大連理工大學(xué)，畢業(yè)后有幸加入小米搶購(gòu)系統(tǒng)團(tuán)隊(duì)，并參與了小米搶購(gòu)系統(tǒng)開發(fā)、重構(gòu)與調(diào)優(yōu)。其人熱愛技術(shù)，對(duì)分布式系統(tǒng)架構(gòu)、高并發(fā)峰值系統(tǒng)、大數(shù)據(jù)領(lǐng)域、反作弊領(lǐng)域、搜索/廣告/推薦系統(tǒng)有濃厚的興趣。

3、相關(guān)文章

《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》

《達(dá)達(dá)O2O后臺(tái)架構(gòu)演進(jìn)實(shí)踐：從0到4000高并發(fā)請(qǐng)求背后的努力》

《騰訊資深架構(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í)踐之路》

4、小米搶購(gòu)系統(tǒng)的前世今生

4.1 早期的架構(gòu)設(shè)計(jì)

2011底，在小米手機(jī)首批30萬(wàn)全部發(fā)完貨之后，接下來(lái)便是大家熟知的，每周二中午十二點(diǎn)，小米手機(jī)開放購(gòu)買。在開放購(gòu)買期間，海量的用戶請(qǐng)求瞬間沖擊過(guò)來(lái)，對(duì)于當(dāng)時(shí)小米這樣一個(gè)初創(chuàng)公司，特別是一個(gè)剛成立不到半年的電商團(tuán)隊(duì)來(lái)說(shuō)，面臨的挑戰(zhàn)是巨大的。

面臨的問(wèn)題大致如下：

1）第一次開放購(gòu)買，在小米商城主站進(jìn)行，在瞬時(shí)壓力下，整個(gè)主交易系統(tǒng)并沒(méi)有逃脫掛掉的命運(yùn)；

2）開放購(gòu)買活動(dòng)是結(jié)束了，但是一周之后，下一輪的開放購(gòu)買已經(jīng)開始開放預(yù)約，開放購(gòu)買又會(huì)如期而至。

為了保證下次開放購(gòu)買順利進(jìn)行，留給小米網(wǎng)工程師團(tuán)隊(duì)的時(shí)間是有限的，只有短短的7天時(shí)間。

經(jīng)過(guò)技術(shù)團(tuán)隊(duì)討論，為了避免搶購(gòu)時(shí)的峰值流量壓垮整個(gè)小米網(wǎng)，決定設(shè)計(jì)一套獨(dú)立的搶購(gòu)系統(tǒng)。預(yù)約用戶通過(guò)在這套獨(dú)立的搶購(gòu)系統(tǒng)中搶到購(gòu)買資格，購(gòu)買資格會(huì)異步的由資格數(shù)據(jù)同步模塊同步到用戶的購(gòu)物車中，從用戶搶到手機(jī)那一時(shí)刻起，在規(guī)定的時(shí)間內(nèi)，用戶小米商城完成下單和支付。

從此這版獨(dú)立的搶購(gòu)系統(tǒng)承接了小米的所有的搶購(gòu)，經(jīng)歷過(guò)大大小小的優(yōu)化與重構(gòu)，最后又演化為整個(gè)小米網(wǎng)的限流峰值系統(tǒng)。這版最初的搶購(gòu)系統(tǒng)內(nèi)部代號(hào)：TD。

這套系統(tǒng)早期的架設(shè)設(shè)計(jì)出發(fā)點(diǎn)是：

1）并發(fā)能力要盡量的高，能承受瞬時(shí)的峰值；

2）不能超賣（可容忍小量的超賣）；

3）只有預(yù)約用戶可以購(gòu)買，一個(gè)用戶只能買一臺(tái)；

4）要非?？煽?，購(gòu)買記錄不可丟失。

TD的早期技術(shù)架構(gòu)圖：

如上圖所示，小米第一版搶購(gòu)系統(tǒng)使用的技術(shù)棧：LVS + nginx + PHP + node.js + redis：

1）預(yù)約用戶信息緩存在遠(yuǎn)端緩存集群中，一主多從結(jié)構(gòu)，具體在放號(hào)的過(guò)程中，對(duì)預(yù)約數(shù)據(jù)只有查詢操作；

2）放號(hào)業(yè)務(wù)邏輯層使用PHP開發(fā)（當(dāng)時(shí)小米網(wǎng)PHP開發(fā)者居多），使用遠(yuǎn)端緩存作為數(shù)據(jù)中心，存放用戶的購(gòu)買記錄，同時(shí)，每放一個(gè)資格號(hào)，記錄一條持久化的log（資格日志），保障用戶購(gòu)買記錄可靠；

3）使用node.js開發(fā)的資格日志收集及統(tǒng)計(jì)模塊logagent，收集資格日志，并將資格日志發(fā)送到遠(yuǎn)端的logserver；同時(shí)，logagent統(tǒng)計(jì)自己所在的機(jī)器上購(gòu)買記錄的條數(shù)，由于事先均等的分配好每臺(tái)機(jī)器的商品銷售數(shù)量，當(dāng)機(jī)器上購(gòu)買成功的日志條數(shù)大于等于分配的數(shù)量時(shí)，則在本地生成一個(gè).Lock的文件；

4）PHP開發(fā)的放號(hào)業(yè)務(wù)邏Middle集群中服務(wù)可能會(huì)輯中首先會(huì)檢查.Lock的文件是否存在，來(lái)標(biāo)志這臺(tái)機(jī)器上的資格數(shù)是否被放完；同時(shí)，logserver將用戶購(gòu)買成功的資格同步到購(gòu)物車及其他相關(guān)服務(wù)系統(tǒng)中。

這套架構(gòu)的回顧和總結(jié)：

1) 伸縮性強(qiáng)：PHP開發(fā)的放號(hào)邏輯不持有狀態(tài)數(shù)據(jù)，狀態(tài)數(shù)據(jù)存在遠(yuǎn)端數(shù)據(jù)中心或者由logagent控制生成本地文件鎖（.Lock）標(biāo)識(shí)，伸縮性強(qiáng)；

2) 可靠性高：搶購(gòu)成功記錄以日志的形式記錄，保障數(shù)據(jù)可靠性。

該系統(tǒng)經(jīng)過(guò)不間斷的優(yōu)化，滿足了2012年及2013年上半年的搶購(gòu)需求，應(yīng)對(duì)的預(yù)約量在100萬(wàn)級(jí)別。

毫無(wú)疑問(wèn)，這個(gè)初期架構(gòu)也存在很多問(wèn)題：

1）單機(jī)處理能力有限：由于單機(jī)處理能力有限，如果要應(yīng)對(duì)千萬(wàn)級(jí)別的預(yù)約量時(shí)，假設(shè)不暴漏伸縮性問(wèn)題的話，需要的資源數(shù)量是否能承擔(dān)的起？

2）logserver處理能力： logserver的管理能力有限，隨著搶購(gòu)人數(shù)的增多，并發(fā)量的增加，當(dāng)前邏輯下，每秒放的資格數(shù)量會(huì)增加，logserver是否能夠及時(shí)的處理這些資格記錄？

基于上述問(wèn)題，接下來(lái)我們來(lái)看小米新一代搶購(gòu)系統(tǒng)，也可以理解為加強(qiáng)版。

4.2 加入了限流服務(wù)后的新一代搶購(gòu)系統(tǒng)

2013年7月份，小米發(fā)布了紅米手機(jī)，并與QQ空間合作首發(fā)，1分鐘內(nèi)預(yù)約達(dá)到30萬(wàn)，半個(gè)小時(shí)預(yù)約量達(dá)到100萬(wàn)，72小時(shí)預(yù)約量突破500萬(wàn)，小米手機(jī)的預(yù)約量從此進(jìn)入了千萬(wàn)級(jí)別，面對(duì)如此驚人的預(yù)約量，像之前分析的那樣，如何在短時(shí)間內(nèi)應(yīng)對(duì)這個(gè)突發(fā)的量級(jí)變化呢？（紅米手機(jī)發(fā)布前，技術(shù)團(tuán)隊(duì)并不清楚將要面臨的挑戰(zhàn)）。

經(jīng)過(guò)技術(shù)團(tuán)隊(duì)討論之后，決定在搶購(gòu)系統(tǒng)之前加一層限流服務(wù)，將流量限制在TD能夠處理的能力范圍之內(nèi)，由此便演進(jìn)出一個(gè)新的服務(wù)——限流服務(wù)，內(nèi)部代號(hào): TC。

新一代搶購(gòu)系統(tǒng)的整體架構(gòu)介紹如下：

最初的TC使用nginx+Lua開發(fā)，主要負(fù)責(zé)用戶預(yù)約驗(yàn)證和每秒向后端放行流量控制：

1）TC在活動(dòng)開始前，load預(yù)約用戶數(shù)據(jù)到nginx共享內(nèi)存中；

2）使用Lua開發(fā)每秒放量計(jì)數(shù)邏輯，nginx的異步IO機(jī)制加上Lua的多協(xié)程處理能力，使限流層能夠達(dá)到一個(gè)很高的并發(fā)量；

3）Nginx是多進(jìn)程運(yùn)行，我們需要將預(yù)先限流層的每秒放行總量均攤到整個(gè)Nginx集群的進(jìn)程數(shù)量上，而非按照機(jī)器數(shù)量均攤。

TC與TD之間以token的形式交互，用戶從TC上取得放行資格，然后拿著這個(gè)資格去TD放量集群中請(qǐng)求放量，TD放行通過(guò)，才代表最終的搶購(gòu)成功。

有了上述的系統(tǒng)結(jié)構(gòu)，只要放行控制得當(dāng)，再高的流量壓力也不用怕了，我們也成功撐過(guò)了紅米首發(fā)。

從此這個(gè)小米開放購(gòu)買預(yù)約量進(jìn)入了千萬(wàn)級(jí)別，紅米2首發(fā)預(yù)約量更是在兩千萬(wàn)級(jí)別。

盡管系統(tǒng)并發(fā)能力有了大大的提升，但是整個(gè)系統(tǒng)仍有一些不足：

1）管理功能簡(jiǎn)陋：活動(dòng)過(guò)程中需要人工干預(yù)活動(dòng)的結(jié)束，在TD服務(wù)將商品賣完后，手動(dòng)執(zhí)行命令設(shè)置TC內(nèi)存中指定商品的銷售狀態(tài)為售罄，這個(gè)誤操作風(fēng)險(xiǎn)非常高，并且延遲很高，在商品售罄后不能及時(shí)的通知用戶售罄狀態(tài)；

2）靈活性較弱：技術(shù)團(tuán)隊(duì)對(duì)于lua使用還不夠靈活，TC也只能處理一些簡(jiǎn)單的業(yè)務(wù)邏輯；

3）反應(yīng)能力不足：前后端處理能力差距較大，一旦限流失誤，后端很快就會(huì)崩潰，管理體系的不完善，不能瞬時(shí)響應(yīng)。往往在流量高峰下，再多1秒的請(qǐng)求量，就有可能使整個(gè)系統(tǒng)發(fā)生雪崩。反應(yīng)能力的不足造成，系統(tǒng)的可靠性下降。

在TC限流服務(wù)優(yōu)化的過(guò)程中，我們調(diào)研了其他高并發(fā)的語(yǔ)言，如: C/C++、 scala、erlang、node.js、golang等。

從學(xué)習(xí)成本、開發(fā)效率、運(yùn)維便捷性等多方面評(píng)估，我們選擇使用golang開發(fā)了一版TC服務(wù)。在2013年11月，我們上線了golang版的TC服務(wù)，同時(shí)也針對(duì)這款golang版的TC限流服務(wù)和TD放號(hào)服務(wù)開發(fā)了統(tǒng)一的監(jiān)控管理平臺(tái)，由監(jiān)控管理平臺(tái)統(tǒng)一協(xié)調(diào)整個(gè)活動(dòng)以及參與活動(dòng)的商品的配置與狀態(tài)，在整個(gè)系統(tǒng)流程上保證了很好的連貫性以及運(yùn)營(yíng)的靈活性。監(jiān)控管理平臺(tái)同時(shí)還負(fù)責(zé)監(jiān)控各個(gè)服務(wù)的運(yùn)行狀態(tài)，及時(shí)報(bào)警。

接下來(lái)的文章內(nèi)容，我們將詳細(xì)介紹基于golang的小米搶購(gòu)系統(tǒng)（內(nèi)部稱為“大秒”），也是本文的分享重點(diǎn)，請(qǐng)繼續(xù)往下閱讀。

5、整合了搶購(gòu)限流峰值服務(wù)后的小米搶購(gòu)系統(tǒng)：“大秒”

接上節(jié)，我們繼續(xù)詳細(xì)介紹這套最新架構(gòu)。

時(shí)間回到2014年初，當(dāng)時(shí)公司決定舉辦一場(chǎng)“米粉節(jié)”活動(dòng)，全天6輪活動(dòng)，多個(gè)國(guó)家、多款爆品同時(shí)參與搶購(gòu)。業(yè)務(wù)場(chǎng)景將變得更加復(fù)雜，當(dāng)天的并發(fā)壓力也會(huì)有一個(gè)量級(jí)的提升，原有的搶購(gòu)系統(tǒng)已經(jīng)不能適應(yīng)如此復(fù)雜的業(yè)務(wù)場(chǎng)景了。

為此，小米網(wǎng)技術(shù)團(tuán)隊(duì)基于對(duì) golang 應(yīng)對(duì)高并發(fā)、大規(guī)模分布式系統(tǒng)能力的肯定，完全基于 golang，重新設(shè)計(jì)了搶購(gòu)系統(tǒng)，也就是我們目前使用的搶購(gòu)限流峰值系統(tǒng)——“大秒”。

在整個(gè)系統(tǒng)設(shè)計(jì)的之初，我們充分考慮了：

1）靈活性及可運(yùn)營(yíng)性；

2）可運(yùn)維性及可伸縮性；

3）限流與搶購(gòu)放號(hào)的精準(zhǔn)性。

從大秒第一天誕生到演化至今有很多次重構(gòu)與優(yōu)化，但一直沿用了設(shè)計(jì)之初的結(jié)構(gòu)，接下來(lái)我們?cè)敿?xì)了解下這套架構(gòu)的技術(shù)設(shè)計(jì)以及填過(guò)的一些坑。

6、“大秒”系統(tǒng)的架構(gòu)設(shè)計(jì)

大秒系統(tǒng)主要由如下幾個(gè)模塊構(gòu)成：

1）限流集群 HTTP 服務(wù)；

2）放號(hào)策略集群 Middle 服務(wù)；

3）監(jiān)控?cái)?shù)據(jù)中心 Dcacenter；

4）監(jiān)控管理體系 Master；

5）準(zhǔn)實(shí)時(shí)防刷模塊 antiblack；

6）基礎(chǔ)存儲(chǔ)與日志隊(duì)列服務(wù)：Redis 集群、Kafka 集群等。

整個(gè)大秒體系中大秒前端模塊 (HTTP/middle/antiblack) 和監(jiān)控?cái)?shù)據(jù)中心使用 golang 開發(fā)，大秒監(jiān)控管理體系使用 Python + golang 開發(fā)。

7、“大秒”的前端架構(gòu)設(shè)計(jì)

“大秒”前端的架構(gòu)設(shè)計(jì)從三個(gè)系統(tǒng)展開：

1）限流集群 HTTP 服務(wù)；

2）策略集群 Middle 服務(wù)；

3）準(zhǔn)實(shí)時(shí)反作弊 antiblack 服務(wù)。

7.1 限流集群 HTTP 服務(wù)

搶購(gòu)高峰時(shí)，通常會(huì)有幾百萬(wàn)的用戶同時(shí)請(qǐng)求，瞬時(shí)流量非常大，HTTP 集群頂在最前線，接受用戶的請(qǐng)求，將合法的請(qǐng)求發(fā)送的處理隊(duì)列，處理隊(duì)列設(shè)置一定的長(zhǎng)度限制，通常情況下，搶購(gòu)用戶數(shù)與銷售商品的比例在100：1，甚至更高，為了避免系統(tǒng)不被沖垮，保障絕大多數(shù)用戶的體驗(yàn)，我們認(rèn)為流量是部分可丟失的，當(dāng)處理隊(duì)列滿時(shí)，丟棄入隊(duì)請(qǐng)求；

雖然設(shè)計(jì)上過(guò)載流量是部分可丟棄的，但是策略層處理能力是非常 power 的，即便是需要丟棄流量，也是按流量的惡意程度，逐級(jí)丟棄的，正常用戶購(gòu)買請(qǐng)求不受影響。

我們使用基于規(guī)則的識(shí)別、離線畫像信息、機(jī)器學(xué)習(xí)邏輯回歸等方法，識(shí)別惡意用戶，在系統(tǒng)高負(fù)載的情況下，這部分請(qǐng)求可以優(yōu)先阻擊其發(fā)送到策略層，優(yōu)先處理正常用戶的請(qǐng)求，保障用戶體驗(yàn)過(guò)。

HTTP集群中不同節(jié)點(diǎn)之間的所持用的狀態(tài)數(shù)據(jù)是一致的，處理邏輯也是一致的，所以整個(gè)集群中的任何一個(gè)節(jié)點(diǎn)掛掉，在前端負(fù)載均衡能力下，服務(wù)的準(zhǔn)確性與一致性不受任何影響。

7.2 策略集群 Middle 服務(wù)

HTTP 模塊將滿足條件用戶的請(qǐng)求按照 uid 哈希的規(guī)則，轉(zhuǎn)發(fā)到 Middle 集群中相應(yīng)的節(jié)點(diǎn)，Middle 集群根據(jù)商品放號(hào)策略判斷 (uid:sku:time) 組合是否可以分配購(gòu)買資格，并返回給相應(yīng)的 HTTP 服務(wù)；

使用 Middle 服務(wù)本地內(nèi)存維護(hù)用戶的購(gòu)買記錄信息，支持各種購(gòu)買規(guī)則，比如：?jiǎn)未位顒?dòng)不限購(gòu)買數(shù)量，單次活動(dòng)僅限購(gòu)買一款商品，單次活動(dòng)每款商品僅限購(gòu)買一次。

我們將 Middle 的放號(hào)邏輯抽象成一個(gè)有限狀態(tài)機(jī)，由商品的放號(hào)策略配置閾值來(lái)觸發(fā)放號(hào)狀態(tài)轉(zhuǎn)換，整個(gè)配置由 Master 節(jié)點(diǎn)統(tǒng)一管理與調(diào)度。

為了提升整個(gè)系統(tǒng)的處理能力，我們將用戶狀態(tài)數(shù)據(jù)局部化，單用戶（uid）的所有相關(guān)信息全部路由到一臺(tái) Middle 節(jié)點(diǎn)上處理。

但是有一點(diǎn)風(fēng)險(xiǎn)是，Middle 集群中服務(wù)可能會(huì)出現(xiàn)活動(dòng)過(guò)程中掛掉的風(fēng)險(xiǎn)，在搶購(gòu)場(chǎng)景下，商品基本上是瞬時(shí)賣完，為了保障系統(tǒng)的處理能力，我們主要從代碼層面做優(yōu)化，review 代碼邏輯，保證服務(wù)應(yīng)對(duì)異常的處理能力。

雖然理論上存在風(fēng)險(xiǎn)，但是在實(shí)際工程中，經(jīng)歷過(guò)幾百次活動(dòng)，還沒(méi)出現(xiàn) Middle 節(jié)點(diǎn)掛掉的情況。

7.3 準(zhǔn)實(shí)時(shí)防刷 antiblack 服務(wù)

基于日志流的防刷架構(gòu)，在每臺(tái) HTTP 節(jié)點(diǎn)上部署日志收集 Agent，使用高吞吐量的 Kafka 做日志轉(zhuǎn)儲(chǔ)隊(duì)列，antiblack 模塊實(shí)時(shí)分析用戶請(qǐng)求日志，基于 IP 粒度、Uid 粒度等做防刷。

雖然此處將 antiblack 模塊定義為準(zhǔn)實(shí)時(shí)防刷模塊，但是作弊信息識(shí)別的延遲時(shí)長(zhǎng)在 1 分鐘之內(nèi)，其中主要的時(shí)延發(fā)生在日志的轉(zhuǎn)儲(chǔ)過(guò)程中。

8、“大秒”的監(jiān)控管理體系

8.1 監(jiān)控?cái)?shù)據(jù)中心 dcacenter

1）監(jiān)控?cái)?shù)據(jù)中心數(shù)據(jù)種類：

1）業(yè)務(wù)級(jí)數(shù)據(jù)：過(guò)大秒的商品配置數(shù)據(jù)與實(shí)時(shí)狀態(tài)數(shù)據(jù)，當(dāng)前活動(dòng)的配置與狀態(tài)數(shù)據(jù)等；

2）系統(tǒng)級(jí)數(shù)據(jù)：大秒前端服務(wù)集群通信地址配置，限流隊(duì)列初始長(zhǎng)度配置，系統(tǒng)服務(wù)資源占用情況，包括：CPU、MEM、連接數(shù)等；

2）數(shù)據(jù)采集方式：

同時(shí)使用push和pull模式采集業(yè)務(wù)級(jí)監(jiān)控?cái)?shù)據(jù)和系統(tǒng)級(jí)監(jiān)控?cái)?shù)據(jù)，業(yè)務(wù)級(jí)數(shù)據(jù)越實(shí)時(shí)越好，做到1秒采集處理，3秒可視化；對(duì)于 HTTP 節(jié)點(diǎn)和 Middle 節(jié)點(diǎn)采用pull的模式拉去系統(tǒng)監(jiān)控?cái)?shù)據(jù)和業(yè)務(wù)監(jiān)控?cái)?shù)據(jù)。

具體的優(yōu)點(diǎn)如下。

a. 靈活性高：

由數(shù)據(jù)中心控制監(jiān)控?cái)?shù)據(jù)采集的粒度，在數(shù)據(jù)中心處理能力既定的情況下，可以根據(jù)前端集群的伸縮規(guī)模，靈活的調(diào)整數(shù)據(jù)采集的粒度，比如米粉節(jié)時(shí)，大秒前端集群擴(kuò)容至過(guò)百臺(tái)，管理的過(guò)大秒商品的數(shù)量在400個(gè)左右，業(yè)務(wù)級(jí)監(jiān)控?cái)?shù)據(jù)量很大，此時(shí)監(jiān)控?cái)?shù)據(jù)采集時(shí)間間隔很容易降配至 2s。

對(duì)于除Http服務(wù)和Middle服務(wù)之外的服務(wù)集群，如：redis，管理平臺(tái)各個(gè)模塊等可以使用監(jiān)控?cái)?shù)據(jù)采集agent，將采集到的數(shù)據(jù)周期性的push到redis隊(duì)列，dcacenter采集協(xié)程實(shí)時(shí)的從redis隊(duì)列中拉去消息，對(duì)于基礎(chǔ)服務(wù)以及python實(shí)現(xiàn)的服務(wù)，增加了監(jiān)控?cái)?shù)據(jù)采集靈活性。

b. 增強(qiáng)服務(wù)的可靠性與伸縮性：

大秒在設(shè)計(jì)之初采用push的方式，在每臺(tái)前端機(jī)器上部署一個(gè)數(shù)據(jù)采集agent，agent和大秒前端服務(wù)同時(shí)alive，才代表?yè)屬?gòu)系統(tǒng)健康運(yùn)行。這樣即增加了系統(tǒng)的不穩(wěn)定因素，由不利于系統(tǒng)的伸縮，將監(jiān)控?cái)?shù)據(jù)采集邏輯內(nèi)置到前端golang程序中，提供tcp管理端口，在數(shù)據(jù)中心使用pull方式采集數(shù)據(jù)，很好的解決了這個(gè)問(wèn)題。減少了服務(wù)的數(shù)量，增強(qiáng)了整個(gè)系統(tǒng)的可靠性與伸縮性。

3）數(shù)據(jù)ETL與數(shù)據(jù)緩存：

dcacenter同時(shí)負(fù)責(zé)將采集到的業(yè)務(wù)級(jí)數(shù)據(jù)及系統(tǒng)級(jí)監(jiān)控?cái)?shù)據(jù)，實(shí)時(shí)清洗，提取，轉(zhuǎn)換，結(jié)構(gòu)化，并將結(jié)構(gòu)化的數(shù)據(jù)存儲(chǔ)在自身內(nèi)存中，定制通信協(xié)議（golang實(shí)現(xiàn)類redis通信協(xié)議），作為一個(gè)數(shù)據(jù)中心，對(duì)整個(gè)管理體系Master及其他系統(tǒng)提供實(shí)時(shí)數(shù)據(jù)支持。

將dcacenter直接作為數(shù)據(jù)中心，主要是出于數(shù)據(jù)的實(shí)時(shí)性考慮，省去中間轉(zhuǎn)儲(chǔ)環(huán)節(jié)，上層可視化系統(tǒng)、自動(dòng)化活動(dòng)控制系統(tǒng)、規(guī)則引擎系統(tǒng)等可以第一時(shí)間獲得前端實(shí)時(shí)的銷售狀態(tài)數(shù)據(jù)及服務(wù)的狀態(tài)數(shù)據(jù)。

8.2 監(jiān)控管理中心 Master

監(jiān)控管理中心的主要模塊如下。

a.倉(cāng)儲(chǔ)庫(kù)存同步服務(wù)StockKeeper：

同步商品的倉(cāng)儲(chǔ)系統(tǒng)中的實(shí)時(shí)庫(kù)存到秒殺系統(tǒng)，大秒系統(tǒng)擁有雙庫(kù)存保障，一個(gè)是實(shí)時(shí)倉(cāng)儲(chǔ)庫(kù)存，一個(gè)是虛擬庫(kù)存也就是資格號(hào)，在搶購(gòu)場(chǎng)景下只有當(dāng)兩個(gè)庫(kù)存都有貨時(shí)，才能正常銷售。

b.商品策略控制器PolicyKeeper：

基于相應(yīng)的策略觸發(fā)器（時(shí)間區(qū)間與庫(kù)存區(qū)間），當(dāng)策略觸發(fā)時(shí)，比如12點(diǎn)整，搶購(gòu)開始，為相應(yīng)的商品配置策略，并向大秒前端廣播商品配置變更命令，在通信基礎(chǔ)模塊的保障下，整個(gè)過(guò)程秒級(jí)內(nèi)完成。

c.活動(dòng)自動(dòng)化控制ActKeeper：

基于監(jiān)控?cái)?shù)據(jù)中心獲取大秒前端的實(shí)時(shí)銷售數(shù)據(jù)，自動(dòng)化的控制活動(dòng)中的各個(gè)狀態(tài)，活動(dòng)開始前逐層打開開關(guān)，活動(dòng)開始時(shí)打開最后開關(guān)，活動(dòng)過(guò)程中維護(hù)活動(dòng)的售罄狀態(tài)，活動(dòng)結(jié)束后初始化，整個(gè)搶購(gòu)活動(dòng)的過(guò)程無(wú)需人工介入；

d.數(shù)據(jù)可視化：

從監(jiān)控?cái)?shù)據(jù)中心提取實(shí)時(shí)的結(jié)構(gòu)化系統(tǒng)級(jí)監(jiān)控?cái)?shù)據(jù)和業(yè)務(wù)級(jí)監(jiān)控?cái)?shù)據(jù)，將活動(dòng)過(guò)程中的詳細(xì)數(shù)據(jù)實(shí)時(shí)可視化到管理頁(yè)面上，讓運(yùn)營(yíng)與銷售以及大秒管理員能夠及時(shí)了解當(dāng)前活動(dòng)狀態(tài)，并人工干預(yù)活動(dòng)；

e.監(jiān)控規(guī)則引擎：

監(jiān)控規(guī)則引擎建立在監(jiān)控?cái)?shù)據(jù)中心之上，根據(jù)結(jié)構(gòu)化監(jiān)控?cái)?shù)據(jù)判斷當(dāng)前整個(gè)搶購(gòu)系統(tǒng)的狀態(tài)，及時(shí)報(bào)警，以及半自動(dòng)化控制。

f.其他：

大秒管理端管理大秒前端所有的數(shù)據(jù)、配置以及狀態(tài)，Master體系提供了詳細(xì)的管理工具與自動(dòng)化服務(wù)。如果清理大秒前端Middle服務(wù)中的用戶購(gòu)買信息等。

8.3 大秒配置管理數(shù)據(jù)流

整個(gè)搶購(gòu)系統(tǒng)由 Master 體系中各個(gè)服務(wù)做統(tǒng)一的控制的，Master 控制商品狀態(tài)及配置數(shù)據(jù)的變更，控制當(dāng)前活動(dòng)的狀態(tài)，控制商品放號(hào)的策略等。

為了保證時(shí)效性，商品、活動(dòng)、系統(tǒng)等配置狀態(tài)的變更都需要將變更命令廣播前端集群，這期間發(fā)生了大量的分布式系統(tǒng)間通信，為了保障命令及時(shí)下行，我們提取出了命令轉(zhuǎn)發(fā)服務(wù)：MdwRouter，用于廣播控制命令到大秒前端集群。該服務(wù)模塊維護(hù)了到大秒前端長(zhǎng)連接，接收 Master 下發(fā)的控制命令，并瞬時(shí)廣播，保障了整個(gè)控制流的處理能力。

舉個(gè)例子：

某年米粉節(jié)，我們單機(jī)房大秒集群的規(guī)模在過(guò)百臺(tái)級(jí)別，假設(shè)為 100 臺(tái)，管理的獨(dú)立的商品id的數(shù)量在 400 個(gè)左右，在這種量級(jí)的活動(dòng)下，商品的放行策略是批量管理的，比如我們根據(jù)后端交易系統(tǒng)的壓力反饋，調(diào)整所有商品的放行速度，這時(shí)候需要廣播的命令條數(shù)在: 100*400=40000 級(jí)別，Mdwrouter 很好的保障了系統(tǒng)命令下行的速度，秒級(jí)完成命令下行。

9、小米搶購(gòu)技術(shù)架構(gòu)整體概覽

9.1 整個(gè)搶購(gòu)服務(wù)閉環(huán)設(shè)計(jì)

▲ 整個(gè)小米網(wǎng)搶購(gòu)系統(tǒng)服務(wù)閉環(huán)

整個(gè)小米網(wǎng)搶購(gòu)系統(tǒng)服務(wù)閉環(huán)如上圖所示：

1）bigtap體系中大秒前端服務(wù)負(fù)責(zé)搶購(gòu)時(shí)限流放號(hào)，并控制放號(hào)策略以及維護(hù)用戶在本地緩存中的購(gòu)買記錄；

2）cart服務(wù)驗(yàn)證token的有效性，并向counter服務(wù)發(fā)起銷量驗(yàn)證請(qǐng)求;

3）counter服務(wù)是整個(gè)搶購(gòu)系統(tǒng)最終的計(jì)數(shù)器， 海量的請(qǐng)求在bigtap服務(wù)的作用下已經(jīng)被限制在可以承受的壓力范圍內(nèi)，并且復(fù)雜的放號(hào)策略已經(jīng)在大秒Middle服務(wù)中實(shí)現(xiàn)，counter只負(fù)責(zé)最終的計(jì)數(shù)即可。counter服務(wù)采用redis記錄相應(yīng)商品的放號(hào)情況，根據(jù)預(yù)設(shè)的銷量，判斷當(dāng)前請(qǐng)求加購(gòu)物車商品是否有庫(kù)存余量，并維護(hù)商品銷量;

4）bigtap體系中的dcacenter服務(wù)實(shí)時(shí)采集商品銷量，Master中活動(dòng)自動(dòng)化控制服務(wù)依據(jù)商品銷量判斷當(dāng)前商品是否售罄，售罄則通過(guò)設(shè)置商品的售罄狀態(tài)，并通知大秒前端。

9.2 整個(gè)系統(tǒng)在2015年米粉節(jié)的實(shí)際應(yīng)用情況

從上述整個(gè)服務(wù)閉環(huán)設(shè)計(jì)可以看出，“大秒”的功能完全可以抽象成限流系統(tǒng)，只有在處理?yè)屬?gòu)活動(dòng)時(shí)，數(shù)據(jù)的管理與一致性要求才使整個(gè)系統(tǒng)變得復(fù)雜。

2015年米粉節(jié)，我們完全使用大秒的限流功能，不限用戶的購(gòu)買數(shù)量，很便捷的將系統(tǒng)部署在兩個(gè)機(jī)房，一個(gè)物理機(jī)房，一個(gè)公有云集群，兩者同時(shí)服務(wù)，大秒系統(tǒng)作為整個(gè)商城的最前端，能夠根據(jù)后端服務(wù)的壓力狀態(tài)，瞬時(shí)調(diào)整整個(gè)集群放行流量大小，非常好的保障了整個(gè)米粉節(jié)的正常舉行。

正如您看到在上述文章中介紹的那樣，這些服務(wù)設(shè)計(jì)的每一次優(yōu)化的背后，都至少有一次慘痛的經(jīng)歷，針對(duì)這些經(jīng)歷，我們也做了大量的總結(jié)，這些總結(jié)將在下兩節(jié)的內(nèi)容里進(jìn)行總結(jié)性地分享。

10、“大秒”系統(tǒng)架構(gòu)的幾點(diǎn)經(jīng)驗(yàn)總結(jié)

10.1 Golang GC 優(yōu)化方法

我們從 golang 1.2 版本開始在線上搶購(gòu)系統(tǒng)中大規(guī)模使用，最初上線的 TC 限流集群在搶購(gòu)的過(guò)程中通過(guò)過(guò)載重啟的方式瘸腿前行。

在當(dāng)前的大秒系統(tǒng)中，對(duì)于限流集群主要是 goroutine 資源、HTTP 協(xié)議數(shù)據(jù)結(jié)構(gòu)、TCP 連接讀寫緩沖區(qū)等頻繁動(dòng)態(tài)開銷，造成內(nèi)存 GC 壓力大。

在現(xiàn)有 GC 能力下，我們對(duì) GC 優(yōu)化從以下幾個(gè)方面考慮：

1）減少垃圾產(chǎn)生：降低數(shù)據(jù)結(jié)構(gòu)或者緩沖區(qū)的開銷；

2）手動(dòng)管理內(nèi)存：使用內(nèi)存池，手動(dòng)管理內(nèi)存；

3）臟數(shù)據(jù)盡快釋放，增大空閑內(nèi)存比。

我們使用了以下 3 種 golang GC 優(yōu)化方法。

1）定制 golang HTTP 包：

調(diào)整 HTTP 協(xié)議 conn 數(shù)據(jù)結(jié)構(gòu)默認(rèn)分配讀寫緩沖區(qū)的大小，以及手動(dòng)維護(hù)讀寫緩存池，減少動(dòng)態(tài)開辟內(nèi)存的次數(shù)，降低 GC 壓力。

在 Go 語(yǔ)言原生的 HTTP 包中會(huì)為每個(gè)請(qǐng)求默認(rèn)分配 8KB 的緩沖區(qū)，讀、寫緩沖區(qū)各 4K。而在我們的服務(wù)場(chǎng)景中只有 GET 請(qǐng)求,服務(wù)需要的信息都包含在 HTTP header 中，并沒(méi)有 body，實(shí)際上不需要如此大的內(nèi)存進(jìn)行存儲(chǔ)，所以我們調(diào)小了讀寫緩沖區(qū)，將讀緩沖區(qū)調(diào)小到 1K，寫緩沖區(qū)調(diào)小到 32B，golang 的 bufio 在寫緩沖區(qū)較小時(shí)，會(huì)直接寫出。

從 golang 1.3 開始，HTTP 原生的包中已經(jīng)使用了sync.Pool 維護(hù)讀寫緩存池，但是 sync.Pool 中的數(shù)據(jù)會(huì)被自動(dòng)的回收，同樣會(huì)小量的增加 GC 壓力，我們此處自己維護(hù)緩存池來(lái)減少垃圾回收。

2）加快資源釋放：

原生的 HTTP 包默認(rèn)使用 keep-alive 的方式，小米搶購(gòu)場(chǎng)景下，惡意流量占用了大量的連接，我們通過(guò)主動(dòng)設(shè)置 response header 的 connection 為 close 來(lái)主動(dòng)關(guān)閉惡意連接，加快 goroutine 資源的釋放。

3）升級(jí)版本：

跟進(jìn)使用 golang 最新的版本，golang 后續(xù)的每個(gè)版本都有針對(duì) GC 能力的調(diào)整。

得益于開源技術(shù)力量，以及大秒系統(tǒng)在 GC 優(yōu)化上的努力，以及系統(tǒng)層的調(diào)優(yōu)，我們的 HTTP 限流層已經(jīng)可以余量前行。

從上圖可以看出，得益于 GC 的優(yōu)化，2015 年米粉節(jié)，每輪搶購(gòu)，HTTP 服務(wù)的內(nèi)存不會(huì)有特別大的抖動(dòng)。

10.2 HTTP 服務(wù)器內(nèi)存調(diào)優(yōu)之操作系統(tǒng)參數(shù)調(diào)整

我們的服務(wù)場(chǎng)景下絕大多數(shù)的請(qǐng)求數(shù)都是惡意請(qǐng)求，惡意請(qǐng)求通常都是短連接請(qǐng)求，大量的短連接會(huì)處于 timewait 狀態(tài)，幾分鐘之后才會(huì)釋放，這樣會(huì)占用大量的資源，通過(guò)調(diào)整內(nèi)核參數(shù)，盡快釋放或者重用 timewait 狀態(tài)的連接，減少資源的開銷。

具體參數(shù)調(diào)整如下：

net.ipv4.tcp_tw_recycle = 1 （打開TIME-WAIT sockets快速回收）

net.ipv4.tcp_tw_reuse = 1 （允許TIME-WAIT sockets復(fù)用）

net.ipv4.tcp_max_tw_buckets=10000  （降低系統(tǒng)連接數(shù)和資源占用，默認(rèn)為18w）

高并發(fā)場(chǎng)景下，操作系統(tǒng)層網(wǎng)絡(luò)模塊參數(shù)的調(diào)整，會(huì)起到事半功倍的效果。

10.3 沒(méi)有通信就談不上分布式系統(tǒng)

整個(gè)大秒系統(tǒng)模塊之間面臨的通信要求是非?？量痰?，Master 節(jié)點(diǎn)與 HTTP、Middle 節(jié)點(diǎn)要頻繁的廣播控制命令，dcacenter要實(shí)時(shí)的收集 HTTP、Middle 節(jié)點(diǎn)的監(jiān)控管理數(shù)據(jù)，HTTP 要將用戶的購(gòu)買請(qǐng)求路由到 Middle 節(jié)點(diǎn)之間，Middle 節(jié)點(diǎn)要返回給相應(yīng)的 HTTP 節(jié)點(diǎn)放號(hào)信息；

我們基于 TCP 定制了簡(jiǎn)單、高效的通信協(xié)議，對(duì)于 HTTP 層和 Middle 層通信，通信模塊能夠合并用戶請(qǐng)求，減少通信開銷，保障整個(gè)大秒系統(tǒng)的高效通信，增加服務(wù)的處理能力。

10.4 服務(wù)閉環(huán)設(shè)計(jì)

從上述搶購(gòu)的服務(wù)閉環(huán)架構(gòu)中可以看出，整個(gè)搶購(gòu)流程處理bigtap系統(tǒng)之外，還有 cart 服務(wù)，中心 counter 服務(wù)，這三者與 bigtap 系統(tǒng)構(gòu)成了一個(gè)數(shù)據(jù)流的閉環(huán)，但是在大秒最初的設(shè)計(jì)中，是沒(méi)有 counter 服務(wù)的，Middle層策略集群在放號(hào)的同時(shí)，又作為計(jì)數(shù)服務(wù)存在，但是整個(gè)搶購(gòu)流程卻是以商品加入購(gòu)物車代表最終的搶購(gòu)成功，這在設(shè)計(jì)上有一個(gè)漏洞，假如 bigtap 計(jì)數(shù)了，但是token 并沒(méi)有請(qǐng)求加購(gòu)物車成功，這是不合理的。為了保證整個(gè)系統(tǒng)的準(zhǔn)確性，我們?cè)黾恿擞?jì)數(shù)器服務(wù)，計(jì)數(shù)操作發(fā)生在加購(gòu)物車下游，bigtap 在從計(jì)數(shù)中心取出商品實(shí)時(shí)銷量，由此，構(gòu)成一個(gè)服務(wù)閉環(huán)設(shè)計(jì)。在提升了系統(tǒng)的準(zhǔn)確性，同時(shí)也保證了用戶體驗(yàn)。

10.5 技術(shù)的選擇要可控

我們一開始選擇使用 ZooKeeper 存放商品的配置信息，在搶購(gòu)活動(dòng)的過(guò)程伴隨著大量的配置變更操作，ZooKeeper 的 watch 機(jī)制不適合用于頻繁寫的場(chǎng)景，造成消息丟失，大秒前端集群狀態(tài)與配置不一致。

后來(lái)，我們將所有的配置信息存放在 Redis 中，基于通信模塊，在發(fā)生配置變更時(shí)，伴隨著一次配置項(xiàng)變更的廣播通知，大秒前端根據(jù)相應(yīng)的通知命令，拉取 Redis 中相應(yīng)的配置信息，變更內(nèi)存中配置及狀態(tài)。

11、“大秒”的幾點(diǎn)設(shè)計(jì)原則

在設(shè)計(jì)“大秒”的過(guò)程中，我們總結(jié)了下面這些原則：

1）分治是解決復(fù)雜問(wèn)題的通則：我們從第一代搶購(gòu)系統(tǒng)演進(jìn)到當(dāng)前的大秒系統(tǒng)，衍生出了很多服務(wù)，每個(gè)服務(wù)的產(chǎn)生都是為了專門解決一個(gè)問(wèn)題，分離整個(gè)復(fù)雜系統(tǒng)，針對(duì)每個(gè)服務(wù)需要解決的問(wèn)題，各個(gè)擊破，重點(diǎn)優(yōu)化。由此，才保障了秒殺體系整體性能、可靠性的提升；

2）服務(wù)化設(shè)計(jì)：系統(tǒng)解耦，增強(qiáng)系統(tǒng)的伸縮性與可靠性；

3）無(wú)狀態(tài)設(shè)計(jì)：增強(qiáng)系統(tǒng)的伸縮性，提升集群整體處理能力；

4）狀態(tài)數(shù)據(jù)局部化：相對(duì)于數(shù)據(jù)中心化，提升集群整體處理能力；

5）中心化監(jiān)控管理、熱備部署：既保證了服務(wù)的高可用性，又能夠提升開發(fā)和管理效率。隨著集群規(guī)模的增大以及管理數(shù)據(jù)的增多，分離管理信息到不同的數(shù)據(jù)管理節(jié)點(diǎn)，實(shí)現(xiàn)管理能力的擴(kuò)容。通常情況下，中小型分布式系統(tǒng)，單機(jī)管理能力即可滿足；

6）避免過(guò)度設(shè)計(jì)、過(guò)早的優(yōu)化：小步快跑，頻繁迭代；

7）沒(méi)有華麗的技術(shù)，把細(xì)小的點(diǎn)做好：不回避問(wèn)題，特別是在高并發(fā)系統(tǒng)中，一個(gè)細(xì)小的問(wèn)題，都可以引發(fā)整個(gè)服務(wù)雪崩。

12、Q&A

1）實(shí)時(shí)倉(cāng)庫(kù)怎么避免超賣？

我們的搶購(gòu)系統(tǒng)以加入購(gòu)物車代表購(gòu)買成功，因?yàn)橛脩粢I配件等，庫(kù)存是由計(jì)數(shù)器控制的，先限流，在計(jì)數(shù)，在可控的并發(fā)量情況下，不會(huì)出現(xiàn)超賣。

2）有了放號(hào)系統(tǒng)計(jì)算放號(hào)規(guī)則，為什么還需要一個(gè)外圍的 counter?

主要是 bigtap 到 cart 的環(huán)節(jié) token 有丟失，在 cart 之后再加一個(gè)計(jì)數(shù)器，保障銷量，bigtap 再讀取計(jì)數(shù)器的數(shù)據(jù)控制前端商品銷售狀態(tài)，整個(gè)延遲不超 3s。

3）HTTP 集群通過(guò) uuid hash 到 Middle，如果目標(biāo) Middle 已經(jīng)死掉怎么應(yīng)對(duì)？

這個(gè)問(wèn)題在文章中有強(qiáng)調(diào)，在我們的場(chǎng)景下，商品迅速賣完，這塊沒(méi)有做高可用，只是從代碼層面做 review，完善異常處理機(jī)制，并且通常情況下，middle 負(fù)載不是特別高，幾百次活動(dòng)下來(lái)，還沒(méi)出現(xiàn)過(guò)掛掉情況。

4）防刷系統(tǒng)是離線計(jì)算的嗎，還是有在線識(shí)別的策略？

基于日志，準(zhǔn)實(shí)時(shí)，因?yàn)檎?qǐng)求量比較大，專門搭了一套 Kafka 服務(wù)轉(zhuǎn)儲(chǔ)日志，基于 golang 開發(fā) logcollect 與 antiblack 模塊，可以達(dá)到很高的處理性能。

5）請(qǐng)問(wèn)如何模擬大量請(qǐng)求做測(cè)試？

我們遇到的情況是，由于壓測(cè)機(jī)單機(jī)端口限制造成早期不好測(cè)試，我們這邊壓測(cè)團(tuán)隊(duì)基于開源模塊開發(fā)了能夠模擬虛擬IP的模塊，打破了單機(jī)端口的限制。

6）即使廣播和 Redis 拉取商品配置信息，仍有可能配置信息不一致如何解決？

這個(gè)主要是商品的配置和狀態(tài)信息，不涉及到強(qiáng)一致性要求的場(chǎng)景，我們這樣可以在秒級(jí)達(dá)到最終一致性。

附錄：更多架構(gòu)設(shè)計(jì)方面的文章

[1] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章：

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

《簡(jiǎn)述移動(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》

《微信后臺(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)》》

《快速裂變：見證微信強(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開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》

《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問(wèn)量背后的技術(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)用場(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開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》

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

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

《新手入門：零基礎(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)之路》

>> 更多同類文章 ……

[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í)踐之路》

《新手入門：零基礎(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í)踐》

>> 更多同類文章 ……

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