話說(shuō)每逢雙十一節(jié)或春節(jié)等節(jié)假日，對(duì)大家來(lái)講是最歡樂的日子，可以在微信群中收發(fā)紅包，此外今年微信還推出了面對(duì)面紅包，讓大家拜年時(shí)可直接收發(fā)，對(duì)于用戶來(lái)講很爽也很方便。但對(duì)于技術(shù)架構(gòu)側(cè)的考量，這使得微信紅包的收發(fā)數(shù)據(jù)成幾何倍數(shù)上升，處理的復(fù)雜度也增加了很多。
2017年微信紅包發(fā)送量大的時(shí)間段是除夕夜，達(dá)到了142億個(gè)。
如此大規(guī)模、高并發(fā)、高峰值的業(yè)務(wù)場(chǎng)景，怕是在美帝互聯(lián)網(wǎng)的技術(shù)團(tuán)隊(duì)，包括EBay、Amazon等也無(wú)法想象，在這種巨大的流量與并發(fā)后面，需要什么樣級(jí)別的技術(shù)架構(gòu)支撐？
當(dāng)達(dá)百億級(jí)別的資金交易規(guī)模時(shí)，我們?cè)撛鯓觼?lái)保證系統(tǒng)的并發(fā)性能和交易安全？
當(dāng)今中國(guó)的互聯(lián)網(wǎng)平臺(tái)，有兩個(gè)場(chǎng)景稱得上億級(jí)以上的并發(fā)量：
一個(gè)是微信的紅包，
一個(gè)是字節(jié)的紅包，
都是在一個(gè)單位時(shí)間達(dá)到億萬(wàn)以以上的請(qǐng)求負(fù)載。
百億級(jí) 微信紅包技術(shù)架構(gòu)與傳統(tǒng)意義上的紅包相比，近兩年火起來(lái)的“紅包”，似乎才是如今春節(jié)的一大重頭戲。歷經(jīng)上千年時(shí)代傳承與變遷，春節(jié)發(fā)紅包早已成為歷史沉淀的文化習(xí)俗，融入了民族的血脈。按照各家公布的數(shù)據(jù)，除夕全天微信用戶紅包總發(fā)送量達(dá)到80.8億個(gè)，紅包峰值收發(fā)量為40.9萬(wàn)個(gè)/秒。春晚直播期間討論春晚的微博達(dá)到5191萬(wàn)條，網(wǎng)友互動(dòng)量達(dá)到1.15億，網(wǎng)友搶微博紅包的總次數(shù)超過8億次。
微信紅包在經(jīng)過15年春晚?yè)u一搖之后，2015年上半年業(yè)務(wù)量一度呈指數(shù)級(jí)增長(zhǎng)。尤其是微信紅包活躍用戶數(shù)的大量增長(zhǎng)，使得2016除夕跨年紅包成為極大挑戰(zhàn)。為了應(yīng)對(duì)16年春節(jié)可預(yù)知的紅包海量業(yè)務(wù)，紅包系統(tǒng)在架構(gòu)上進(jìn)行了一系列調(diào)整和優(yōu)化。主要包括異地架構(gòu)、cache系統(tǒng)優(yōu)化、拆紅包并發(fā)策略優(yōu)化、存儲(chǔ)優(yōu)化一系列措施，為迎接2016春節(jié)紅包挑戰(zhàn)做好準(zhǔn)備。 下面介紹最主要的一些思路。
架構(gòu)微信用戶在國(guó)內(nèi)有深圳、上海兩個(gè)接入點(diǎn)，習(xí)慣性稱之為南、北（即深圳為南，上海為北）。用戶請(qǐng)求接入后，不同業(yè)務(wù)根據(jù)業(yè)務(wù)特性選擇部署方式。微信紅包在信息流上可以分為訂單緯度與用戶緯度。
其中訂單是貫穿紅包發(fā)、搶、拆、詳情列表等業(yè)務(wù)的關(guān)鍵信息，屬于交易類信息；而用戶緯度指的是紅包用戶的收紅包列表、發(fā)紅包列表，屬于展示類信息。紅包系統(tǒng)在架構(gòu)上，有以下幾個(gè)方面：
南北分布1、訂單層南北獨(dú)立體系，數(shù)據(jù)不同步
用戶就近接入，請(qǐng)求發(fā)紅包時(shí)分配訂單南北，并在單號(hào)打上南北標(biāo)識(shí)。搶紅包、拆紅包、查紅包詳情列表時(shí)，接入層根據(jù)紅包單號(hào)上的南北標(biāo)識(shí)將流量分別引到南北系統(tǒng)閉環(huán)。根據(jù)發(fā)紅包用戶和搶紅包用戶的所屬地不同，有以下四種情況：
1）深圳用戶發(fā)紅包，深圳用戶搶
訂單落在深圳，深圳用戶搶紅包時(shí)不需要跨城，在深圳完成閉環(huán)。
2）深圳用戶發(fā)紅包，上海用戶搶
訂單落在深圳，上海用戶搶紅包，在上海接入后通過專線跨城到深圳，最后在深圳閉環(huán)完成搶紅包。
3）上海用戶發(fā)紅包，上海用戶搶
訂單落在上海，上海用戶搶紅包時(shí)不需要跨城，在上海完成閉環(huán)。
4）上海用戶發(fā)紅包，深圳用戶搶
訂單落在上海，深圳用戶搶紅包，從深圳接入后通過專線跨城到上海，最后在上海閉環(huán)完成搶紅包。
系統(tǒng)這樣設(shè)計(jì)，好處是南北系統(tǒng)分?jǐn)偭髁?，降低系統(tǒng)風(fēng)險(xiǎn)。
2、用戶數(shù)據(jù)寫多讀少，全量存深圳，異步隊(duì)列寫入，查時(shí)一邊跨城
用戶數(shù)據(jù)的查詢?nèi)肟?，在微信錢包中，隱藏的很深。這決定了用戶數(shù)據(jù)的訪問量不會(huì)太大，而且也被視為可旁路的非關(guān)鍵信息，實(shí)時(shí)性要求不高。因此，只需要在發(fā)紅包、拆紅包時(shí)，從訂單緯度拆分出用戶數(shù)據(jù)寫入請(qǐng)求，由MQ異步寫入深圳。后臺(tái)將訂單與用戶進(jìn)行定時(shí)對(duì)賬保證數(shù)據(jù)完整性即可。
3、支持南北流量靈活調(diào)控
紅包系統(tǒng)南北分布后，訂單落地到深圳還是上海，是可以靈活分配的，只需要在接入層上做邏輯。例如，可以在接入層中，實(shí)現(xiàn)讓所有紅包請(qǐng)求，都落地到深圳（無(wú)論用戶從上海接入，還是深圳接入），這樣上海的紅包業(yè)務(wù)系統(tǒng)將不會(huì)有請(qǐng)求量。提升了紅包系統(tǒng)的容災(zāi)能力。同時(shí)，實(shí)現(xiàn)了接入層上的后臺(tái)管理系統(tǒng)，實(shí)現(xiàn)了秒級(jí)容量調(diào)控能力?？筛鶕?jù)南北請(qǐng)求量的實(shí)時(shí)監(jiān)控，做出對(duì)應(yīng)的調(diào)配。
4、DB故障時(shí)流量轉(zhuǎn)移能力 基于南北流量的調(diào)控能力，當(dāng)發(fā)現(xiàn)DB故障時(shí)，可將紅包業(yè)務(wù)流量調(diào)到另外一邊，實(shí)現(xiàn)DB故障的容災(zāi)。
預(yù)訂單
支付前訂單落cache，同時(shí)利用cache的原子incr操作順序生成紅包訂單號(hào)。優(yōu)點(diǎn)是cache的輕量操作，以及減少DB廢單。在用戶請(qǐng)求發(fā)紅包與真正支付之間，存在一定的轉(zhuǎn)化率，部分用戶請(qǐng)求發(fā)紅包后，并不會(huì)真正去付款。
拆紅包入賬異步化信息流與資金流分離。
拆紅包時(shí)，DB中記下拆紅包憑證，然后異步隊(duì)列請(qǐng)求入賬。
入賬失敗通過補(bǔ)償隊(duì)列補(bǔ)償，最終通過紅包憑證與用戶賬戶入賬流水對(duì)賬，保證最終一致性。如下圖所示：
這個(gè)架構(gòu)設(shè)計(jì)，理論基礎(chǔ)是快慢分離。
紅包的入賬是一個(gè)分布事務(wù)，屬于慢接口。
而拆紅包憑證落地則速度快。
實(shí)際應(yīng)用場(chǎng)景中，用戶搶完紅包，只關(guān)心詳情列表中誰(shuí)是“最佳手氣”，很少關(guān)心搶到的零是否已經(jīng)到賬。
因?yàn)橹恍枰故居脩舻牟鸺t包憑證即可。
發(fā)拆落地，其他操作雙層cache1、Cache住所有查詢，兩層cache
除了使用ckv做全量緩存，還在數(shù)據(jù)訪問層dao中增加本機(jī)內(nèi)存cache做二級(jí)緩存，cache住所有讀請(qǐng)求。
查詢失敗或者查詢不存在時(shí)，降級(jí)內(nèi)存cache；內(nèi)存cache查詢失敗或記錄不存在時(shí)降級(jí)DB。
DB本身不做讀寫分離。
2、DB寫同步cache，容忍少量不一致， DB寫操作完成后，dao中同步內(nèi)存cache，業(yè)務(wù)服務(wù)層同步ckv，失敗由異步隊(duì)列補(bǔ)償，
定時(shí)的ckv與DB備機(jī)對(duì)賬，保證最終數(shù)據(jù)一致。
高并發(fā)微信紅包的并發(fā)挑戰(zhàn)，主要在于微信大群，多人同時(shí)搶同一個(gè)紅包。
以上這種情況，存在競(jìng)爭(zhēng)MySQL行鎖。為了控制這種并發(fā)，團(tuán)隊(duì)做了以下一些事情：
1、請(qǐng)求按紅包訂單路由，邏輯塊垂直sticky，事務(wù)隔離
按紅包訂單劃分邏輯單元，單元內(nèi)業(yè)務(wù)閉環(huán)。服務(wù)rpc調(diào)用時(shí)，使用紅包訂單號(hào)的hash值為key尋找下一跳地址。對(duì)同一個(gè)紅包的所有拆請(qǐng)求、查詢請(qǐng)求，都路由到同一臺(tái)邏輯機(jī)器、同一臺(tái)DB中處理。
2、Dao搭建本機(jī)Memcache內(nèi)存cache，控制同一紅包并發(fā)個(gè)數(shù)
在DB的接入機(jī)dao中，搭建本機(jī)內(nèi)存cache。以紅包訂單號(hào)為key，對(duì)同一個(gè)紅包的拆請(qǐng)求做原子計(jì)數(shù)，控制同一時(shí)刻能進(jìn)DB中拆紅包的并發(fā)請(qǐng)求數(shù)。
這個(gè)策略的實(shí)施，依賴于請(qǐng)求路由按紅包訂單hash值走，確保同一紅包的所有請(qǐng)求路由到同一邏輯層機(jī)器。
3、多層級(jí)并發(fā)量控制
1）發(fā)紅包控制
發(fā)紅包是業(yè)務(wù)流程的入口，控制了這里的并發(fā)量，代表著控制了紅包業(yè)務(wù)整體的并發(fā)量。在發(fā)紅包的業(yè)務(wù)鏈路里，做了多層的流量控制，確保產(chǎn)生的有效紅包量級(jí)在可控范圍。
2）搶紅包控制
微信紅包領(lǐng)取時(shí)分為兩個(gè)步驟，搶和拆。
搶紅包這個(gè)動(dòng)作本身就有控制拆并發(fā)的作用。因?yàn)閾尲t包時(shí)，只需要查cache中的數(shù)據(jù)，不需要請(qǐng)求DB。
對(duì)于紅包已經(jīng)領(lǐng)完、用戶已經(jīng)領(lǐng)過、紅包已經(jīng)過期等流量可以直接攔截。而對(duì)于有資格進(jìn)入拆紅包的請(qǐng)求量，也做流量控制。通過這些處理，最后可進(jìn)入拆環(huán)節(jié)的流量大大減少，并且都是有效請(qǐng)求。
3）拆時(shí)內(nèi)存cache控制
針對(duì)同一個(gè)紅包并發(fā)拆的控制，上面的文章已介紹。
4、DB簡(jiǎn)化和拆分
DB的并發(fā)能力，有很多影響因素。紅包系統(tǒng)結(jié)合紅包使用情境，進(jìn)行了一些優(yōu)化。比較有借鑒意義的，主要有以下兩點(diǎn)：
1）訂單表只存關(guān)鍵字段，其他字段只在cache中存儲(chǔ)，可柔性。
紅包詳情的展示中，除了訂單關(guān)鍵信息（用戶、單號(hào)、金額、時(shí)間、狀態(tài)）外，還有用戶頭像、昵稱、祝福語(yǔ)等字段。這些字段對(duì)交易來(lái)說(shuō)不是關(guān)鍵信息，卻占據(jù)大量的存儲(chǔ)空間。
將這些非關(guān)鍵信息拆出來(lái)，只存在cache，用戶查詢展示，而訂單中不落地。
這樣可以維持訂單的輕量高效，同時(shí)cache不命中時(shí)，又可從實(shí)時(shí)接口中查詢補(bǔ)償，達(dá)到優(yōu)化訂單DB容量的效果。
2）DB雙重緯度分庫(kù)表，冷熱分離
使用訂單hash、訂單日期，兩個(gè)緯度分庫(kù)表，也即db_xxx.t_x_dd這樣的格式。
其中，x表示訂單hash值，dd表示01-31循環(huán)日。
訂單hash緯度，是為了將訂單打散到不同的DB服務(wù)器中，均衡壓力。
訂單日期循環(huán)日緯度，是為了避免單表數(shù)據(jù)無(wú)限擴(kuò)張，使每天都是一張空表。
另外，紅包的訂單訪問熱度，是非常典型的冷熱型。
熱數(shù)據(jù)集中在一兩天內(nèi)，且隨時(shí)間急劇消減。
線上熱數(shù)據(jù)庫(kù)只需要存幾天的數(shù)據(jù)，其他數(shù)據(jù)可以定時(shí)移到成本低的冷數(shù)據(jù)庫(kù)中。
循環(huán)日表也使得歷史數(shù)據(jù)的遷移變得方便。
紅包算法首先，如果紅包只有一個(gè)，本輪直接使用全部金額，確保紅包發(fā)完。
然后，計(jì)算出本輪紅包最少要領(lǐng)取多少，才能保證紅包領(lǐng)完，即本輪下水位；輪最多領(lǐng)取多少，才能保證每個(gè)人都領(lǐng)到，即本輪上水位。主要方式如下：
計(jì)算本輪紅包金額下水位：假設(shè)本輪領(lǐng)到最小值1分，那接下來(lái)每次都領(lǐng)到200元紅包能領(lǐng)完，那下水位為1分；如果不能領(lǐng)完，那按接下來(lái)每次都領(lǐng)200元，剩下的本輪應(yīng)全部領(lǐng)走，是本輪的下水位。
計(jì)算本輪紅包上水位：假設(shè)本輪領(lǐng)200元，剩下的錢還足夠接下來(lái)每輪領(lǐng)1分錢，那本輪上水位為200元；如果已經(jīng)不夠領(lǐng)，那按接下來(lái)每輪領(lǐng)1分，計(jì)算本輪的上水位。
為了使紅包金額不要太懸殊，使用紅包均值調(diào)整上水位。如果上水位金額大于兩倍紅包均值，那么使用兩倍紅包均值作為上水位。換句話說(shuō)，每一輪搶到的紅包金額，最高為兩倍剩下紅包的均值。
最后，獲取隨機(jī)數(shù)并用上水位取余，如果結(jié)果比下水位還小，則直接使用下水位，否則使用隨機(jī)金額為本輪拆到金額。
柔性降級(jí)方案系統(tǒng)到處存在發(fā)生異常的可能，需要對(duì)所有的環(huán)節(jié)做好應(yīng)對(duì)的預(yù)案。
下面列舉微信紅包對(duì)系統(tǒng)異常的主要降級(jí)考慮。
1、 下單cache故障降級(jí)DB
下單cache有兩個(gè)作用，生成紅包訂單與訂單緩存。
緩存故障情況下，降級(jí)為直接落地DB，并使用id生成器獨(dú)立生成訂單號(hào)。
2、 搶時(shí)cache故障降級(jí)DB
搶紅包時(shí)，查詢cache，攔截紅包已經(jīng)搶完、用戶已經(jīng)搶過、紅包已經(jīng)過期等無(wú)效請(qǐng)求。當(dāng)cache故障時(shí)，降級(jí)DB查詢，同時(shí)打開DB限流保護(hù)開關(guān)，防止DB壓力過大導(dǎo)致服務(wù)不可用。
另外，cache故障降級(jí)DB時(shí)，DB不存儲(chǔ)用戶頭像、用戶昵稱等（上文提到的優(yōu)化），此時(shí)一并降級(jí)為實(shí)時(shí)接口查詢。查詢失敗，繼續(xù)降級(jí)為展示默認(rèn)頭像與昵稱。
3、 拆時(shí)資金入賬多級(jí)柔性
拆紅包時(shí)，DB記錄拆紅包單據(jù)，然后執(zhí)行資金轉(zhuǎn)賬。單據(jù)需要實(shí)時(shí)落地，而資金轉(zhuǎn)賬，這里做了多個(gè)層級(jí)的柔性降級(jí)方案：
大額紅包實(shí)時(shí)轉(zhuǎn)賬，小額紅包入隊(duì)列異步轉(zhuǎn)賬 所有紅包進(jìn)隊(duì)列異步轉(zhuǎn)賬 實(shí)時(shí)流程不執(zhí)行轉(zhuǎn)賬，事后憑單據(jù)批量入賬。
總之，單據(jù)落地后，真實(shí)入賬可實(shí)時(shí)、可異步，最終保證一致即可。
4、 用戶列表降級(jí)
用戶列表數(shù)據(jù)在微信紅包系統(tǒng)中，屬于非關(guān)鍵路徑信息，屬于可被降級(jí)部分。
首先，寫入時(shí)通過MQ異步寫，通過定時(shí)對(duì)賬保證一致性。
其次，cache中只緩存兩屏，用戶查詢超過兩屏則查用戶列表DB。在系統(tǒng)壓力大的情況下，可以限制用戶只查兩屏。
調(diào)整后的系統(tǒng)經(jīng)過了2016年春節(jié)的實(shí)踐檢驗(yàn)，平穩(wěn)地度過了除夕業(yè)務(wù)高峰，保障了紅包用戶的體驗(yàn)。
360w QPS 100億級(jí) 字節(jié)紅包 體系架構(gòu) 1. 背景&挑戰(zhàn)&目標(biāo) 1.1 業(yè)務(wù)背景上文參考來(lái)源：架構(gòu)說(shuō)公眾號(hào)，作者：方樂明
方樂明，2011年畢業(yè)于華南理工大學(xué)通信與信息系統(tǒng)專業(yè)，畢業(yè)后就職于財(cái)付通科技有限公司。微信支付團(tuán)隊(duì)組建后，主要負(fù)責(zé)微信紅包、微信轉(zhuǎn)賬、AA收款等支付應(yīng)用產(chǎn)品的后臺(tái)架構(gòu)。
（1）支持八端：
2022 年字節(jié)系產(chǎn)品春節(jié)活動(dòng)需要支持八端 APP 產(chǎn)品（包含抖音/抖音火山/抖音極速版/西瓜/頭條/頭條極速版/番茄小說(shuō)/番茄暢聽）的獎(jiǎng)勵(lì)互通。用戶在上述任意一端都可以參與活動(dòng)，得到的獎(jiǎng)勵(lì)在其他端都可以提現(xiàn)與使用。
（2）玩法多變：
主要有集卡、朋友頁(yè)紅包雨、紅包雨、集卡開獎(jiǎng)與煙火大會(huì)等。
（3）多種獎(jiǎng)勵(lì)：
獎(jiǎng)勵(lì)類型包含現(xiàn)金紅包、補(bǔ)貼視頻紅包、商業(yè)化廣告券、電商券、支付券、消費(fèi)金融券、保險(xiǎn)券、信用卡優(yōu)惠券、喜茶券、電影票券、dou+券、抖音文創(chuàng)券、頭像掛件等。
1.2 核心挑戰(zhàn)（1）超高吞吐，超大并發(fā)，最高預(yù)估 360w QPS 發(fā)獎(jiǎng)。
（2）獎(jiǎng)勵(lì)類型多，共 10 余種獎(jiǎng)勵(lì)。多種發(fā)獎(jiǎng)勵(lì)的場(chǎng)景，玩法多變；
（3）從獎(jiǎng)勵(lì)系統(tǒng)穩(wěn)定性、用戶體驗(yàn)、資金安全與運(yùn)營(yíng)基礎(chǔ)能力全方位保障，確保活動(dòng)順利進(jìn)行 。
1.3 最終目標(biāo)（1）獎(jiǎng)勵(lì)入賬：數(shù)據(jù)高可靠。提供統(tǒng)一的錯(cuò)誤處理機(jī)制，入賬冪等能力和獎(jiǎng)勵(lì)預(yù)算控制。
（2）**獎(jiǎng)勵(lì)展示/使用：**支持用戶查看、提現(xiàn)（現(xiàn)金），使用卡券/掛件等能力。
（3）穩(wěn)定性保障：在大流量的入賬場(chǎng)景下，保證錢包核心路徑穩(wěn)定性與完善，通過常用穩(wěn)定性保障手段如資源擴(kuò)容、限流、熔斷、降級(jí)、兜底、資源隔離等方式保證用戶獎(jiǎng)勵(lì)方向的核心體驗(yàn)。
（4）資金安全：通過冪等、對(duì)賬、監(jiān)控與報(bào)警等機(jī)制，保證資金安全，保證用戶資產(chǎn)應(yīng)發(fā)盡發(fā)，不少發(fā)。
（5）活動(dòng)隔離：實(shí)現(xiàn)內(nèi)部測(cè)試、灰度放量和正式春節(jié)活動(dòng)三個(gè)階段的獎(jiǎng)勵(lì)入賬與展示的數(shù)據(jù)隔離，不互相影響。
2. 產(chǎn)品需求介紹用戶可以在任意一端參與字節(jié)的春節(jié)活動(dòng)獲取獎(jiǎng)勵(lì)，以抖音紅包雨現(xiàn)金紅包入賬場(chǎng)景為例，具體的業(yè)務(wù)流程如下：
登錄抖音 → 參與活動(dòng) → 活動(dòng)錢包頁(yè) → 點(diǎn)擊提現(xiàn)按鈕 → 進(jìn)入提現(xiàn)頁(yè)面 → 進(jìn)行提現(xiàn) → 提現(xiàn)結(jié)果頁(yè)，
另外從錢包頁(yè)也可以進(jìn)入活動(dòng)錢包頁(yè)。
獎(jiǎng)勵(lì)發(fā)放核心場(chǎng)景：
在 2022 年春節(jié)活動(dòng)中，業(yè)務(wù)方分為：
UG、激勵(lì)中臺(tái)、視頻紅包、錢包方向、資產(chǎn)中臺(tái)等
其中，UG 主要負(fù)責(zé)活動(dòng)的玩法實(shí)現(xiàn)，包含集卡、紅包雨以及煙火大會(huì)等具體的活動(dòng)相關(guān)業(yè)務(wù)邏輯和穩(wěn)定性保障。
而錢包方向定位是大流量場(chǎng)景下實(shí)現(xiàn)獎(jiǎng)勵(lì)入賬、獎(jiǎng)勵(lì)展示、獎(jiǎng)勵(lì)使用與資金安全保障的相關(guān)任務(wù)。
其中資產(chǎn)中臺(tái)負(fù)責(zé)獎(jiǎng)勵(lì)發(fā)放與獎(jiǎng)勵(lì)展示部分。
3.1 春節(jié)資產(chǎn)資產(chǎn)中臺(tái)總體架構(gòu)圖如下：
錢包資產(chǎn)中臺(tái)核心系統(tǒng)劃分如下：
資產(chǎn)訂單層：
收斂八端獎(jiǎng)勵(lì)入賬鏈路，
提供統(tǒng)一的接口協(xié)議，對(duì)接上游活動(dòng)業(yè)務(wù)方的獎(jiǎng)勵(lì)發(fā)放功能，
同時(shí)，支持預(yù)算控制、補(bǔ)償、訂單號(hào)冪等。
活動(dòng)錢包 api 層：
統(tǒng)一獎(jiǎng)勵(lì)展示鏈路，同時(shí)支持大流量場(chǎng)景
核心發(fā)放模型：
說(shuō)明：
活動(dòng) ID 唯一區(qū)分一個(gè)活動(dòng)，
本次春節(jié)分配了一個(gè)單獨(dú)的母活動(dòng) ID
場(chǎng)景 ID 和具體的一種獎(jiǎng)勵(lì)類型一一對(duì)應(yīng)，
定義該場(chǎng)景下發(fā)獎(jiǎng)勵(lì)的唯一配置，
場(chǎng)景 ID 可以配置的能力有：
訂單號(hào)設(shè)計(jì)：
資產(chǎn)訂單層支持訂單號(hào)維度的發(fā)獎(jiǎng)冪等，訂單號(hào)設(shè)計(jì)邏輯為
${actID}_${scene_id}_${rain_id}_${award_type}_${statge}
從單號(hào)設(shè)計(jì)層面保證不超發(fā)，每個(gè)場(chǎng)景的獎(jiǎng)勵(lì)用戶最多只領(lǐng)一次。
4. 核心難點(diǎn)問題解決 4.1 難點(diǎn)一：支持八端獎(jiǎng)勵(lì)數(shù)據(jù)互通有八個(gè)產(chǎn)品端，需要統(tǒng)一對(duì)接，
其中抖音系和頭條系 APP 是不同的賬號(hào)體系，所以不能通過用戶 ID 打通獎(jiǎng)勵(lì)互通。
具體解決方案是：
在唯一 actID 基礎(chǔ)上，每個(gè)用戶的獎(jiǎng)勵(lì)數(shù)據(jù)是綁定在 actID 上的，入賬和查詢是通過 actID 維度實(shí)現(xiàn)的，即可實(shí)現(xiàn)八端獎(jiǎng)勵(lì)互通。
示意圖如下：
超高并發(fā)場(chǎng)景，發(fā)現(xiàn)金紅包都是最關(guān)鍵的一環(huán)。有幾個(gè)原因如下：
終上所述，發(fā)現(xiàn)金紅包面臨比較大的技術(shù)挑戰(zhàn)。
發(fā)紅包其實(shí)是一種交易行為，資金流走向是從公司成本出然后進(jìn)入個(gè)人賬戶。
（1）從技術(shù)方案上是要支持訂單號(hào)維度的冪等，同一訂單號(hào)多次請(qǐng)求只入賬一次。訂單號(hào)生成邏輯為
${actID}_${scene_id}_${rain_id}_${award_type}_${statge}
從單號(hào)設(shè)計(jì)層面保證不超發(fā)。
（2）支持高并發(fā)，有以下 2 個(gè)傳統(tǒng)方案：
| 具體方案類型 | 實(shí)現(xiàn)思路 | 優(yōu)點(diǎn) | 缺點(diǎn) |
|---|---|---|---|
| 同步入賬 | 申請(qǐng)和預(yù)估流量相同的計(jì)算和存儲(chǔ)資源 | 1.開發(fā)簡(jiǎn)單； 2.不容易出錯(cuò)； | 浪費(fèi)存儲(chǔ)成本。 拿賬戶數(shù)據(jù)庫(kù)舉例，經(jīng)實(shí)際壓測(cè)結(jié)果：支持 30w 發(fā)紅包需要 152 個(gè)數(shù)據(jù)庫(kù)實(shí)例，如果支持 180w 發(fā)紅包，至少需要 1152 個(gè)數(shù)據(jù)庫(kù)實(shí)例，還沒有算上 tce 和 redis 等其他計(jì)算和存儲(chǔ)資源。 |
| 異步入賬 | 申請(qǐng)部分計(jì)算和存儲(chǔ)資源資源，實(shí)際入賬能力與預(yù)估有一定差值 | 1.開發(fā)簡(jiǎn)單； 2.不容易出錯(cuò)； 3.不浪費(fèi)資源； | 用戶體驗(yàn)受到很大影響。 入賬延遲較大，以今年活動(dòng)舉例會(huì)有十幾分鐘延遲。用戶參與玩法得到獎(jiǎng)勵(lì)后在活動(dòng)錢包頁(yè)看不到獎(jiǎng)勵(lì)，也無(wú)法進(jìn)行提現(xiàn)，會(huì)有大量客訴，影響抖音活動(dòng)的效果。 |
以上兩種傳統(tǒng)意義上的技術(shù)方案都有明顯的缺點(diǎn)，
那么進(jìn)行思考，既能相對(duì)節(jié)約資源又能保證用戶體驗(yàn)的方案是什么？
最終采用的是紅包雨 token 方案，具體方案是：
使用異步入賬加較少量分布式存儲(chǔ)和較復(fù)雜方案來(lái)實(shí)現(xiàn)，
下面具體介紹一下。
4.2.1 紅包雨 token 方案：根據(jù)預(yù)估發(fā)放紅包估算，紅包雨 token 方案, 計(jì)算實(shí)際入賬最低要支持的 TPS 為 30w，所以實(shí)際發(fā)放中有壓?jiǎn)蔚倪^程。
設(shè)計(jì)目標(biāo)：
在活動(dòng)預(yù)估給用戶發(fā)放（180w）與實(shí)際入賬（30w）有很大 gap 的情況下，保證用戶的核心體驗(yàn)。
用戶在前端頁(yè)面查看與使用過當(dāng)中不能感知壓?jiǎn)蔚倪^程，即查看與使用體驗(yàn)不能受到影響，相關(guān)展示的數(shù)據(jù)包含余額，累計(jì)收入與紅包流水，使用包含提現(xiàn)等。
具體設(shè)計(jì)方案：
我們?cè)诖罅髁繄?chǎng)景下每次給用戶發(fā)紅包會(huì)生成一個(gè)加密 token（使用非對(duì)稱加密，包含發(fā)紅包的元信息：紅包金額，actID，與發(fā)放時(shí)間等），
分別存儲(chǔ)在客戶端和服務(wù)端（容災(zāi)互備），每個(gè)用戶有個(gè) token 列表。
每次發(fā)紅包的時(shí)候會(huì)在 Redis 里記錄該 token 的入賬狀態(tài)，
然后用戶在活動(dòng)錢包頁(yè)看到的現(xiàn)金紅包流水、余額等數(shù)據(jù)，是合并已入賬紅包列表+token 列表-已入賬/入賬中 token 列表的結(jié)果。
同時(shí)為保證用戶提現(xiàn)體驗(yàn)不感知紅包壓?jiǎn)瘟鞒蹋?/p>
在進(jìn)入提現(xiàn)頁(yè)或者點(diǎn)擊提現(xiàn)時(shí)，將未入賬的 token 列表進(jìn)行強(qiáng)制入賬，
保證用戶提現(xiàn)時(shí)賬戶的余額為應(yīng)入賬總金額，不 block 用戶提現(xiàn)流程。
示意圖如下：
token 數(shù)據(jù)結(jié)構(gòu)：
token 使用的是 protobuf 格式，
經(jīng)單測(cè)驗(yàn)證存儲(chǔ)消耗實(shí)際比使用 json 少了一倍，節(jié)約請(qǐng)求網(wǎng)絡(luò)的帶寬和存儲(chǔ)成本；
同時(shí)序列化與反序列化消耗 cpu 也有降低。
重慶分公司
重慶分公司
// 紅包雨token結(jié)構(gòu)
type RedPacketToken struct {AppID int64 `protobuf: varint,1,opt json: AppID,omitempty ` // 端ID
ActID int64 `protobuf: varint,2,opt json: UserID,omitempty ` // ActID
ActivityID string `protobuf: bytes,3,opt json: ActivityID,omitempty ` // 活動(dòng)ID
SceneID string `protobuf: bytes,4,opt json: SceneID,omitempty ` // 場(chǎng)景ID
Amount int64 `protobuf: varint,5,opt json: Amount,omitempty ` // 紅包金額
OutTradeNo string `protobuf: bytes,6,opt json: OutTradeNo,omitempty ` // 訂單號(hào)
OpenTime int64 `protobuf: varint,7,opt json: OpenTime,omitempty ` // 開獎(jiǎng)時(shí)間
RainID int32 `protobuf: varint,8,opt,name=rainID json: rainID,omitempty ` // 紅包雨ID
Status int64 `protobuf: varint,9,opt,name=status json: status,omitempty ` //入賬狀態(tài)
}token 安全性保障：
采用非對(duì)稱加密算法，保障存儲(chǔ)在的客戶端盡可能不被破解。
如果 token 加密算法被黑產(chǎn)破譯，可監(jiān)控報(bào)警發(fā)現(xiàn)，可降級(jí)。
4.3 難點(diǎn)三：發(fā)獎(jiǎng)勵(lì)鏈路依賴多的穩(wěn)定性保障發(fā)紅包流程降級(jí)示意圖如下：
根據(jù)歷史經(jīng)驗(yàn)，實(shí)現(xiàn)的功能越復(fù)雜，依賴會(huì)變多，對(duì)應(yīng)的穩(wěn)定性風(fēng)險(xiǎn)就越高，那么如何保證高依賴的系統(tǒng)穩(wěn)定性呢？
解決方案：
現(xiàn)金紅包入賬最基礎(chǔ)要保障的功能，
是將用戶得到的紅包進(jìn)行入賬，
核心的功能，需要支持冪等與預(yù)算控制（避免超發(fā)），
紅包賬戶的冪等設(shè)計(jì)強(qiáng)依賴數(shù)據(jù)庫(kù)保持事務(wù)一致性。
但是如果極端情況發(fā)生，中間的鏈路可能會(huì)出現(xiàn)問題，如果是弱依賴，需要支持降級(jí)掉，不影響發(fā)放主流程。
錢包方向發(fā)紅包最短路徑為依賴服務(wù)實(shí)例計(jì)算資源和 MySQL 存儲(chǔ)資源實(shí)現(xiàn)現(xiàn)金紅包入賬。
發(fā)紅包強(qiáng)弱依賴梳理圖示：
| psm | 依賴服務(wù) | 是否強(qiáng)依賴 | 降級(jí)方案 | 降級(jí)后影響 |
|---|---|---|---|---|
| 資產(chǎn)中臺(tái) | tcc | 是 | 降級(jí)讀本地緩存 | 無(wú) |
| bytkekv | 否 | 主動(dòng)降級(jí)開關(guān)，跳過 bytekv，依賴下游做冪等 | 無(wú) | |
| 資金交易層 | 分布式鎖 Redis | 否 | 被動(dòng)降級(jí)，調(diào)用失敗，直接跳過 | 基本無(wú) |
| token Redis | 否 | 主動(dòng)降級(jí)開關(guān)，不調(diào)用 Redis | 用戶能感知到入賬有延遲，會(huì)有很多客訴 | |
| MySQL | 是 | 主有問題，聯(lián)系 dba 切主 | 故障期間發(fā)紅包不可用 |
大流量集中發(fā)券的一個(gè)場(chǎng)景，錢包側(cè)與算法策略配合進(jìn)行卡券發(fā)放庫(kù)存控制，防止超發(fā)。
具體實(shí)現(xiàn)：
（1）錢包資產(chǎn)中臺(tái)維護(hù)每個(gè)卡券模板 ID 的消耗發(fā)放量。
（2）每次卡券發(fā)放前，讀取該卡券模板 ID 的消耗量以及總庫(kù)存數(shù)。同時(shí)會(huì)設(shè)置一個(gè)閾值，如果卡券剩余量小于 10%后不發(fā)這個(gè)券（使用兜底券或者祝福語(yǔ)進(jìn)行兜底）。
（3） 發(fā)券流程 累計(jì)每個(gè)券模板 ID 的消耗量（使用 Redis incr 命令原子累加消耗量），然后與總活動(dòng)庫(kù)存進(jìn)行比對(duì)，如果消耗量大于總庫(kù)存數(shù)則拒絕掉，防止超發(fā)，也是一個(gè)兜底流程。
具體流程圖：
優(yōu)化方向：
（1）大流量下使用 Redis 計(jì)數(shù)，單 key 會(huì)存在熱 key 問題，需要拆分 key 來(lái)解決。
（2）大流量場(chǎng)景下，操作 Redis 會(huì)存在超時(shí)問題，返回上游處理中，上游繼續(xù)重試發(fā)券，會(huì)多消耗庫(kù)存少發(fā)，本次春節(jié)活動(dòng)實(shí)際活動(dòng)庫(kù)存在預(yù)估庫(kù)存基礎(chǔ)上加了 5%的量級(jí)來(lái)緩解超時(shí)帶來(lái)的少發(fā)問題。
4.5 難點(diǎn)五：高 QPS 場(chǎng)景下的熱 key 的讀取和寫入穩(wěn)定性保障大流量預(yù)估讀取有 180wQPS，寫入 30wQPS。
這是典型的超大流量，熱點(diǎn) key、更新延遲不敏感，非數(shù)據(jù)強(qiáng)一致性場(chǎng)景（數(shù)字是一直累加），
同時(shí)要做好容災(zāi)降級(jí)處理，最后實(shí)際活動(dòng)展示的金額與產(chǎn)品預(yù)計(jì)發(fā)放數(shù)值誤差小于 1%。
高 QPS 下的讀取和寫入單 key，比較容易想到的是使用 Redis 分布式緩存來(lái)進(jìn)行實(shí)現(xiàn)，但是單 key 讀取和寫入的會(huì)打到一個(gè)實(shí)例上，壓測(cè)過單實(shí)例的瓶頸為 3w QPS。
所以做的一個(gè)優(yōu)化是拆分多個(gè) key，然后用本地緩存兜底。
具體寫入流程：
設(shè)計(jì)拆分 100 個(gè) key，每次發(fā)紅包根據(jù)請(qǐng)求的 actID%100 使用 incr 命令累加該數(shù)字，因?yàn)椴荒鼙ＷC冪等性，所以超時(shí)不重試。
讀取流程：
與寫入流程類似，優(yōu)先讀取本地緩存，
如果本地緩存值為為 0，那么去讀取各個(gè) Redis 的 key 值累加到一起，進(jìn)行返回。
問題：
（1）拆分 100 個(gè) key 會(huì)出現(xiàn)讀擴(kuò)散的問題，需要申請(qǐng)較多 Redis 資源，存儲(chǔ)成本比較高。
而且可能存在讀取超時(shí)問題，不能保證一次讀取所有 key 都讀取成功，故返回的結(jié)果可能會(huì)較上一次有減少。
（2）容災(zāi)方案方面，如果申請(qǐng)備份 Redis，也需要較多的存儲(chǔ)資源，需要的額外存儲(chǔ)成本。
4.5.2 方案二設(shè)計(jì)思路：
在方案一實(shí)現(xiàn)的基礎(chǔ)上進(jìn)行優(yōu)化，
在寫場(chǎng)景，通過本地緩存進(jìn)行合并寫請(qǐng)求，進(jìn)行原子性累加，
讀場(chǎng)景返回本地緩存的值，減少額外的存儲(chǔ)資源占用。
使用 Redis 實(shí)現(xiàn)中心化存儲(chǔ)，最終大家讀到的值都是一樣的。
具體設(shè)計(jì)方案：
每個(gè) docker 實(shí)例啟動(dòng)時(shí)都會(huì)執(zhí)行定時(shí)任務(wù)，分為讀 Redis 任務(wù)和寫 Redis 任務(wù)。
讀取流程：
本地的定時(shí)任務(wù)每秒執(zhí)行一次，
讀取 Redis 單 key 的值，如果獲取到的值大于本地緩存那么更新本地緩存的值。
對(duì)外暴露的 sdk 直接返回本地緩存的值即可。
有個(gè)問題需要注意下，每次實(shí)例啟動(dòng)第一秒內(nèi)是沒有數(shù)據(jù)的，所以會(huì)阻塞讀，等有數(shù)據(jù)再返回。
寫入流程：
因?yàn)樽x取都是讀取本地緩存（本地緩存不過期），所以處理好并發(fā)情況下的寫即可。
本地緩存寫變量使用 go 的 atomic.AddInt64 支持原子性累加本地寫緩存的值。
每次執(zhí)行更新 Redis 的定時(shí)任務(wù)，
先將本地寫緩存復(fù)制到 amount 變量，最后將 amount 的值 incr 到 Redis 單 key 上，實(shí)現(xiàn) Redis 的單 key 的值一直累加。
容災(zāi)方案是使用備份 Redis 集群，寫入時(shí)進(jìn)行雙寫，
一旦主機(jī)群掛掉，設(shè)計(jì)了一個(gè)配置開關(guān)支持讀取備份 Redis。兩個(gè) Redis 集群的數(shù)據(jù)一致性，通過定時(shí)任務(wù)兜底實(shí)現(xiàn)。
具體寫入流程圖如下：
本方案調(diào)用 Redis 的流量是跟實(shí)例數(shù)成正比，
經(jīng)調(diào)研讀取側(cè)的服務(wù)為主會(huì)場(chǎng)實(shí)例數(shù) 2 萬(wàn)個(gè)，寫入側(cè)服務(wù)為資產(chǎn)中臺(tái)實(shí)例數(shù) 8 千個(gè)，
所以實(shí)際 Redis 要支持的 QPS 為 2.8 萬(wàn)/定時(shí)任務(wù)執(zhí)行間隔（單位為 s），
經(jīng)壓測(cè)驗(yàn)證 Redis 單實(shí)例可以支持單 key2 萬(wàn) get，8k incr 的操作，
所以設(shè)置定時(shí)任務(wù)的執(zhí)行時(shí)間間隔是 1s，如果實(shí)例數(shù)更多可以考慮延長(zhǎng)執(zhí)行時(shí)間間隔。
4.5.3 方案對(duì)比| 優(yōu)點(diǎn) | 缺點(diǎn) | |
|---|---|---|
| 方案一 | 1. 實(shí)現(xiàn)成本簡(jiǎn)單 | 1. 浪費(fèi)存儲(chǔ)資源； 2. 難以做容災(zāi)； 3. 不能做到一直累加； |
| 方案二 | 1. 節(jié)約資源； 2. 容災(zāi)方案比較簡(jiǎn)單，同時(shí)也節(jié)約資源成本； | 1. 實(shí)現(xiàn)稍復(fù)雜，需要考慮好并發(fā)原子性累加問題 |
結(jié)論：
從實(shí)現(xiàn)效果，資源成本和容災(zāi)等方面考慮，最終選擇了方案二上線。
4.6 難點(diǎn)六：大流量場(chǎng)景下資金安全保障錢包方向在本次春節(jié)活動(dòng)期間做了三件事情來(lái)保障大流量大預(yù)算的現(xiàn)金紅包發(fā)放的資金安全：
多維度核對(duì)示意圖：
準(zhǔn)實(shí)時(shí)對(duì)賬流程圖：
說(shuō)明：
準(zhǔn)實(shí)時(shí)對(duì)賬監(jiān)控和報(bào)警可以及時(shí)發(fā)現(xiàn)是否異常入賬情況，如果報(bào)警發(fā)現(xiàn)會(huì)有緊急預(yù)案處理。
5. 通用模式抽象在經(jīng)歷過春節(jié)超大流量活動(dòng)后的設(shè)計(jì)與實(shí)現(xiàn)后，有一些總結(jié)和經(jīng)驗(yàn)與大家一起分享一下。
5.1 容災(zāi)降級(jí)層面大流量場(chǎng)景，為了保證活動(dòng)最終上線效果，容災(zāi)是一定要做好的。
參考業(yè)界通用實(shí)現(xiàn)方案，如降級(jí)、限流、熔斷、資源隔離，根據(jù)預(yù)估活動(dòng)參與人數(shù)和效果進(jìn)行使用存儲(chǔ)預(yù)估等。
5.1.1 限流層面（1）限流方面應(yīng)用了 api 層 nginx 入流量限流，分布式入流量限流，分布式出流量限流。
這幾個(gè)限流器都是字節(jié)跳動(dòng)公司層面公共的中間件，經(jīng)過大流量的驗(yàn)證。
（2）首先進(jìn)行了實(shí)際單實(shí)例壓測(cè)，根據(jù)單實(shí)例扛住的流量與本次春節(jié)活動(dòng)預(yù)估流量打到該服務(wù)的流量進(jìn)行擴(kuò)容，并結(jié)合下游能抗住的情況，
在 tlb 入流量、入流量限流以及出流量限流分別做好了詳細(xì)完整的配置并同。
限流目標(biāo)：
保證自身服務(wù)穩(wěn)定性，防止外部預(yù)期外流量把本身服務(wù)打垮，防止造成雪崩效應(yīng)，保證核心業(yè)務(wù)和用戶核心體驗(yàn)。
簡(jiǎn)單集群限流是實(shí)例維度的限流，
每個(gè)實(shí)例限流的 QPS=總配置限流 QPS/實(shí)例數(shù)，
對(duì)于多機(jī)器低 QPS 可能會(huì)有不準(zhǔn)的情況，要經(jīng)過實(shí)際壓測(cè)并且及時(shí)調(diào)整配置值。
對(duì)于分布式入流量和出流量限流，兩種使用方式如下，每種方式都支持高低 QPS，區(qū)別只是 SDK 使用方式和功能不同。
一般低 QPS 精度要求高，采用 redis 計(jì)數(shù)方式，使用方提供自己的 redis 集群。
高 QPS 精度要求低，退化為總 QPS/tce 實(shí)例數(shù)的單實(shí)例限流。
5.1.2 降級(jí)層面對(duì)于高流量場(chǎng)景，每個(gè)核心功能都要有對(duì)應(yīng)的降級(jí)方案來(lái)保證突發(fā)情況核心鏈路的穩(wěn)定性。
（1）本次春節(jié)獎(jiǎng)勵(lì)入賬與活動(dòng)活動(dòng)錢包頁(yè)方向做好了充分的操作預(yù)案，一共有 26 個(gè)降級(jí)開關(guān)，關(guān)鍵時(shí)刻棄車保帥，防止有單點(diǎn)問題影響核心鏈路。
（2）以發(fā)現(xiàn)金紅包鏈路舉例，錢包方向最后完全降級(jí)的方案是只依賴 docker 和 MySQL，其他依賴都是可以降級(jí)掉的，MySQL 主有問題可以緊急聯(lián)系切主，雖說(shuō)最后一個(gè)都沒用上，但是前提要設(shè)計(jì)好保證活動(dòng)的萬(wàn)無(wú)一失。
5.1.3 資源隔離層面（1）提升開發(fā)效率不重復(fù)造輪子。
因?yàn)殄X包資產(chǎn)中臺(tái)也日常支持抖音資產(chǎn)發(fā)放的需求，本次春節(jié)活動(dòng)也復(fù)用了現(xiàn)有的接口和代碼流程支持發(fā)獎(jiǎng)。
（2）同時(shí)針對(duì)本次春節(jié)活動(dòng)，服務(wù)層面做了集群隔離，
創(chuàng)建專用活動(dòng)集群，底層存儲(chǔ)資源隔離，活動(dòng)流量和常規(guī)流量互不影響。
5.1.4 存儲(chǔ)預(yù)估（1）不但要考慮和驗(yàn)證了 Redis 或者 MySQL 存儲(chǔ)能抗住對(duì)應(yīng)的流量，同時(shí)也要按照實(shí)際的獲取參與和發(fā)放數(shù)據(jù)等預(yù)估存儲(chǔ)資源是否足夠。
（2）對(duì)于字節(jié)跳動(dòng)公司的 Redis 組件來(lái)講，
可以進(jìn)行垂直擴(kuò)容（每個(gè)實(shí)例增加存儲(chǔ)，大 10G），也可以進(jìn)行水平擴(kuò)容（單機(jī)房上限是 500 個(gè)實(shí)例），因?yàn)?Redis 是三機(jī)房同步的，所以計(jì)算存儲(chǔ)時(shí)只考慮一個(gè)機(jī)房的存儲(chǔ)上限即可。
要留足 buffer，因?yàn)樗綌U(kuò)容是很慢的一個(gè)過程，突發(fā)情況遇到存儲(chǔ)資源不足只能通過配置開關(guān)提前下掉依賴存儲(chǔ)，需要提前設(shè)計(jì)好。
5.1.5 壓測(cè)層面本次春節(jié)活動(dòng)，錢包獎(jiǎng)勵(lì)入賬和活動(dòng)錢包頁(yè)做了充分的全鏈路壓測(cè)驗(yàn)證，下面是一些經(jīng)驗(yàn)總結(jié)。
在日常技術(shù)設(shè)計(jì)中，大家都會(huì)遵守微服務(wù)設(shè)計(jì)原則和規(guī)范，根據(jù)系統(tǒng)職責(zé)和核心數(shù)據(jù)模型拆分不同模塊，提升開發(fā)迭代效率并不互相影響。
但是微服務(wù)也有它的弊端，對(duì)于超大流量的場(chǎng)景功能也比較復(fù)雜，會(huì)經(jīng)過多個(gè)鏈路，這樣是極其消耗計(jì)算資源的。
本次春節(jié)活動(dòng)資產(chǎn)中臺(tái)提供了 sdk 包代替 rpc 進(jìn)行微服務(wù)鏈路聚合對(duì)外提供基礎(chǔ)能力，如查詢余額、判斷用戶是否獲取過獎(jiǎng)勵(lì)，強(qiáng)制入賬等功能。訪問流量最高上千萬(wàn)，與使用微服務(wù)架構(gòu)對(duì)比節(jié)約了上萬(wàn)核 CPU 的計(jì)算資源。
6. 系統(tǒng)的未來(lái)演進(jìn)方向（1）梳理上下游需求和痛點(diǎn)，優(yōu)化資產(chǎn)中臺(tái)設(shè)計(jì)實(shí)現(xiàn)，完善基礎(chǔ)能力，優(yōu)化服務(wù)架構(gòu)，提供一站式服務(wù)，讓接入活動(dòng)方可以更專注進(jìn)行活動(dòng)業(yè)務(wù)邏輯的研發(fā)工作。
（2）加強(qiáng)實(shí)時(shí)和離線數(shù)據(jù)看板能力建設(shè)，讓獎(jiǎng)勵(lì)發(fā)放數(shù)據(jù)展示的更清晰更準(zhǔn)確。
（3）加強(qiáng)配置化和文檔建設(shè)，對(duì)內(nèi)減少對(duì)接活動(dòng)的對(duì)接成本，對(duì)外提升活動(dòng)業(yè)務(wù)方接入效率。
推薦閱讀：上文參考來(lái)源：字節(jié)跳動(dòng)技術(shù)團(tuán)隊(duì)：春節(jié)錢包大流量獎(jiǎng)勵(lì)系統(tǒng)入賬及展示的設(shè)計(jì)與實(shí)現(xiàn)
《Docker面試題（史上最全 + 持續(xù)更新）》
《 場(chǎng)景題：假設(shè)10W人突訪，你的系統(tǒng)如何做到不 雪崩？》
《尼恩Java面試寶典》
《Springcloud gateway 底層原理、核心實(shí)戰(zhàn) (史上最全)》
《Flux、Mono、Reactor 實(shí)戰(zhàn)（史上最全）》
《sentinel （史上最全）》
《Nacos (史上最全)》
《分庫(kù)分表 Sharding-JDBC 底層原理、核心實(shí)戰(zhàn)（史上最全）》
《TCP協(xié)議詳解 (史上最全)》
《clickhouse 超底層原理 + 高可用實(shí)操 （史上最全）》
《nacos高可用（圖解+秒懂+史上最全）》
《隊(duì)列之王： Disruptor 原理、架構(gòu)、源碼 一文穿透》
《環(huán)形隊(duì)列、 條帶環(huán)形隊(duì)列 Striped-RingBuffer （史上最全）》
《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關(guān)系（史上最全）
《單例模式（史上最全）
《紅黑樹（ 圖解 + 秒懂 + 史上最全）》
《分布式事務(wù) （秒懂）》
《緩存之王：Caffeine 源碼、架構(gòu)、原理（史上最全，10W字 超級(jí)長(zhǎng)文）》
《緩存之王：Caffeine 的使用（史上最全）》
《Java Agent 探針、字節(jié)碼增強(qiáng) ByteBuddy（史上最全）》
《Docker原理（圖解+秒懂+史上最全）》
《Redis分布式鎖（圖解 - 秒懂 - 史上最全）》
《Zookeeper 分布式鎖 - 圖解 - 秒懂》
《Zookeeper Curator 事件監(jiān)聽 - 10分鐘看懂》
《Netty 粘包 拆包 | 史上最全解讀》
《Netty 100萬(wàn)級(jí)高并發(fā)服務(wù)器配置》
《Springcloud 高并發(fā) 配置 （一文全懂）》
你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購(gòu)，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧
