“世界杯”這三個(gè)字一出來幾乎所有做產(chǎn)品和技術(shù)的同事第一反應(yīng)都是又要打仗了。作為曾經(jīng)在某體育社區(qū)完整做過一屆世界杯互動(dòng)項(xiàng)目的開發(fā)者我太清楚這種“大節(jié)日”項(xiàng)目的特殊性——需求多、時(shí)間緊、數(shù)據(jù)要求實(shí)時(shí)、用戶量像過山車一樣忽高忽低。更麻煩的是每次這種項(xiàng)目都是臨時(shí)組隊(duì)有人擅長后端有人只會(huì)調(diào)前端真正能在兩周內(nèi)把一個(gè)能扛住千萬級(jí)訪問的互動(dòng)平臺(tái)搭起來的人少之又少。近兩年我逐漸摸索出一套更務(wù)實(shí)的打法基于預(yù)制源碼做二次開發(fā)再疊加專業(yè)API服務(wù)快速補(bǔ)齊數(shù)據(jù)與功能短板。這個(gè)方法不是偷懶而是在有限時(shí)間窗口內(nèi)把人力集中在真正能產(chǎn)生差異化的業(yè)務(wù)邏輯上比如競(jìng)猜玩法設(shè)計(jì)、互動(dòng)氛圍營造、以及流量頂峰的穩(wěn)定性預(yù)案。這篇文章完整梳理一下我是怎么做的、踩了哪些坑、以及哪些步驟是你可以直接“抄作業(yè)”的。1. 整體設(shè)計(jì)思路拆解為什么是“預(yù)制源碼”加“專業(yè)API”1.1 從零開發(fā)為什么“必死”世界杯項(xiàng)目的時(shí)間窗口極其特殊開賽前一個(gè)月往往是需求才最終凍結(jié)開賽后第二天就要見真章。如果從零開始做按常規(guī)流程走完需求評(píng)審、原型確認(rèn)、UI設(shè)計(jì)、前后端開發(fā)、聯(lián)調(diào)測(cè)試、壓測(cè)優(yōu)化兩個(gè)月都不一定夠。就算團(tuán)隊(duì)加班加點(diǎn)勉強(qiáng)趕上線上出問題的概率也是成倍增長。我見過不少團(tuán)隊(duì)死磕自研最后憋出了一個(gè)“能用但不好用”的系統(tǒng)直播彈幕卡成PPT競(jìng)猜入口在流量峰值直接宕機(jī)積分榜單數(shù)據(jù)錯(cuò)亂。問題不在開發(fā)者的編碼能力而在“時(shí)間密度”這件事上——越急的活兒越不能純靠人肉堆代碼。預(yù)制源碼的核心價(jià)值就在這里它把那些已經(jīng)被驗(yàn)證過、被反復(fù)打磨過的通用能力比如用戶注冊(cè)登錄、積分系統(tǒng)、競(jìng)猜底表結(jié)構(gòu)、排行榜緩存策略直接封裝成一個(gè)能跑起來的骨架。你要做的不是重新發(fā)明輪子而是在這個(gè)骨架上填入世界杯專屬的業(yè)務(wù)血肉。根據(jù)我的經(jīng)驗(yàn)選用合適的預(yù)制源碼前期準(zhǔn)備工作能節(jié)省至少60%的時(shí)間。1.2 預(yù)制源碼選型的三條硬指標(biāo)市面上號(hào)稱“世界杯源碼”的產(chǎn)品很多但質(zhì)量參差不齊。我總結(jié)出三條硬性篩選標(biāo)準(zhǔn)缺一不可。第一模塊匹配度要高。比如你要做競(jìng)猜玩法源碼里就得有完整的競(jìng)猜底層數(shù)據(jù)結(jié)構(gòu)比如場(chǎng)次表、用戶投注表、結(jié)算流水表而不是讓你自己去設(shè)計(jì)數(shù)據(jù)庫。哪怕表結(jié)構(gòu)不那么完美也能省下大量從零建模的時(shí)間和試錯(cuò)成本。第二技術(shù)棧要和你團(tuán)隊(duì)熟悉的一致。這個(gè)太重要了。如果你團(tuán)隊(duì)主攻Java非要搞一套PHP源碼后續(xù)改起來就是災(zāi)難。技術(shù)棧的熟悉程度直接決定了二次開發(fā)的效率不要在這個(gè)環(huán)節(jié)貪圖源碼“看起來功能多”而忽視團(tuán)隊(duì)能力的匹配。第三授權(quán)和合規(guī)必須明確。我見過有源碼聲稱完全開源結(jié)果里面藏著多個(gè)未授權(quán)的商業(yè)組件差點(diǎn)引發(fā)版權(quán)事故。商業(yè)使用授權(quán)是否清晰有沒有隱藏的域名綁定、授權(quán)碼驗(yàn)證這些如果不提前核實(shí)后期會(huì)很被動(dòng)。合規(guī)問題在大廠里尤其敏感哪怕個(gè)人開發(fā)者也應(yīng)該養(yǎng)成先看License再動(dòng)手的習(xí)慣。1.3 專業(yè)API的邊界劃分什么該調(diào)、什么不該調(diào)不是所有功能都適合靠API解決。我一般把候選功能分為三類匹配不同策略。類別一數(shù)據(jù)源型API比如實(shí)時(shí)比分、球隊(duì)資料、賽程信息。這類數(shù)據(jù)需要專業(yè)數(shù)據(jù)服務(wù)商提供自己抓取不僅穩(wěn)定性差還有版權(quán)風(fēng)險(xiǎn)。這種必須用API。類別二能力型API比如短信驗(yàn)證碼、對(duì)象存儲(chǔ)、內(nèi)容安全檢測(cè)。這類是底層基礎(chǔ)設(shè)施自己做成本高且不一定做得比專業(yè)服務(wù)好建議直接集成。類別三業(yè)務(wù)型API比如競(jìng)猜邏輯、積分發(fā)放、排行榜計(jì)算。這類涉及復(fù)雜業(yè)務(wù)規(guī)則和狀態(tài)流轉(zhuǎn)自己做更能掌控細(xì)節(jié)不建議依賴外部API除非你的業(yè)務(wù)極其簡單且API價(jià)格足夠便宜。舉一個(gè)實(shí)際例子你可以通過專業(yè)數(shù)據(jù)API快速拿到比賽的實(shí)時(shí)狀態(tài)、比分和統(tǒng)計(jì)信息但如果直接用這套數(shù)據(jù)去跑競(jìng)猜結(jié)算很容易出現(xiàn)數(shù)據(jù)口徑不一致的問題。我的做法是外部API只負(fù)責(zé)“展示層”的比分刷新真正決定用戶是否中獎(jiǎng)的結(jié)算數(shù)據(jù)以官方賽后確認(rèn)的數(shù)據(jù)為準(zhǔn)做一次兜底校準(zhǔn)。這就是業(yè)務(wù)型邏輯不能外包的核心原因——你永遠(yuǎn)要對(duì)用戶的資產(chǎn)狀態(tài)負(fù)責(zé)。1.4 整體架構(gòu)如何分層我用一個(gè)比較通用的四層架構(gòu)來組織整個(gè)平臺(tái)預(yù)制源碼和API服務(wù)各司其職接入層負(fù)責(zé)用戶請(qǐng)求入口包括負(fù)載均衡、CDN加速、API網(wǎng)關(guān)。這一層主要靠云廠商能力不太需要自己寫代碼。業(yè)務(wù)服務(wù)層承載核心互動(dòng)邏輯包括用戶體系、競(jìng)猜下注、簽到任務(wù)、積分商城、排行榜。這一層的主體來自預(yù)制源碼二次開發(fā)重點(diǎn)也在這里。數(shù)據(jù)層包含MySQL主庫核心業(yè)務(wù)數(shù)據(jù)、Redis緩存熱點(diǎn)數(shù)據(jù)、排行數(shù)據(jù)、以及消息隊(duì)列異步任務(wù)解耦。預(yù)制源碼通常會(huì)提供一套可運(yùn)行的數(shù)據(jù)庫腳本但我會(huì)根據(jù)業(yè)務(wù)場(chǎng)景做一定調(diào)整。外部服務(wù)層通過專業(yè)API接入實(shí)時(shí)數(shù)據(jù)、短信服務(wù)、內(nèi)容安全檢測(cè)、對(duì)象存儲(chǔ)等。這一層的調(diào)用邏輯需要做好超時(shí)和降級(jí)處理防止外部服務(wù)抖動(dòng)拖垮核心鏈路。分層的好處是顯而易見的每一層都可以獨(dú)立替換和擴(kuò)展。比如你覺得某家數(shù)據(jù)API不好用了只需要在外部服務(wù)層做一個(gè)適配器改造完全不影響業(yè)務(wù)服務(wù)層的穩(wěn)定運(yùn)行。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)預(yù)制源碼的二次開發(fā)關(guān)鍵點(diǎn)2.1 用戶體系與鑒權(quán)不能直接湊合用大多數(shù)預(yù)制源碼會(huì)自帶一套簡單的用戶系統(tǒng)比如手機(jī)號(hào)加密碼注冊(cè)、用戶表、登錄態(tài)通過Session或簡單Token管理。直接湊合用行不行行但擔(dān)風(fēng)險(xiǎn)。世界杯期間的流量特征極其明顯開球前半小時(shí)是登錄高峰中場(chǎng)休息是競(jìng)猜和分享高峰。如果用戶體系在登錄環(huán)節(jié)就出現(xiàn)瓶頸后面的所有互動(dòng)都無從談起。所以我把用戶體系的改造放在優(yōu)先級(jí)最高的位置。實(shí)際操作上我會(huì)做以下幾件事第一引入獨(dú)立的鑒權(quán)服務(wù)。把登錄態(tài)從簡單的Session升級(jí)為自帶過期時(shí)間與刷新機(jī)制的Token體系并且把Token的校驗(yàn)做成無狀態(tài)方便水平擴(kuò)容。前端每次請(qǐng)求帶上Access Token過期后通過Refresh Token無感續(xù)期避免用戶在比賽最激烈的時(shí)候被強(qiáng)制踢下線。第二綁定第三方快捷登錄。預(yù)制源碼里如果有微信或QQ登錄優(yōu)先激活。實(shí)測(cè)下來世界杯競(jìng)猜這種泛娛樂場(chǎng)景用戶很反感輸入手機(jī)號(hào)注冊(cè)第三方一鍵登錄的轉(zhuǎn)化率是傳統(tǒng)注冊(cè)方式的3倍以上。第三做好風(fēng)控前置。世界杯期間刷競(jìng)猜積分、批量注冊(cè)小號(hào)的行為非常猖獗。這塊不要自己硬寫規(guī)則引擎直接集成專業(yè)的內(nèi)容安全或風(fēng)控API在注冊(cè)、投注兩個(gè)關(guān)鍵節(jié)點(diǎn)做風(fēng)險(xiǎn)識(shí)別。某次比賽夜我靠風(fēng)控API攔下了上萬個(gè)異常賬號(hào)的注冊(cè)請(qǐng)求提前量非常關(guān)鍵。2.2 實(shí)時(shí)比分與賽程數(shù)據(jù)流決定體驗(yàn)下限世界杯互動(dòng)平臺(tái)最核心的體驗(yàn)就是“實(shí)時(shí)”。用戶看直播的時(shí)候打開你的平臺(tái)屏幕上必須得同步刷出比分、進(jìn)球事件、紅黃牌等關(guān)鍵信息。如果這里卡頓5秒用戶就會(huì)立刻切走而且大概率不會(huì)再回來。這件事的實(shí)現(xiàn)在工程上并不復(fù)雜專業(yè)數(shù)據(jù)API提供增量賽事數(shù)據(jù)你的服務(wù)端每隔若干秒拉取一次然后通過WebSocket推送到客戶端。難的是怎么保證“推”這個(gè)過程穩(wěn)定且不浪費(fèi)資源。我的做法是分級(jí)推送對(duì)于比賽狀態(tài)變化未開賽、進(jìn)行中、已結(jié)束采用廣播方式所有客戶端都能第一時(shí)間收到狀態(tài)更新。對(duì)于進(jìn)球、紅黃牌這類高關(guān)注度事件采用事件廣播加Push通知的方式讓未打開App的用戶也能收到消息。對(duì)于場(chǎng)上普通數(shù)據(jù)比如控球率、射門次數(shù)采用低頻拉取加差異對(duì)比更新減少無效推送量。同時(shí)嚴(yán)格控制WebSocket消息體的體積。有些團(tuán)隊(duì)喜歡把整個(gè)比賽對(duì)象推送給客戶端一傳就是十幾KB用戶一多帶寬立刻告急。我習(xí)慣只推變化字段客戶端自己維護(hù)一份比賽快照做合并實(shí)測(cè)下來推送量能減少近80%。2.3 競(jìng)猜玩法狀態(tài)機(jī)與冪等保護(hù)缺一不可競(jìng)猜是世界杯互動(dòng)平臺(tái)變現(xiàn)和活躍用戶的核心手段同時(shí)也是最容易出事故的模塊。我見過太多案例用戶投注時(shí)按鈕點(diǎn)擊沒反應(yīng)一查是數(shù)據(jù)庫連接池被打滿也見過重復(fù)扣積分用戶發(fā)起兩次競(jìng)猜請(qǐng)求都成功了余額直接變負(fù)數(shù)。競(jìng)猜玩法在預(yù)制源碼中往往已經(jīng)有一套基礎(chǔ)實(shí)現(xiàn)但通常只覆蓋“單場(chǎng)勝負(fù)平”這種簡單模式。如果要做小組出線預(yù)測(cè)、冠亞軍競(jìng)猜、進(jìn)球數(shù)競(jìng)猜這類更復(fù)雜的玩法數(shù)據(jù)結(jié)構(gòu)就要自行擴(kuò)展。我強(qiáng)烈建議把所有競(jìng)猜狀態(tài)用狀態(tài)機(jī)來管理。比如競(jìng)猜流程可以拆成可投注、鎖定中、結(jié)算中、已結(jié)算、已退款。每一個(gè)狀態(tài)轉(zhuǎn)移都要滿足特定條件比如“鎖定中”這個(gè)狀態(tài)必須在比賽開始前5分鐘由定時(shí)任務(wù)統(tǒng)一觸發(fā)而不是依賴用戶操作。狀態(tài)機(jī)的好處是線上問題排查變得非常直觀你問自己“這個(gè)競(jìng)猜為什么不能投注”一查狀態(tài)值就知道是卡在了“鎖定中”還是已經(jīng)“已結(jié)算”。冪等保護(hù)是另一個(gè)容易忽略的細(xì)節(jié)。用戶很可能用兩臺(tái)設(shè)備同時(shí)登錄在秒級(jí)窗口內(nèi)提交了兩次相同的競(jìng)猜請(qǐng)求。后端必須通過唯一業(yè)務(wù)流水號(hào)比如用戶ID加場(chǎng)次ID加競(jìng)猜類型來判重保證同一邏輯請(qǐng)求只處理一次。這個(gè)前置判斷沒做好后面再靠對(duì)賬補(bǔ)數(shù)據(jù)就非常被動(dòng)。2.4 排行榜與積分體系緩存策略決定實(shí)時(shí)性排行榜在預(yù)制源碼里最常見的大坑是直接用SQL的CountGroup By去實(shí)時(shí)統(tǒng)計(jì)數(shù)據(jù)。在數(shù)據(jù)量小的時(shí)候沒問題一旦競(jìng)猜參與人數(shù)過萬這種查詢基本就是數(shù)據(jù)庫的災(zāi)難。我采用的方案是雙層排行榜第一層是實(shí)時(shí)內(nèi)存排行榜基于Redis的有序集合實(shí)現(xiàn)用戶每次競(jìng)猜或積分變動(dòng)后直接更新應(yīng)對(duì)“實(shí)時(shí)排名”的展示需求。第二層是異步離線榜單通過消息隊(duì)列把積分變動(dòng)事件異步落庫每隔幾分鐘計(jì)算一次全量排名應(yīng)對(duì)“歷史榜單歸檔”和“榜單結(jié)算發(fā)獎(jiǎng)”的需求。中間還夾了一個(gè)小技巧不要為了追求“秒級(jí)”實(shí)時(shí)性讓每次積分變動(dòng)都同步刷新全量榜單。Redis有序集合的更新復(fù)雜度是Log級(jí)寫入確實(shí)很快但客戶端排行榜頁面的讀取頻率遠(yuǎn)高于寫入我會(huì)加一層本地緩存或CDN緩存設(shè)置10到30秒的緩存時(shí)間用可接受的延遲換來極高的系統(tǒng)穩(wěn)定性。2.5 分享與傳播:預(yù)制功能只做了一半預(yù)制源碼通常會(huì)提供一個(gè)分享功能比如生成一張圖片海報(bào)用戶可以保存到本地發(fā)朋友圈。但世界杯場(chǎng)景里分享裂變的核心不在于“生成海報(bào)”而在于“通過分享回流后怎么識(shí)別歸屬”。我每次都會(huì)在分享鏈路上加一個(gè)帶渠道參數(shù)的短鏈并把參數(shù)寫入用戶畫像。比如一個(gè)用戶A分享了某場(chǎng)比賽的競(jìng)猜海報(bào)他的朋友B通過這張海報(bào)進(jìn)入平臺(tái)并參與競(jìng)猜A就能獲得積分獎(jiǎng)勵(lì)。這個(gè)“老帶新”回流鏈路如果只靠預(yù)制源碼是做不到的必須自己加邏輯。關(guān)于分享海報(bào)有一個(gè)很容易忽略的合規(guī)問題如果海報(bào)上直接用了世界杯相關(guān)的官方標(biāo)識(shí)或球員照片很容易被平臺(tái)判定為侵權(quán)素材嚴(yán)重時(shí)觸發(fā)封禁。所以我會(huì)在分享圖里全部用自有的插畫元素和中性文字絕對(duì)不去碰官方Logo。細(xì)節(jié)雖小關(guān)鍵時(shí)刻卻能保住整個(gè)活動(dòng)的命。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)一步步把平臺(tái)跑起來3.1 階段一環(huán)境準(zhǔn)備與源碼初始化拿到預(yù)制源碼后我建議先不要急著改代碼而是花一天時(shí)間把環(huán)境完整跑起來。所謂“跑起來”不是指本地能打開首頁而是注冊(cè)登錄、競(jìng)猜下注、排行榜展示、后臺(tái)管理這四個(gè)主鏈路全部走通。我通常在Linux服務(wù)器上用Docker Compose一鍵初始化環(huán)境包含MySQL、Redis、Nginx和應(yīng)用容器。預(yù)制源碼如果自帶了安裝腳本一般會(huì)很順利如果沒有就需要手動(dòng)補(bǔ)一個(gè)順便摸清整個(gè)系統(tǒng)的依賴關(guān)系。這一步最關(guān)鍵的產(chǎn)出物是一張全局配置清單記錄數(shù)據(jù)庫連接串、Redis地址、存儲(chǔ)桶名、短信服務(wù)AK等所有敏感配置項(xiàng)。我的習(xí)慣是把這些配置收斂到一個(gè)獨(dú)立配置文件中而不是散落在源碼各處這樣后續(xù)換環(huán)境或者在多個(gè)機(jī)器上部署會(huì)省很多事。3.2 階段二專業(yè)API集成以實(shí)時(shí)數(shù)據(jù)為例我們以實(shí)時(shí)比分?jǐn)?shù)據(jù)接入為例講解API集成的標(biāo)準(zhǔn)流程。市面上主流數(shù)據(jù)服務(wù)商提供的都是標(biāo)準(zhǔn)REST接口鑒權(quán)方式一般是API Key加簽名。我在接入時(shí)重點(diǎn)考慮三個(gè)問題接口限流規(guī)模、輪詢頻率上限、數(shù)據(jù)延遲指標(biāo)。假設(shè)數(shù)據(jù)服務(wù)商允許每秒調(diào)用10次每場(chǎng)比賽的數(shù)據(jù)可以通過一個(gè)請(qǐng)求獲取。那么理論上同時(shí)運(yùn)行50場(chǎng)比賽小組賽最后一輪甚至更多采用異步并發(fā)請(qǐng)求完全可以在秒級(jí)刷新全部數(shù)據(jù)。但真實(shí)業(yè)務(wù)中我不會(huì)這樣做而是做一個(gè)簡單的分級(jí)調(diào)度重點(diǎn)比賽如焦點(diǎn)戰(zhàn)輪詢頻率高一些比如10秒一次普通比賽30秒一次已結(jié)束的比賽只在最終確認(rèn)時(shí)拉取一次。接入過程我一般按四步走第一步先通過SDK或直接HTTP Client完成一次真實(shí)的API調(diào)用確認(rèn)返回?cái)?shù)據(jù)結(jié)構(gòu)和官方文檔描述一致。第二步定義一套平臺(tái)內(nèi)部的標(biāo)準(zhǔn)賽事對(duì)象把外部API的字段映射到內(nèi)部對(duì)象。這樣未來如果切換數(shù)據(jù)服務(wù)商只需要改映射層代碼。第三步增加降級(jí)開關(guān)。如果外部API連續(xù)5次調(diào)用失敗自動(dòng)切換到備用數(shù)據(jù)源或者退化為“手動(dòng)比分狀態(tài)維護(hù)”模式由后臺(tái)運(yùn)營手工錄入比分。第四步寫一個(gè)定時(shí)任務(wù)做數(shù)據(jù)對(duì)賬。比分?jǐn)?shù)據(jù)是比賽結(jié)束后結(jié)算競(jìng)猜的唯一依據(jù)。我習(xí)慣在賽后30分鐘以上從數(shù)據(jù)服務(wù)商獲取最終結(jié)果和實(shí)時(shí)流里收到的比分做比對(duì)不一致時(shí)以對(duì)賬結(jié)果為準(zhǔn)。一個(gè)調(diào)試期的細(xì)節(jié)實(shí)時(shí)比分推送階段一定要把時(shí)間的同步誤差控制在1秒內(nèi)。如果服務(wù)端時(shí)間和客戶端時(shí)間偏差過大會(huì)出現(xiàn)“客戶端顯示比分已更新但WebSocket還沒推送”的錯(cuò)覺用戶會(huì)投訴數(shù)據(jù)不同步。3.3 階段三競(jìng)猜模塊核心邏輯實(shí)現(xiàn)這部分是二次開發(fā)工作量最重的。我以最常用的“猜勝負(fù)”玩法為例子梳理一遍核心邏輯。競(jìng)猜模塊在數(shù)據(jù)庫層面至少要三張表競(jìng)猜場(chǎng)次表比賽信息可選結(jié)果截止時(shí)間、競(jìng)猜記錄表用戶ID選擇結(jié)果投注積分狀態(tài)、結(jié)算流水表場(chǎng)次ID中獎(jiǎng)結(jié)果用戶ID派獎(jiǎng)金額派獎(jiǎng)時(shí)間。業(yè)務(wù)邏輯上代碼里需要做這幾件事在投注階段校驗(yàn)當(dāng)前是否處于可投注狀態(tài)、用戶余額是否充足、是否已經(jīng)投注過全部通過后先扣減積分并記錄流水再插入競(jìng)猜記錄。這里有一個(gè)順序問題扣減積分和寫入競(jìng)猜記錄必須放在同一個(gè)數(shù)據(jù)庫事務(wù)里任何一個(gè)失敗都要回滾否則就會(huì)出現(xiàn)“積分扣了但競(jìng)猜沒記錄”的幽靈問題。在鎖定階段定時(shí)任務(wù)掃描所有即將開賽的場(chǎng)次把它們從可投注變?yōu)殒i定中同時(shí)禁止任何新投注。我習(xí)慣在比賽原定開賽時(shí)間前5分鐘鎖場(chǎng)給用戶一個(gè)“最后的投注窗口”。在結(jié)算階段根據(jù)對(duì)賬后的真實(shí)比分批量更新競(jìng)猜記錄的狀態(tài)計(jì)算中獎(jiǎng)金額并給中獎(jiǎng)用戶發(fā)積分。批量結(jié)算一定要用“每場(chǎng)一個(gè)事務(wù)”的方式避免一場(chǎng)比賽的殘次數(shù)據(jù)影響其他所有場(chǎng)次。在異常退款階段遇到比賽延期、腰斬等不可抗力要能快速回滾所有已投注的積分。這個(gè)流程在世界杯這種大賽里一定會(huì)遇到我和平臺(tái)運(yùn)營提前約定好觸發(fā)條件一旦收到官方延期通知運(yùn)營在后臺(tái)一鍵執(zhí)行減少用戶客訴壓力。3.4 階段四排行榜實(shí)時(shí)性優(yōu)化排行榜的核心痛點(diǎn)上一節(jié)已經(jīng)提到。這里給出一個(gè)實(shí)際可用的Redis實(shí)現(xiàn)思路。比分和積分變動(dòng)后后端代碼只需要一行命令把用戶ID和最新的積分值寫入有序集合ZADD rank:worldcup {積分} {用戶ID}。讀取排行榜時(shí)用ZREVRANGE命令取出Top100然后用類似ZSCORE的方式查詢當(dāng)前用戶自己的排名和積分。為了減少數(shù)據(jù)庫壓力排行榜數(shù)據(jù)不直接讀MySQL而是基于Redis的這份快照來展示。整套設(shè)計(jì)能做到即使有10萬用戶同時(shí)刷新排行榜Redis也能輕松扛住。當(dāng)需要生成排行榜歸檔時(shí)由定時(shí)任務(wù)周期性地把Redis快照寫到MySQL的歸檔表供后續(xù)發(fā)獎(jiǎng)和數(shù)據(jù)報(bào)表使用。記住一個(gè)原則實(shí)時(shí)展示走緩存持久存儲(chǔ)異步落庫。3.5 階段五上線前壓測(cè)與系統(tǒng)容量預(yù)估每年世界杯項(xiàng)目我都會(huì)給團(tuán)隊(duì)留出至少3天做壓測(cè)和容量規(guī)劃。別小看這個(gè)環(huán)節(jié)很多平臺(tái)就是在這里翻了車。首先做峰值預(yù)估假設(shè)你的平臺(tái)預(yù)計(jì)有200萬注冊(cè)用戶最極端情況下有20%的日活同時(shí)在線人數(shù)可能是日活的30%也就是12萬人。如果每個(gè)人都可能在開賽前1分鐘進(jìn)入頁面那這60秒內(nèi)大概會(huì)產(chǎn)生每秒數(shù)千次請(qǐng)求。再考慮到羊毛黨、爬蟲、自動(dòng)簽到腳本的流量建議把壓測(cè)目標(biāo)定在預(yù)估峰值的2到3倍。壓測(cè)工具我習(xí)慣用開源方案在自己的壓測(cè)機(jī)上模擬高并發(fā)請(qǐng)求。實(shí)測(cè)結(jié)果出來后重點(diǎn)看四個(gè)指標(biāo)接口成功率、平均響應(yīng)時(shí)間、錯(cuò)誤率、以及數(shù)據(jù)庫連接池的使用情況。如果發(fā)現(xiàn)某個(gè)接口成功率低于99.9%必須刨根問底不能帶著問題上線。容量冗余方面我的經(jīng)驗(yàn)是世界杯項(xiàng)目寧可空轉(zhuǎn)不要饑餓。數(shù)據(jù)庫和Redis一定要買比預(yù)估用量高一個(gè)檔次的規(guī)格CDN流量包也要提前備足。比賽日的流量像過山車有時(shí)候你以為已經(jīng)到頂了下一個(gè)熱點(diǎn)事件又把你推高一截。4. 常見問題與排查技巧實(shí)錄4.1 競(jìng)猜按鈕點(diǎn)了沒反應(yīng)數(shù)據(jù)庫連接池被打滿這是流量高峰期最典型的故障沒有之一?，F(xiàn)象是競(jìng)猜頁面能打開但一提交就轉(zhuǎn)圈過一會(huì)提示網(wǎng)絡(luò)超時(shí)。排查思路從慢查詢和連接數(shù)入手。我一般先用命令行查看MySQL當(dāng)前連接數(shù)再查慢查詢?nèi)罩?。如果是連接數(shù)打滿第一反應(yīng)不是無限調(diào)大連接池上限而是要找到“誰在長時(shí)間占用連接不釋放”。最常見的元兇是事務(wù)中執(zhí)行了外部API調(diào)用比如在投注事務(wù)里同步發(fā)送了一條短信通知導(dǎo)致事務(wù)長時(shí)間不提交連接被白白占用。解決方案有兩步第一把外部調(diào)用短信、消息推送全部改成MQ異步觸發(fā)從數(shù)據(jù)庫事務(wù)里徹底移除第二為讀接口和寫接口設(shè)置不同的數(shù)據(jù)庫賬號(hào)池讀接口的連接超時(shí)時(shí)間設(shè)短一些防止慢查詢把寫連接池也拖垮。4.2 實(shí)時(shí)比分和結(jié)算結(jié)果不一致外部API的鍋有一次實(shí)時(shí)數(shù)據(jù)API顯示A隊(duì)2比1獲勝但結(jié)算時(shí)卻按1比1平局處理大量用戶炸了。排查后發(fā)現(xiàn)數(shù)據(jù)服務(wù)商的實(shí)時(shí)數(shù)據(jù)流在比賽進(jìn)行中出現(xiàn)了短暫的數(shù)據(jù)回拔修正而我們的結(jié)算任務(wù)不小心讀到了修正前的臟數(shù)據(jù)。自從那次踩坑之后我立了一條鐵規(guī)矩實(shí)時(shí)數(shù)據(jù)僅供展示結(jié)算數(shù)據(jù)必須走對(duì)賬源。對(duì)賬源可以是數(shù)據(jù)服務(wù)商提供的最終結(jié)果接口也可以是官方賽后統(tǒng)計(jì)但絕對(duì)不能復(fù)用實(shí)時(shí)推送通道。實(shí)戰(zhàn)打法就是我在第3章里說的賽后30分鐘做一次全量對(duì)賬以對(duì)賬結(jié)果為準(zhǔn)。4.3 WebSocket掉線頻繁心跳機(jī)制和重連策略用戶反饋比分不同步刷新頁面又好了這是典型的WebSocket連接不穩(wěn)定。一個(gè)成熟的推送鏈路必須有心跳機(jī)制服務(wù)端和客戶端每隔一定時(shí)間互發(fā)心跳包。如果連續(xù)多次沒收到心跳就判定連接已斷開客戶端主動(dòng)重連。重連策略上還要注意退避算法。我見過最夸張的客戶端斷線后每秒瘋狂重連直接把服務(wù)端打掛。這里要用指數(shù)退避第一次失敗等1秒第二次等2秒第三次等4秒最多不超過30秒并且每次重連前先重置連接避免舊的僵尸連接占資源。4.4 排行榜數(shù)字虛高用戶刷分世界杯競(jìng)猜積分一旦能換獎(jiǎng)品就一定會(huì)有人刷。最常見的刷法是多賬號(hào)注冊(cè)所有賬號(hào)都投同一場(chǎng)高賠率的比賽冷門一中就收益巨大。另一個(gè)刷法是通過邀請(qǐng)返利機(jī)制自己用小號(hào)刷邀請(qǐng)獎(jiǎng)勵(lì)。針對(duì)刷分我的處理辦法是三層防線第一層風(fēng)控API在注冊(cè)和投注環(huán)節(jié)打標(biāo)異常賬號(hào)直接攔截。第二層競(jìng)猜玩法本身做限制。比如設(shè)置單場(chǎng)投注積分上限、單日總投注上限即使對(duì)方有100個(gè)小號(hào)每個(gè)號(hào)能產(chǎn)生的收益也被壓在一個(gè)很小的范圍。第三層積分提現(xiàn)或兌換實(shí)物的時(shí)候引入人工審核環(huán)節(jié)。高危賬號(hào)的兌獎(jiǎng)申請(qǐng)進(jìn)入待審核列表由運(yùn)營人工確認(rèn)。雖然會(huì)多花點(diǎn)時(shí)間但能把絕大部分黑產(chǎn)擋在獎(jiǎng)勵(lì)池之外。4.5 問題排查速查表這里的表格是我實(shí)際項(xiàng)目中最常用的排查手冊(cè)可以作為大家的參考起點(diǎn)異常現(xiàn)象排查第一步常規(guī)解決方案競(jìng)猜提交超時(shí)查看MySQL連接數(shù)、慢查詢異步化外部調(diào)用讀寫連接池拆分比分長時(shí)間不更新檢查數(shù)據(jù)API配額和調(diào)用頻率降級(jí)到備用數(shù)據(jù)源或手動(dòng)維護(hù)消息推送丟失查看MQ消費(fèi)日志與重試次數(shù)增加可靠性投遞與死信隊(duì)列用戶重復(fù)收到積分檢查冪等控制邏輯按業(yè)務(wù)流水號(hào)全局唯一約束排行榜延遲嚴(yán)重檢查Redis淘汰策略與持久化增加緩存時(shí)間歸檔異步落庫Token過期導(dǎo)致掉登錄檢查Refresh Token有效時(shí)長增加無感續(xù)期延長有效期分享回流數(shù)據(jù)缺失檢查短鏈參數(shù)傳遞鏈路增加埋點(diǎn)日志保證入口到落庫全鏈路可追蹤4.6 幾條躲坑的獨(dú)家心得再分享幾條常規(guī)文檔里絕對(duì)不會(huì)寫的心得。第一不要相信“開箱即用”的四個(gè)字。預(yù)制源碼在演示環(huán)境跑得通不代表在真實(shí)網(wǎng)絡(luò)環(huán)境下跑得穩(wěn)。你至少需要做一輪“環(huán)境差異測(cè)試”換一臺(tái)全新的服務(wù)器從零部署看看哪些環(huán)節(jié)會(huì)出問題。提前暴露環(huán)境適配性問題遠(yuǎn)比上線后再處理要好。第二所有外部API必須做超時(shí)控制且超時(shí)時(shí)間不能太長。外部API調(diào)用如果超過3秒還沒返回大概率說明對(duì)方服務(wù)已經(jīng)異常這時(shí)候強(qiáng)等沒有意義。我的習(xí)慣是連接超時(shí)1.5秒讀取超時(shí)3秒超時(shí)就熔斷降級(jí)走本地緩存或者默認(rèn)值。第三日志就是你的另一雙眼睛。世界杯期間排查問題的效率基本上取決于你的日志質(zhì)量。每個(gè)關(guān)鍵操作投注、結(jié)算、積分變動(dòng)、Token刷新都要打一條結(jié)構(gòu)化日志包含時(shí)間戳、用戶標(biāo)識(shí)、請(qǐng)求唯一ID、核心參數(shù)。上線前花半天把日志埋好上線后能節(jié)省至少三個(gè)通宵。第四提前和運(yùn)營約定“功能降級(jí)預(yù)案”。如果系統(tǒng)真的撐不住了哪些功能可以先砍我的排序一般是砍分享海報(bào)、砍實(shí)時(shí)彈幕、砍排行榜的秒級(jí)刷新、保留競(jìng)猜和登錄。因?yàn)楦?jìng)猜是核心交易登錄是平臺(tái)入口這兩塊必須誓死保衛(wèi)。與其到時(shí)候手忙腳亂關(guān)功能不如提前把開關(guān)做進(jìn)代碼里運(yùn)營一鍵切換。5. 總結(jié)與經(jīng)驗(yàn)沉淀做完這個(gè)項(xiàng)目我悟到了什么如果你問我用預(yù)制源碼加專業(yè)API這種方式構(gòu)建世界杯互動(dòng)平臺(tái)最大的價(jià)值是什么我會(huì)說它幫你搶回來了“思考的時(shí)間”。寫業(yè)務(wù)代碼只是一部分工作量真正讓人晚上睡不著覺的是那些你根本預(yù)想不到的邊角問題某個(gè)老舊瀏覽器上的前端兼容問題、數(shù)據(jù)服務(wù)商半夜接口超時(shí)、某個(gè)用戶頭像下載導(dǎo)致存儲(chǔ)帶寬超標(biāo)。預(yù)制源碼保證了你有一個(gè)完整可用的系統(tǒng)基礎(chǔ)專業(yè)API接管了那些必須依賴第三方能力才能做好的事你才能騰出精力真正去應(yīng)對(duì)世界杯期間瞬息萬變的線上環(huán)境。踩過幾次坑之后我現(xiàn)在做任何大促型項(xiàng)目時(shí)都會(huì)堅(jiān)持一個(gè)習(xí)慣在項(xiàng)目啟動(dòng)第一天就把“降級(jí)方案”寫進(jìn)設(shè)計(jì)文檔。不是“如果出問題我們?cè)傧朕k法”而是“這個(gè)環(huán)節(jié)可能出現(xiàn)什么級(jí)別的問題對(duì)應(yīng)什么應(yīng)急動(dòng)作由誰按下那個(gè)按鈕”。這種“一切盡在計(jì)劃中”的踏實(shí)感是從零開發(fā)很難快速獲得的。最后再分享一個(gè)小技巧活動(dòng)正式結(jié)束之后不要急著把所有服務(wù)器釋放至少保留一套完整的環(huán)境運(yùn)行一周用來跑歷史數(shù)據(jù)對(duì)賬、補(bǔ)發(fā)遺漏獎(jiǎng)勵(lì)、以及復(fù)盤日志。世界杯互動(dòng)平臺(tái)的價(jià)值不在于世界杯那一夜而在于這一整套平臺(tái)能力沉淀下來之后下一次歐洲杯、奧運(yùn)會(huì)甚至公司年會(huì)你都能在一個(gè)小時(shí)內(nèi)把它重新“長”出來。