5.1 業(yè)務(wù)場景：如何以最小代價解決短期高頻寫請求

某公司策劃了一場超低價預(yù)約大型線上活動，在某天9:00~9:15期間，用戶可以前往詳情頁半價預(yù)約搶購一款熱門商品。根據(jù)市場部門的策劃方案，這次活動的運營目標(biāo)是幾十萬左右的預(yù)約量。

為避免活動上線后出現(xiàn)問題，比如數(shù)據(jù)庫被壓垮、后臺服務(wù)器支撐不?。ㄟ@個倒是小問題，加幾臺服務(wù)器即可）等，項目組必須提前做好預(yù)案。這場活動中，領(lǐng)導(dǎo)要求在架構(gòu)上不要做太大調(diào)整，畢竟是一個臨時的活動。簡單地說就是工期不能太長，修改影響范圍不要太大。

項目組分析了一下可能的情況，其他都沒問題，唯一沒把握的就是數(shù)據(jù)庫。

項目組通過如下邏輯做了一次簡單的測算。

假設(shè)目標(biāo)是15分鐘完成100萬的預(yù)約數(shù)據(jù)插入，并且不是在15分鐘內(nèi)平均插入的。按照以往的經(jīng)驗，有可能在1分鐘內(nèi)就完成90%的預(yù)約，也有可能在5分鐘內(nèi)完成80%的預(yù)約，這些難以預(yù)計。但是峰值流量預(yù)估值只能取高，不能取低。所以設(shè)計的目標(biāo)是：用戶1分鐘內(nèi)就完成90%的預(yù)約量，即90萬預(yù)約。那么推算出目標(biāo)的TPS（吞吐量）就是9萬/60=1.5萬。

原來預(yù)約就是個簡單的功能，并沒有做高并發(fā)設(shè)計。對它做了一次壓力測試，結(jié)果最大的TPS是2200左右，與需求值差距較大。

項目組想過分表分庫這個方案，不過代碼改動的代價太大了，性價比不高。畢竟這次僅僅是臨時性市場活動，而且活動運營目標(biāo)是幾十萬的預(yù)約量，這點數(shù)據(jù)量采取分表分庫的話，未免有些得不償失。

項目最終采用的方案是不讓預(yù)約的請求直接插入數(shù)據(jù)庫，而是先存放到性能很高的緩沖地帶，以此保證洪峰期間先沖擊緩沖地帶，之后再從緩沖地帶異步、勻速地遷移數(shù)據(jù)到數(shù)據(jù)庫中。

其實這個解決方案就是寫緩存，這也是接下來要重點講解的內(nèi)容。