Day 20|開賣瞬間(上):尖峰的形狀,與兩種命運

交易和營運的故事都寫完了,接下來幾章講的是貫穿全系統的事:尖峰、維運、對帳。先從所有直播電商的原點講起——主播喊完 key 的那三秒。今天先講真實的數字和兩種命運;最痛的一次事故,和一條從被打爆一路通往「雲端菩薩」的戰記,留到明天。

尖峰的形狀:一堵牆,和一連串浪

先給數字。一場大直播,最高 13,000 人在線,一般尖峰也有 9,000。主播介紹商品時,留言平均每秒 10–20 則;喊出 key、起標的瞬間——每秒 200 則。

兩個形狀上的重點:它是階躍,不是爬升——主播一句話,流量一秒內跳 10–20 倍,任何 autoscaling 都反應不過來,容量只能按峰值準備、削峰只能靠結構;它是脈衝串,不是單峰——結標平均三分鐘,長結標裡主播不定時放優惠、流量一波波再起。自適應抓取(爆量就帶著 paging key 加速、空閒就放慢)當年看是直覺,對著這個形狀看是精準:固定速率的輪詢對脈衝負載兩頭吃虧。

還有一件事值得先講,因為它是整章的地基:13,000 人在線,寫入洪峰卻只有 200 則/秒——尖峰時大家都在留言區,網站的寫入反而不多。 如果這是傳統電商的搶購,13,000 人就是 13,000 個併發結帳請求直接砸在你的 API 上;「用留言買東西」把一萬三千人的購買意圖壓進一條線性的文字通道,FB 的聊天室基礎設施免費幫你扛了 fan-in,你的系統只需要消化一條 200/s 的串流。這個商業模式自帶削峰——看似原始的互動方式,恰好是天才的流量設計,只是當年沒有人這樣想過它。

兩種命運:批次淤而不倒,同步一觸即炸

有了流量的形狀,就能講這章的主題句:尖峰之下,這個系統的元件分成兩種命運。

批次那一欄,是 batch 在這個系統的第三次救場:留言下單靠 FSM batch(起標時積壓幾分鐘,但不崩)、得標通知靠 FB batch API、連主播 dashboard 的留言瀑布都打 batch 推送——200 則/秒照樣扛住。批次系統過載的表現是淤:隊伍變長、延遲變大,但它不會倒;它用延遲付帳,不用可用性付帳。

這也解釋了一件事後看很有趣的事:這個系統沒有任何降級功能——不是疏忽,當年的說法是「都還沒遇到什麼事故,要做什麼降級」。這句話對了一半;另一半更深:降級開關是同步系統的必需品,因為同步系統的過載是雪崩;批次系統的降級是內建的,它天生淤而不倒。唯一真正炸過的,全部在同步那一欄——這就要講戰記了。

反思

過載一定要付帳,架構師決定用什麼貨幣

尖峰之下沒有免費的午餐:負載超過容量,系統一定在某個維度付出代價——批次系統用延遲付,同步系統用可用性付。這章兩條故事線的全部差異就在貨幣:留言積壓幾分鐘,客訴幾句,系統活著;fat API 一觸即炸,整站陪葬(明天的戰記)。所以「能批次的都批次化」不是效能優化,是選擇破產方式——延遲的帳可以分期(慢慢消化積壓),可用性的帳是即期全額。設計系統時問自己:每一條路徑過載時,我是在用哪種貨幣付帳?付不起的那種,就把它改成付得起的那種。

尖峰是商業模式的形狀,不是流量的形狀

200 則/秒的牆、放優惠的脈衝串、主副台的疊加——這些不是「流量特性」,是生意的節奏直接投影在系統上:主播喊 key 是牆的成因、放優惠是浪的成因、留言下單是削峰的成因。做容量規劃之前先看懂生意怎麼運作,比任何壓測都準——而反過來,雪崩式故障的第一課也是:系統的失效模式,同樣是被業務的形狀決定的。當年那個「商業模式自帶削峰」的紅利,我們享受了很久才意識到它的存在——最好的架構決策,有時候是業務替你做的。

唯一真正炸過的,全部在同步那一欄。明天講兩場真實的仗:毒藥訊息,和 DDoS 戰記。

本文改寫自我的部落格系列《Re:從零開始做直播代購電商平台》,本篇完整版:https://blog.aidan.tw/blog/rezero-flash-crowd/