整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
年期間你參與百度的搶紅包活動了嗎？但是對這場活動批判的聲音一直不絕于耳，我們在天天問討論了這個問題，來一起看看大家是怎么說的吧~enjoy~
百度春晚豪擲9億，能否達到其導流的目的？@問多多
今年，百度成為了春晚的獨家互動合作伙伴。在春晚期間，它總共送出價值9億人民幣的紅包。這次百度砸下重金，能否達到其導流的目的？
說下小問的情況，搖到手酸一共搖了2塊錢，結果提現時候發現還要下載各種百度全家桶安裝包，有點反感就直接卸載了。
（1）百度App本次春晚投放的目的還是擴大下載量，目前一二三線城市用戶滲透率上升空間不大，而且很多對百度已經有比較大的成見，空白手機用戶主要還是在四五六城市至十八線小鎮，沒有什么節目比春晚更強了。
9億的話如果能夠帶來900萬的下載量，一個用戶獲客成本也就100塊錢，很值。還不算廣告效益。至少大家知道了百度是App，不只是PC的搜索框，這個品牌認知對于百度非常重要。
（2）今年春晚百度非投不可，因為百度不投，就有頭條會投。抖音和百度爭奪獨家冠名非常激烈，即使百度的效果不理想，也能夠戰略阻止頭條在農村市場的進一步擴張。
其實頭條在農村用戶那里滲透率不足10%，這個是趣頭條的數據，我不知道準不準確，但是抖音可能是有的。
百度為什么要戰略防御頭條呢？因為兩家的盈利模式都是廣告公司，百度的廣告模式已經由大搜模式轉向到信息流模式了。
（3）百度App春晚分四輪進行，主要是搖一搖模式。參與的門檻相對還是比較考慮“用戶體驗”的，而抽獎的門檻的話，如果門檻越低，其實越鬧影子，難度越大，其實分的錢更實在。
我和答主一樣，基本上沒有去薅羊毛搶紅包的意愿，我這兩年過年時候可能要發出去2萬的紅包，當然不會寄希望于抽獎。但是不能說紅包大戰沒有效，其實類似我這樣的用戶行為已經不再具備一般用戶行為特征，靠自己的行為得出的結論無疑是有偏差的。這也是調查研究和結果反饋的意義所在。
（4）紅包大戰對于存量用戶的意義不再搶多少錢，而在于用戶提現的動作，換句話說，不是看Appstore以及安卓市場上的排名，而是去看有多少下載了App的用戶去綁卡，綁卡就意味著是活躍的真實用戶，其數據的準確率可以用來做征信，以及百度的金融業務即度小滿。如果不綁卡的話，有余額的話，App被卸載的概率會非常低。
（5）客觀去理解9億或者10億，這些是廣告主或者說品牌商的廣告費用，百度等于把這些金主的廣告費直接分給用戶，用戶在搶紅包的時候其實廣告主也有曝光的，并非是百度自己的現金池，可能會有廣告主的賬期存在，但是紅包大戰本身也是一個商業模式。
以上一孔之見。
有個疑問，百度瞄準的確實是三四線的下沉用戶，可是這部分用戶下載完了要提現，發現還要綁定銀行卡，有多少這部分的用戶會綁卡呢？就我身邊的親戚來說，他們大部分是不愿意隨便綁卡的，支付寶微信在市場上花了好幾年的功夫才讓他們敢于綁卡的。
引流肯定是有效果的，本人看到后既沒有參與也沒有提現。
說下我的行為路徑：
第一步：手機里沒下過百度APP，先打開了百度網頁，網頁上赫然幾個大字，下載APP領紅包，嗤笑一聲表示理解，下載了APP，最開始是和支付寶類似的集卡預熱活動，但是卡的種類也太多了吧，好像有7、8張，直接勸退了我（其實后來發現卡的種類雖多，卻并不難集，這也給活動運營們敲個種，別搞太多花花綠綠的，卡片數量也是學問，像人家支付寶搞5種卡片就不多不少了）
第二步：等到春晚主持人宣布搖紅包，四輪全部參與，開始狂搖，最后得了幾塊錢吧。
第三步：失望中準備提現，發現哎喲，還得等24小時審核，耐心已經被磨沒，我要的就是新年搶紅包的這個氣氛，還搞個緩沖時間。
第四步：24小時過去，準備提現，發現，原來還是下載N個APP一個一個領啊，再想一下還有綁卡什么的操作，算了放棄了。
綜上，這個活動讓我覺得自己是一根羊毛被薅了，所以我怒卸百度APP，別說給百度系其他APP導流，百度APP我都不要了！我應該是個典型用戶吧。
百度：下載一天，提現完卸載，收了9.58。
支付寶：掃福、答題、喂雞、澆花、線下支付、操作10天，領了1.68，真棒。
論復雜的用戶心理。
不能單單拿百度的春晚營銷來說話，要對比一下百度和其他競爭對手的風格。
以百度和支付寶為例，百度只是單獨場景的一次運用，僅僅在春晚搖紅包，支付寶是一系列的運營過程，并且在運營過程中充分給客戶游戲一般的體驗。
由于它只是一個單次活動場景，用戶的潛在邏輯是這是一項任務并且獲得報酬。隨后百度在后端設置上，需要用戶各種下載APP才能領紅包，這個對于用戶來說會覺得投入產出比不成比例。
支付寶是通過游戲化的運營場景，讓客戶轉移了參與目標大家在游戲的過程中反而淡化了利益訴求，更加像是一次較長時間的社交活動，所以即使麻煩一些用戶也可以忍受。
說到底，還是初心的問題，赤裸裸的商業活動和體驗班的社交營銷是完全不同的感受。
是否達到引流？答案是：是的
但究其根本，是否只有引流這一個目的？答案是：絕對不是。
引流、品牌運營、產品推送 這三個目的比起來，可能引流就顯得不是那么明顯。
產品推送：從每天打開百度后的任務（給抽獎機會）就能看出來有這不同的任務去做，而最主要的是、需要一定用戶消耗的就是下載好看、全民小視頻、看多多，起碼在這個活動前我對這些APP并不了解，百度可能借此機會將這3款軟件進行強推，相信相關產品線過年都加班了吧。
三個軟件在激活用戶上也都用獎勵抽獎次數進行了運營，如看一個視頻之類，并且達到要求后系統提示，可以直接根據提示進行跳轉也是很人性化的設定。
品牌營銷：去除產品的思維，單說百度，用戶一聽百度搜索、度娘、百度一下、百度圖片，而對于其他產品可能認知度就比較差了，這個活動還有一個目的就是讓用戶知道：小視頻領域百度也在做，新聞也在做……
想是一方面，做又是另一方面。
多個APP，用戶早就眼花繚亂，操作簡單，用戶只需要點點點，導致引流來的用戶，只要有點潔癖，就會把軟件統統刪掉，引流來的用戶并不能真正的觸及產品，還不如來個：分享新年餃子視頻就送1元來的塊，起碼用戶有了沉默成本。
至于活動內容本身（集卡），樓上說過數量有學問，我覺得有道理，但可能是考慮到不想和支付寶重復，湊成了10個，其實也還行，我在這里不累述。
歡迎討論！探討大廠模式。
結論先行，目的已然達到。
光看整體資金規模9億，一看很大，但是有多少用戶被參與，審核，提現攔了一步又一步，真正的成本想必并沒有那么夸張。
說下目的，通過春晚的覆蓋進行下沉，一二線城市的整個滲透不用多言，我不怎么用用百度，但是肯定是知道的。
對于一二線城市的用戶，幾塊錢紅包的誘惑可能，不會一步一步下載APP，各種注冊審核。但是對于三四五線城市就不是了，他們沒有被互聯網紅利覆蓋過，所以當微信，支付寶，百度們來“撒錢”的時候，有多少這樣的目標人群能夠把持住自己。
下了APP——注冊了賬號——成為了用戶——使用了產品。
首先說，不管是不是搖紅包的玩法，哪怕是個其他的玩法，跟春晚合作，一樣可以達到導流的目的，只是中國人對春節收紅包這個傳統概念一直很認同。
亮點1：搖一搖是一個主要玩法，分時段的搖一搖瓜分是一個很好的設計流程，如果搖一次就結束，會減少用戶粘性和興趣，甚至有的用戶會認為沒玩夠，這樣設計，即使第一次沒得到多少紅包，用戶的心里反應是還有下次。選擇繼續下一輪的用戶會占大比例。
亮點2：在搖一搖結束的閑時，用戶可以下載百度推薦的一些列產品并領取紅包。這一項設計是對百度和用戶都是有利的，但是個人認為大多數用戶會選擇在某一段閑時一次性全部下載完畢，這樣雖然下載量有了，但是又有多少人下載后回去大概體驗一下產品呢，都是下載完一個就繼續下一個。
如果這里的流程能完善下，或許更能達到百度想要的效果，比如分時段性的引導下載，吊著用戶胃口，比如8:00搖完后，引導下載一個，并模糊的告知下一個閑暇時段下載可領取88元紅包，并不是一下子完全告知用戶下載可得多少紅包，也不是一下子全都堆給用戶。
導流是肯定有的吧。
只是導了多少和留存多少的問題。
說活動惡心，百度也是沒有辦法，這種商業活動很多人都在玩，淘寶集能量也是N個App去簽到，但是百度錯就錯在，這一切來得太突然了，沒有提前宣告（或許可以，以全家桶集體拜的喜慶方式提前告知，讓用戶有心理預期），沒有其他選擇（要不讓我選就在本App領取不下載其他，但紅包金額折半也可以，雖然這個方案估計不可能）。讓大家興沖沖去搶紅包的時候，卻在大家沒有預期下強制下載一堆APP，沒有與民同樂反而處處都是商業味。
用戶失望，活動失敗也不是什么怪事了。
用紅包吸引用戶，追逐的是紅包，會隨紅包水漲船高，而不是對內容對產品的真正的認可，但也會有保留一部分用戶，這部分是一些什么樣的用戶呢，會是一些想繼續參與搶紅包活動的用戶以及懶得管理各個app的用戶，如果擁有這樣的用戶也算有些價值，但價值不大，因為這樣的用戶傳播到用戶群也會是同等的用戶，從而形成負循環。
我是百度的長期使用者，很長時間我都保留百度這個app，直到有一天我發現可以從手機系統里自帶的網站中登錄百度，從此以后開始卸載百度，只有在什么時候需要百度的時候才會點開，這會是以后所有軟件的常態，用的時候會啟動，不用會刪除以此來節省空間和頁面。
就像軟件商店中，需要的秒開一樣，用完即退，除非里面有可以與用戶產生互動的設計，否則很難吸引像我這樣，要求效率的人。
每個app給自己定位不同，希望每一個app最后都能找到屬于自己的定位，提供更好的內容服務以及用戶體驗，才是所有軟件的生存之道，否則再多的激烈也只是徒勞。
用戶不一樣，所激勵也是不同，沒有說紅包激勵不好，只是相對人群，像我這樣的人群，就完全沒有必要，不會去參與，而且對我沒我任何誘惑，不如實際多來點干貨福利。希望對所有互聯網的精英們有所幫助。
問題鏈接：https://wen.woshipm.com/question/detail/5vc898.html
對于百度紅包你有什么想說的嗎，來天天問和小伙伴們交流一下吧~
【天天問每周精選】第63期：互聯網的春節效應，會讓誰翻身？
【天天問每周精選】第62期：我們要不要緊緊黏住用戶？
【天天問每周精選】第61期：據說大部分的產品經理都不喜歡自己的產品
【天天問每周精選】第60期：納悶，天氣類軟件是怎么活下來的？
【天天問每周精選】第59期：價格補貼，貼著貼著把自己貼進去了
【天天問每周精選】第58期：「曇花一現」 的產品，是否算成功？
【天天問每周精選】第57期：為爛產品做運營，你是什么感受？
【天天問每周精選】第56期：我有些idea想找你聊聊
【天天問每周精選】第55期：了解抽獎設計背后的故事
【天天問每周精選】第54期：一年四季蹭熱點，什么時候是個頭啊
【天天問每周精選】第53期：你準備剁手了嗎？來聊聊雙十一的需求、玩法及未來
精選問題每周有，歡迎食用~配合回復味道更佳(∩_∩)
本欄目由天天問小編@Tracy 編輯，歡迎大家踴躍提問，一起交流。
題圖來自Unsplash，基于CC0協議
然看到了《扛住 100 億次請求——如何做一個“有把握”的春晚紅包系統》一文，看完以后，感慨良多，收益很多。
圖片來自 Pexels
正所謂他山之石，可以攻玉，雖然此文發表于 2015 年，我看到時已經過去良久，但是其中的思想仍然可以為很多后端設計借鑒。
同時作為一名微信后端工程師，看完以后又會思考，學習了這樣的文章以后，是否能給自己的工作帶來一些實際的經驗呢?所謂紙上得來終覺淺，絕知此事要躬行，能否自己實踐一下 100 億次紅包請求呢?
否則讀完以后腦子里能剩下的東西不過就是 100 億，1400 萬 QPS 整流這樣的字眼，剩下的文章將展示作者是如何以此過程為目標，在本地環境的模擬了此過程。
實現的目標：單機支持 100 萬連接，模擬了搖紅包和發紅包過程，單機峰值 QPS 6 萬，平穩支持了業務。
注：本文以及作者所有內容，僅代表個人理解和實踐，過程和微信團隊沒有任何關系，真正的線上系統也不同，只是從一些技術點進行了實踐，請讀者進行區分。
背景知識
QPS：Queries per second(每秒的請求數目)。
PPS：Packets per second(每秒數據包數目)。
搖紅包：客戶端發出一個搖紅包的請求，如果系統有紅包就會返回，用戶獲得紅包。
發紅包：產生一個紅包里面含有一定金額，紅包指定數個用戶，每個用戶會收到紅包信息，用戶可以發送拆紅包的請求，獲取其中的部分金額。
確定目標
在一切系統開始以前，我們應該搞清楚我們的系統在完成以后，應該有一個什么樣的負載能力。
用戶總數
通過文章我們可以了解到接入服務器 638 臺，服務上限大概是 14.3 億用戶， 所以單機負載的用戶上限大概是 14.3 億/638 臺=228 萬用戶/臺。
但是目前中國肯定不會有 14 億用戶同時在線，參考的說法：
http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html 2016 年 Q2 微信用戶大概是 8 億，月活在 5.4 億左右。所以在 2015 年春節期間，雖然使用的用戶會很多，但是同時在線肯定不到 5.4 億。
服務器數量
一共有 638 臺服務器，按照正常運維設計，我相信所有服務器不會完全上線，會有一定的硬件冗余，來防止突發硬件故障。假設一共有 600 臺接入服務器。
單機需要支持的負載數
每臺服務器支持的用戶數：5.4 億/ 600=90 萬。也就是平均單機支持 90 萬用戶。
如果真實情況比 90 萬更多，則模擬的情況可能會有偏差，但是我認為 QPS 在這個實驗中更重要。
單機峰值 QPS
文章中明確表示為 1400 萬 QPS。這個數值是非常高的，但是因為有 600 臺服務器存在，所以單機的 QPS 為 1400 萬/600=約為 2.3 萬 QPS。
文章曾經提及系統可以支持 4000 萬 QPS，那么系統的 QPS 至少要到 4000 萬/ 600=約為 6.6 萬，這個數值大約是目前的 3 倍，短期來看并不會被觸及。但是我相信應該做過相應的壓力測試。
發放紅包
文中提到系統以 5 萬個每秒的下發速度，那么單機每秒下發速度 50000/600=83 個/秒，也就是單機系統應該保證每秒以 83 個的速度下發即可。
最后考慮到系統的真實性，還至少有用戶登錄的動作，真實的系統還會包括聊天這樣的服務業務。
最后整體看一下 100 億次搖紅包這個需求，假設它是均勻地發生在春節聯歡晚會的 4 個小時里。
那么服務器的 QPS 應該是 10000000000/600/3600/4.0=1157。也就是單機每秒 1000 多次，這個數值其實并不高。
如果完全由峰值速度 1400 萬消化 10000000000/(1400*10000)=714 秒，也就是說只需要峰值堅持 11 分鐘，就可以完成所有的請求。
可見互聯網產品的一個特點就是峰值非常高，持續時間并不會很長。
總結：從單臺服務器看，它需要滿足下面一些條件。
①支持至少 100 萬連接用戶。
②每秒至少能處理 2.3 萬的 QPS，這里我們把目標定得更高一些 ，分別設定到了 3 萬和 6 萬。
③搖紅包：支持每秒 83 個的速度下發放紅包，也就是說每秒有 2.3 萬次搖紅包的請求，其中 83 個請求能搖到紅包，其余的 2.29 萬次請求會知道自己沒搖到。
當然客戶端在收到紅包以后，也需要確?？蛻舳撕头掌鲀蛇叺募t包數目和紅包內的金額要一致。
因為沒有支付模塊，所以我們也把要求提高一倍，達到 200 個紅包每秒的分發速度。
④支持用戶之間發紅包業務，確保收發兩邊的紅包數目和紅包內金額要一致。同樣也設定 200 個紅包每秒的分發速度為我們的目標。
想要完整地模擬整個系統實在是太難了，首先需要海量的服務器，其次需要上億的模擬客戶端。
這對我來說是辦不到，但是有一點可以確定，整個系統是可以水平擴展的，所以我們可以模擬 100 萬客戶端，再模擬一臺服務器，那么就完成了 1/600 的模擬。
和現有系統區別：和大部分高 QPS 測試的不同，本系統的側重點有所不同。
我對兩者做了一些對比：
基礎軟件和硬件
軟件
Golang 1.8r3，Shell，Python(開發沒有使用 C++ 而是使用了 Golang，是因為使用 Golang 的最初原型達到了系統要求。雖然 Golang 還存在一定的問題，但是和開發效率比，這點損失可以接受)。
服務器操作系統：Ubuntu 12.04。
客戶端操作系統：debian 5.0。
硬件環境
服務端：dell R2950。8 核物理機，非獨占有其他業務在工作，16G 內存。這臺硬件大概是 7 年前的產品，性能要求應該不是很高。
服務器硬件版本：
服務器 CPU 信息：
客戶端：esxi 5.0 虛擬機，配置為 4 核 5G 內存。一共 17 臺，每臺和服務器建立 6 萬個連接，完成 100 萬客戶端模擬。
技術分析和實現
單機實現 100 萬用戶連接
這一點來說相對簡單，筆者在幾年前就早完成了單機百萬用戶的開發以及操作?，F代的服務器都可以支持百萬用戶。相關內容可以查看 Github 代碼以及相關文檔、系統配置以及優化文檔。
參考鏈接：
https://github.com/xiaojiaqi/C1000kPracticeGuide https://github.com/xiaojiaqi/C1000kPracticeGuide/tree/master/docs/cn 3 萬 QPS
這個問題需要分 2 個部分來看客戶端方面和服務器方面。
①客戶端 QPS
因為有 100 萬連接連在服務器上，QPS 為 3 萬。這就意味著每個連接每 33 秒，就需要向服務器發一個搖紅包的請求。
因為單 IP 可以建立的連接數為 6 萬左右，有 17 臺服務器同時模擬客戶端行為。我們要做的就是保證在每一秒都有這么多的請求發往服務器即可。
其中技術要點就是客戶端協同。但是各個客戶端的啟動時間，建立連接的時間都不一致，還存在網絡斷開重連這樣的情況，各個客戶端如何判斷何時自己需要發送請求，各自該發送多少請求呢?
我是這樣解決的：利用 NTP 服務，同步所有的服務器時間，客戶端利用時間戳來判斷自己的此時需要發送多少請求。
算法很容易實現：假設有 100 萬用戶，則用戶 id 為 0-999999。要求的 QPS 為 5 萬，客戶端得知 QPS 為 5 萬，總用戶數為 100 萬，它計算 100 萬/5 萬=20，所有的用戶應該分為 20 組。
如果 time()%20==用戶id%20，那么這個 id 的用戶就該在這一秒發出請求，如此實現了多客戶端協同工作。每個客戶端只需要知道總用戶數和 QPS 就能自行準確發出請求了。
擴展思考：如果 QPS 是 3 萬這樣不能被整除的數目，該如何做?如何保證每臺客戶端發出的請求數目盡量的均衡呢?
②服務器 QPS
服務器端的 QPS 相對簡單，它只需要處理客戶端的請求即可。但是為了客觀了解處理情況，我們還需要做 2 件事情。
第一：需要記錄每秒處理的請求數目，這需要在代碼里埋入計數器。
第二：需要監控網絡，因為網絡的吞吐情況，可以客觀的反映出 QPS 的真實數據。
為此，我利用 Python 腳本結合 ethtool 工具編寫了一個簡單的工具，通過它我們可以直觀地監視到網絡的數據包通過情況如何。它可以客觀地顯示出我們的網絡有如此多的數據傳輸在發生。
工具截圖：
搖紅包業務
搖紅包的業務非常簡單，首先服務器按照一定的速度生產紅包。紅包沒有被取走的話，就堆積在里面。
服務器接收一個客戶端的請求，如果服務器里現在有紅包就會告訴客戶端有，否則就提示沒有紅包。
因為單機每秒有 3 萬的請求，所以大部分的請求會失敗。只需要處理好鎖的問題即可。
我為了減少競爭，將所有的用戶分在了不同的桶里。這樣可以減少對鎖的競爭。
如果以后還有更高的性能要求，還可以使用高性能隊列——Disruptor 來進一步提高性能。
注意，在我的測試環境里是缺少支付這個核心服務的，所以實現的難度是大大地減輕了。
另外提供一組數字：2016 年淘寶的雙 11 的交易峰值僅僅為 12 萬/秒，微信紅包分發速度是 5 萬/秒，要做到這點是非常困難的。
參考鏈接：
http://mt.sohu.com/20161111/n472951708.shtml 發紅包業務
發紅包的業務很簡單，系統隨機產生一些紅包，并且隨機選擇一些用戶，系統向這些用戶提示有紅包。
這些用戶只需要發出拆紅包的請求，系統就可以隨機從紅包中拆分出部分金額，分給用戶，完成這個業務。同樣這里也沒有支付這個核心服務。
監控
最后，我們需要一套監控系統來了解系統的狀況，我借用了我另一個項目里的部分代碼完成了這個監控模塊，利用這個監控，服務器和客戶端會把當前的計數器內容發往監控，監控需要把各個客戶端的數據做一個整合和展示。
同時還會把日志記錄下來，給以后的分析提供原始數據。線上系統更多使用 opentsdb 這樣的時序數據庫，這里資源有限，所以用了一個原始的方案。
參考鏈接：
https://github.com/xiaojiaqi/fakewechat 監控顯示日志大概這樣：
代碼實現及分析
在代碼方面，使用到的技巧實在不多，主要是設計思想和 Golang 本身的一些問題需要考慮。
首先 Golang 的 goroutine 的數目控制，因為至少有 100 萬以上的連接，所以按照普通的設計方案，至少需要 200 萬或者 300 萬的 goroutine 在工作，這會造成系統本身的負擔很重。
其次就是 100 萬個連接的管理，無論是連接還是業務都會造成一些心智的負擔。
我的設計是這樣的：
①首先將 100 萬連接分成多個不同的 SET，每個 SET 是一個獨立、平行的對象。
每個 SET 只管理幾千個連接，如果單個 SET 工作正常，我只需要添加 SET 就能提高系統處理能力。
②其次謹慎地設計了每個 SET 里數據結構的大小，保證每個 SET 的壓力不會太大，不會出現消息的堆積。
③再次減少了 gcroutine 的數目，每個連接只使用一個 goroutine，發送消息在一個 SET 里只有一個 gcroutine 負責，這樣節省了 100 萬個 goroutine。
這樣整個系統只需要保留 100 萬零幾百個 gcroutine 就能完成業務。大量的節省了 CPU 和內存。
系統的工作流程大概是：每個客戶端連接成功后，系統會分配一個 goroutine 讀取客戶端的消息，當消息讀取完成，將它轉化為消息對象放至在 SET 的接收消息隊列，然后返回獲取下一個消息。
在 SET 內部，有一個工作 goroutine，它只做非常簡單而高效的事情，它做的事情如下。
檢查 SET 的接受消息，它會收到 3 類消息：
對于第 1 種消息是這樣處理的，從客戶端拿到搖紅包請求消息，試圖從 SET 的紅包隊列里獲取一個紅包，如果拿到了就把紅包信息返回給客戶端，否則構造一個沒有搖到的消息，返回給對應的客戶端。
對于第 2 種消息，只需簡單地從隊列里拿走消息，轉發給后端的聊天服務隊列即可，其他服務會把消息轉發出去。
對于第 3 種消息，SET 只需要根據消息里的用戶 id，找到 SET 里保留的用戶連接對象，發回去就可以了。
對于紅包產生服務，它的工作很簡單，只需要按照順序輪流在每個 SET 的紅包產生隊列里放置紅包對象就可以了。
這樣可以保證每個 SET 里都是公平的，其次它的工作強度很低，可以保證業務穩定。
參考鏈接：
https://github.com/xiaojiaqi/10billionhongbaos 實踐
實踐的過程分為三個階段：
階段 1
分別啟動服務器端和監控端，然后逐一啟動 17 臺客戶端，讓它們建立起 100 萬的鏈接。在服務器端，利用 ss 命令統計出每個客戶端和服務器建立了多少連接。
命令如下：
Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: “{print $8}” | sort | uniq –c’ 結果如下：
階段 2
利用客戶端的 HTTP 接口，將所有的客戶端 QPS 調整到 3 萬，讓客戶端發出 3W QPS 強度的請求。
運行如下命令：
觀察網絡監控和監控端反饋，發現 QPS 達到預期數據，網絡監控截圖：
在服務器端啟動一個產生紅包的服務，這個服務會以 200 個每秒的速度下發紅包，總共 4 萬個。
此時觀察客戶端在監控上的日志，會發現基本上以 200 個每秒的速度獲取到紅包。
等到所有紅包下發完成后，再啟動一個發紅包的服務，這個服務系統會生成 2 萬個紅包，每秒也是 200 個，每個紅包隨機指定 3 位用戶，并向這 3 個用戶發出消息，客戶端會自動來拿紅包，最后所有的紅包都被拿走。
階段 3
利用客戶端的 HTTP 接口，將所有的客戶端 QPS 調整到 6 萬，讓客戶端發出 6W QPS 強度的請求。
如法炮制，在服務器端，啟動一個產生紅包的服務，這個服務會以 200 個每秒的速度下發紅包，總共 4 萬個。
此時觀察客戶端在監控上的日志，會發現基本上以 200 個每秒的速度獲取到紅包。
等到所有紅包下發完成后，再啟動一個發紅包的服務，這個服務系統會生成 2 萬個紅包，每秒也是 200 個，每個紅包隨機指定 3 位用戶，并向這 3 個用戶發出消息，客戶端會自動來拿紅包，最后所有的紅包都被拿走。
最后，實踐完成。
分析數據
在實踐過程中，服務器和客戶端都將自己內部的計數器記錄發往監控端，成為了日志。
我們利用簡單 Python 腳本和 gnuplt 繪圖工具，將實踐的過程可視化，由此來驗證運行過程。
第一張是客戶端的 QPS 發送數據：
這張圖的橫坐標是時間，單位是秒，縱坐標是 QPS，表示這時刻所有客戶端發送的請求的 QPS。
圖的第一區間，幾個小的峰值，是 100 萬客戶端建立連接的， 圖的第二區間是 3 萬 QPS 區間，我們可以看到數據比較穩定地保持在 3 萬這個區間。最后是 6 萬 QPS 區間。
但是從整張圖可以看到 QPS 不是完美地保持在我們希望的直線上。
這主要是以下幾個原因造成的：
①當非常多 goroutine 同時運行的時候，依靠 sleep 定時并不準確，發生了偏移。
我覺得這是 Golang 本身調度導致的。當然如果 CPU 比較強勁，這個現象會消失。
②因為網絡的影響，客戶端在發起連接時，可能發生延遲，導致在前 1 秒沒有完成連接。
③服務器負載較大時，1000M 網絡已經出現了丟包現象，可以通過 ifconfig 命令觀察到這個現象，所以會有 QPS 的波動。
第二張是服務器處理的 QPS 圖：
和客戶端相對應，服務器也存在 3 個區間，和客戶端的情況很接近。但是我們看到了在大概 22：57 分，系統的處理能力就有一個明顯的下降，隨后又提高的尖狀，這說明代碼還需要優化。
整體觀察可以發現，在 3 萬 QPS 區間，服務器的 QPS 比較穩定，在 6 萬 QSP 時候，服務器的處理就不穩定了。我相信這和我的代碼有關，如果繼續優化的話，還應該能有更好的效果。
將兩張圖合并起來：
基本是吻合的，這也證明系統是符合預期設計的。
這是紅包生成數量的狀態變化圖：
非常穩定。
這是客戶端每秒獲取的搖紅包狀態：
可以發現 3 萬 QPS 區間，客戶端每秒獲取的紅包數基本在 200 左右，在 6 萬 QPS 的時候，以及出現劇烈的抖動，不能保證在 200 這個數值了。
我覺得主要是 6 萬 QPS 時候，網絡的抖動加劇了，造成了紅包數目也在抖動。
最后是 Golang 自帶的 pprof 信息，其中有 GC 時間超過了 10ms, 考慮到這是一個 7 年前的硬件，而且非獨占模式，所以還是可以接受。
總結
按照設計目標，我們模擬和設計了一個支持 100 萬用戶，并且每秒至少可以支持 3 萬 QPS，最多 6 萬 QPS 的系統，簡單模擬了微信的搖紅包和發紅包的過程，可以說達到了預期的目的。
如果 600 臺主機每臺主機可以支持 6 萬 QPS，只需要 7 分鐘就可以完成 100 億次搖紅包請求。
雖然這個原型簡單地完成了預設的業務，但是它和真正的服務會有哪些差別呢?
我羅列了一下：
參考資料：
https://github.com/xiaojiaqi/C1000kPracticeGuide
https://github.com/xiaojiaqi/fakewechat/wiki/Stress-Testing-in-the-Cloud
https://github.com/xiaojiaqi/fakewechat/wiki/Design
http://techblog.cloudperf.net/2016/05/2-million-packets-per-second-on-public.html
http://huoding.com/2013/10/30/296
https://gobyexample.com/non-blocking-channel-operations
作者：xiaojiaqi
來源：Github
讀：本文整理自高可用架構與數列科技聯合舉辦的技術沙龍，數列科技資深架構師徐漢彬的主題演講。圍繞“峰值流量下的高并發實踐”，主要介紹了其在騰訊QQ會員活動平臺的高可用架構實踐。以下為演講摘錄。
今天分享的主題的是《面向大規模流量活動的高可用架構實踐》，在開始之前先做個簡單的自我介紹，我叫徐漢彬，在進入數列科技之前負責過QQ會員活動運營平臺，把這個平臺從日PV百萬級別做到10億級別，在應對大流量活動這一塊積累了一定的經驗，今天就這個主題方向跟大家做一個探討。
分享的內容主要分為三個部分：
1.大流量活動的系統擴容評估方法
2.系統高可用架構設計實踐
3.大規模流量活動的實踐案例
大流量活動有多種形式，除了我們常見的電商大促（雙11、618等），近幾年還興起了一種新形式——直播賣貨。一個知名主播在比較短的時間里，引導粉絲大量下單，這是一種典型的大流量場景，對系統的穩定性發出較高挑戰。
另外一種比較常見的活動形式是營銷活動，例如春節紅包、周年慶。
活動的流量來源，包括內部資源、外部付費購買的廣告資源和第三方合作導流。公司在活動上投入了大量的資金，參與用戶眾多，如果活動中途出現問題，不僅對產品口碑的影響非常負面，而且會有金錢損失，還涉及到與第三方合作失敗的問題。
舉個例子，假設你的活動跟春晚合作，春晚到了某個環節讓大家拿起手機現場掃碼，這時系統掛了，掃碼失敗，這種情形就非常尷尬。遇到這種情況，第一個找你的可能不是你的領導，而是外部的第三方合作商，由此可見，關鍵時刻的系統高可用有多重要。
大流量活動面臨的挑戰主要分為三個部分。
第一個挑戰是流量評估難，擴容的量級并不是張口就來，如果你跟運維說要擴充10倍容量，他一定會反問你為什么，你要拿出擴容的合理依據。
第二個挑戰是架構擴容難，即使我們評估出了比較準確的流量峰值，又該怎么進行系統擴容呢？現代IT系統架構的復雜度越來越高，尤其是現在流行的微服務架構，它的節點數越來越多，服務之間的調用關系非常復雜，鏈路的梳理本身也是一大難點。
第三個挑戰是怎么進行高可用實施。我們把流量評估和鏈路梳理擴容都做好了，活動在大流量到來的那天就沒有問題了嗎？當然不是，所以第三個問題就是怎么進行高可用實施。
想要解決上述挑戰，繞不開業務和系統的雙重復雜度問題。
微服務架構的復雜性，加之業務的復雜性，使得整個系統錯綜復雜、難以被人類理解。即使是公司的架構師、業務研發同學也很難講清楚系統整個鏈路的每一個細節和服務之間的調用關系，因為此時的系統已經是一張龐大又相互交織的的網絡了。
要解決流量評估的問題就得進行精細的鏈路梳理，梳理的第一步就是畫架構簡圖，把每個架構大的模塊畫出來，再根據架構簡圖進行業務功能鏈路拆解。
部分鏈路
鏈路圖梳理完成后，我們就可以開始預估擴容量了，這里涉及到三個重要的指標：推廣量、環節轉化率、單UV的請求總數。
第一個指標推廣量，一般情況下會以每秒廣告的曝光量計算。將不同廣告渠道的曝光量加起來就能得到預估的推廣量級了。
還有一種方式是計算APP應用高峰每秒用戶的登錄數，這個數值約等于推廣的每秒曝光量。
一般預測的每秒推廣量都在系統現有容量的10倍以上，按這個推廣量去擴容，系統基本沒有問題，但會它會造成比較嚴重的資源浪費。
這時則需要用第二個參數來輔佐我們進行更細致的評估，它叫做環節轉化率。以紅包活動為例，用戶看見紅包活動，但不一定會點擊進入頁面，進入頁面也不一定會領取紅包，每一個環節都有環節轉化率。
預估環節轉化率一般有兩種方法，一種是依據過往的經驗數據進行估算；另一種就是提前演習，提前給部分用戶推送活動，快速準確地收集到每一個環節轉化率，有條件的公司一般會采用這種方式。
還有一個參數是我們需要特別注意的，就是單UV的請求總數，為什么要特別關注呢？
因為用戶進入一個活動頁面，他可能會查詢個人信息、查看活動記錄，通常不止一個請求動作，所以你在計算后端壓力時不能只算用戶進入活動的每秒峰值，還要算上其他請求動作。假設用戶平均有4個請求動作，那你的流量就要乘以4，它有一個放大效應。
通過前面3個指標我們就能計算出后端會承受多少流量壓力，進而得出擴容的預估值。最后把擴容容量設置為預估值的3倍，這個3倍并不是憑空臆想，而是從過往大量的活動擴容經驗中總結得來的規律，活動當天的峰值通常是常規均值的3倍。
具體怎么計算咱們來舉個例子，假設我們是100/S的曝光量，只有60%用戶進入了領取頁面，這其中又只有50%點擊了領取按鈕，那后端收到的請求是30/S，根據單UV的請求總數來說，整個后端最少要支撐120/S的壓力，加上3倍原則那么后端最終的擴容也就是360/S。領取頁面的流量峰值則為180/S，這時你帶著數據去找運維擴容就有理有據了。
某活動容量評估得到結果是9.6W/S，根據三倍原則，整個業務鏈路要擴容到30W/S，但是，在實操擴容過程中會發現部分應用很難擴容。舉個例子，像Web server這種很容易做平行擴容，只要機器足夠就可以擴容上去，但有些接口日常也就2000-3000/S的QPS，要擴到10萬QPS基本就是不可能的，也沒有那么多的資源和精力。這就涉及到擴容的具體實踐了，也是我們接下來要說的系統高可用架構設計的實踐內容。
通常來說，我們系統高可用架構實踐有三大擴容要素：全鏈路QPS、機器帶寬、存儲大小。
全鏈路QPS最容易被大家理解，我們也最關注，就不做過多的展開。
機器帶寬問題，流量越大越容易遇到。假設CGI請求達到10W/S，通常它的請求存儲不是一次，當時我們的常規業務請求存儲高達7-8次，包括查詢活動配置、查詢用戶參與記錄、查詢其他關聯信息等。這個10W/S就意味存儲端需要承受大幾十萬每秒甚至百萬每秒的量，如果一個存儲占1KB或者大幾百KB，在這個量級下存儲數據就相當龐大了，使用百兆級別網卡顯然就會遇到網絡帶寬瓶頸問題。
接下來說說存儲大小，這里說的存儲大小通常不是指硬盤的存儲大小，而是指內存，它也比較容易遇到瓶頸。大多數公司有使用Redis類的Key-value存儲，也有部分公司使用自研的Key-value存儲，通常寫入的數據會先寫入內存，再通過定時淘汰機制，同步到本地的SSD或者磁盤。在大流量場景下，內存很容易被寫滿，如果沒有事前評估，活動當天幾百G的內存會瞬間被寫滿。
還有一個不得不提的內容就是靜態資源，它是我們網頁請求的圖片、JavaScript和CSS樣式，通常它的瓶頸不在系統本身。一般情況下，如果不考慮帶寬的限制，在一臺配置很普通的機器上搭建一個Nginx來壓測靜態資源的請求性能，可以輕松達到數千QPS。但是，如果考慮到靜態資源的大小，加上單個用戶打開一個頁面就會請求很多靜態資源的實際情況，請求的靜態資源的大小很較容易就超過1M了。這時第一個撐不住的就是機器的出口帶寬，而不是靜態資源服務器本身的性能。
針對靜態資源問題，我們有常用的應對方法——離線包推送機制。在活動開始前幾天就把靜態資源推送到活躍用戶的的手機里，這樣活動當天九成以上的流量都是本地的，他根本沒有發起網絡請求，以此來解決CDN的請求壓力，解決帶寬問題。
完成擴容只能說在理論上沒問題，接下來說說高可用架構建設的關鍵要點。概括起來就是幾個點：過載保護、柔性可用、容災建設、輕重分離、監控體系、數據對賬。
監控體系很重要，我們需要探知這個系統處于什么狀態，并且出現問題時需要一些方案去應對它。
前面的分享提到過一個問題，有些接口日常也就2000-3000/S的量，沒有那么多的資源和精力擴到10萬/s， 那怎么辦呢？
關于系統鏈路架構優化，我們常用的方式有三種，第一種是異步化，這個好理解，暫時沒有這個能力執行完，就放到消息隊列里慢慢消化。第二種是內存級的緩存，把需要訪問的數據提前放到內存級的Cache里。第三種是服務降級，這個比較常用，就不做過多介紹了。通過這些方法就可以把鏈路的性能提升起來。
關于過載保護它的的核心目標是部分不可用至少比徹底不可重要強，主要的實現手段是進行分層流量控制。這些層級包含推廣層、前端層、CGI層和后端服務層。針對推廣層，只能在最壞的情況使用，因為它要對廣告進行下架處理，不到萬不得已，公司也不愿意采用這個方式，它也會影響活動的業務效果。針對前端層，可以實現隨機彈出倒計時，限制用戶1分鐘內不能發起新的網絡請求，有助于削平流量峰值。其他流量控制層的實現大同小異，不做過多的展開。
關于部署，我們應該把重要的核心的一些操作給保護起來，例如，在上述案例中，比較重要的是發貨，它不應該被其他操作影響。如果查詢操作不可用，用戶再刷新一次頁面就好了，但如果發貨不到賬，用戶會直接投訴，所以上述案例就把發貨操作拆出來獨立部署了一套異步發貨集群。
柔性可用我們應該怎么實現呢？
一般有兩個方向，第一種是設置超短的超時時間，例如，給安全接口設置超時時間為30毫秒，假設那天安全接口真的掛了，30毫秒對于一個百毫秒級別的請求來說，用戶也不太能感知到，活動的體驗還是好的。另外一種，就是直接不等網絡回包的方式，例如UDP服務。
在容災建設中，我們要大膽提出假設，假設各個核心的服務和存儲都可能掛掉，根據假設去制定對應的容災和解決方案。比如應對機房停電、網絡故障，我們可以做跨機房跨網絡部署，這樣即使電信光纖被挖斷，服務還能保持基本正常。另外要做好應急預案，把所有關鍵節點故障的假設對應的處理方案全部做成開關模式，避免在活動當天還要去跑日志和寫處理腳本。
針對監控與對賬，我們必須建立多維度的監控體系，在流量峰值的壓力下部分監控可能會出現問題，多維度的監控能幫助我們探知系統的真實狀態，有助于我們采取正確的應對措施。
關于對賬能力，假如發貨失敗了，當天值班的同學需要看跑線上日志和寫補發腳本，那么半個小時、一個小時就過去了。值班同學通常都比較忙，所以最好的方式就是提開發好，當天如果發現問題，它就能自動去檢測失敗的日志并且進行補發。
前面講了比較多關于大流量活動的架構準備工作，這一部分我們講講具體的實踐案例。
第一個案例是某年某業務的春節紅包活動，盡管前期做了非常度多的準備，活動上線時還是出現了一系列問題，但好在都在我們的預案之內，算是有驚無險。
事后我們也進行了反思回顧，出現那么多問題是為什么？首先就是沒有遵循3倍擴容原則，再比如說鏈路梳理沒有到位，下面就是我們的一些總結內容。
根據我們的過往經驗，最危險的活動反而不是大型活動，因為為了確保大活動的順利開展，公司會抽調很多骨干參與進來，即使出現問題通常也是小問題。而中小型活動的流量不會太大，沒有什么威脅。最容易出問題的恰恰是那些中大型活動，接下來詳細講講另一個中大型活動案例。
在某游戲的年度活動項目中，我們做了一些評估和準備工作，但不可能對待每個活動都像對待春節紅包活動那樣。當時我們派了2個人看了一下，各個線上模塊團隊負責壓測各自的模塊，都反饋沒問題，活動就上線了。活動當天凌晨我被電話叫醒，系統出問題了，當時有很多用戶已經無法參加活動了。
當時的Web系統是基于PHP和Apache，采用Apache的多進程模式（perfork）。一個后端服務響應時間一般在幾十毫秒，一個worker進程1秒鐘應該可以處理十多個請求，但到了高峰時期，在大流量的壓力下，后端服務的響應時間從幾十毫秒飆到了幾百毫秒甚至是1秒。這個時候1個wrker進程1秒鐘只能處理1個請求，無法及時處理最終導致請求堆積。我們趁著玩家在凌晨的休息時間去做了不少補救工作，包括降級及其他的動作，經過一個通宵的努力，用戶可以正常進入活動了，但還沒有完全解決。第二天下午我們又到公司繼續，48小時連軸轉重新發版后終于解決了問題，安穩度過了那次活動危機。這種大中型的活動最容易出問題，因為通常我們不會給與足夠的關注度。
總結一下大流量活動前期需要做的一些總體的經驗和流程，首先是相對合理的評估&梳理方案，再進行架構上的優化和調整，最后就是整理緊急預案。
我連續參加過三年春節紅包活動活動，每一年都提前大概一個多月召集核心骨干來出具方案，每年都做很多準備，可每年都有一些小問題。
反思為什么投入大量人力物力資源，系統還是出問題？
究其本質，我覺得主要是三個方面：第一很多時候測試環境、甚至性能環境無法代表真實的生產環境；第二，各個局部高可用不代表整體高可用；第三是系統的成長性，復雜的業務系統在持續迭代、膨脹，今天沒性能問題，不代表明天沒問題。
想讓生產環境的性能獲得保證，不出問題，從這個點出發我們有一個明確的探索方向——常態化的生產環境性能測試。
大量的準備工作都是為了保證線上環境能夠達到一定的性能指標，所以最好的方式就是直接在生產環境去做最真實的性能測試。比如選在凌晨兩三點鐘沒有什么業務流量的時候執行性能測試，看系統能不能達到我的目標性能。
那想要真正做到在生產環境實施性能壓測有哪些關鍵點呢？
主要有三點，測試流量識別、測試流量標識的傳遞以及最重要的測試流量隔離。做生產環境壓測避免不了涉及一些寫入請求，如果把大量虛假的數據寫入生產環境數據庫肯定不合適，后續還要去做數據清理。所以只要前面提到的三個關鍵點能夠解決，在線性能測試就能實現。
這是我們基于JAVA做的一套性能測試平臺，因為我們可以在JAVA有中間字節碼這一層做增強，通過agent探針在不侵入用戶業務代碼情況下去做一些控制。正式流量保持不變，我們會對壓測的流量做一些控制。舉個例子，比如說系統有一個mysql數據庫，我們就會在線上建一套影子數據庫，跟原來數據庫一樣，只是數據可能少一點或是空的（只有表結構）。當有流量進來時agent就會進行識別，識別出壓測流量時，agent會把連接的數據庫替換成影子數據庫。無論是消息隊列還是Cache存儲都可以用類似的方式來實現。
另外我們還做了一個東西叫擋板，它是干嘛的呢？假設有個第三方的短信接口，業務流量去調用這個接口是可以的，但測試流量直接去調用肯定是不行的，因為第三方不可能配合你做一個影子發短信的系統。擋板的作用就是通過agent來實現一個mock，在調用第三方接口時直接返回，防止測試流量調用第三方接口時對生產數據產生影響。
這是數列的生產環境全鏈路性能測試的方案，在此基礎上我們還研發了鏈路自動梳理的功能。對于復雜業務以及復雜系統，它內含很多個微服務節點和業務節點，沒有人能完全搞清楚整個鏈路的所有的環節。我們可以通過agent探針，利用技術手段搞清系統鏈路流向，協助進行鏈路梳理，與業務相結合就能梳理出業務調用的鏈路。結合E2E巡檢平臺不僅能夠知道這條鏈路的性能如何，還能定位到具體環節的具體性能瓶頸，方便及時準確地進行性能調優，梳理業務鏈路視圖，最終實現系統的高可用目標。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
