今年這波新型冠狀肺炎，對很多公司的后臺系統是一個大考，有一朋友，之前主要做醫療藥物的云商城，這次服務也被壓垮了好幾次，幾乎每次口罩、消毒水等物品上架，就被秒殺一空。今天，我們來簡單地討論討論，一個秒殺系統要怎么做。

首先我們應該了解一下一個口罩秒殺系統是怎么運作的。首先是我們在前端頁面上看到口罩的商品詳情頁，然后這個時候可能有一個計時器，顯示著還未到秒殺時間，然后開始倒數計時。當到達秒殺時間的時候，就有非常多的人開始點擊購買，這些點擊會變成無數的請求，穿過復雜的網絡環境，到了系統的后臺，一般會先到接入服務器，接入服務器校驗完地址后，知道上秒殺的請求，轉發給對應的CGI,在CGI層會進行一些簡單的檢驗，例如是否是登陸用戶，秒殺的數量填寫對不對，然后將請求轉發給庫存系統，進行庫存預扣，庫存系統會將數據寫到數據庫里面，然后告訴用戶，秒殺成功。

對于一般的業務，我們通常使用的是直筒型的架構設計，也就是有100個人在前端發起搶口罩，就有100個人請求到后臺，100個請求到數據庫。但是對于這種秒殺這么巨量的業務，海量的查詢往往可以讓數據庫奔潰，所以，我們一般使用漏斗型的架構設計。什么是漏斗型的架構設計呢?就有100萬人同時發起搶口罩的請求，可能只有10萬人請求到邏輯層，邏輯層再過濾掉一部分人，服務層再過濾掉一部分人，最后只有1萬個請求到達數據庫，他們都是幸運兒，最終搶到了口罩。

那么怎么去實現這樣的功能呢?通常我們會在客戶端上面就加上保護，首先是防止用戶多次點擊，如果用戶拼命地點擊購買按鈕，那么對后臺的壓力是非常巨大的，所以，我們通常會在用戶多次點擊的時候，實際只往后臺發送一次請求。接下來，我們可以按照一定的百分比，讓客戶端直接返回失敗，或者提醒用戶在排隊中。低級一點的做法，就是在客戶庫或者頁面生成一個隨機數，例如這次口罩的備貨只有預約人的千分之一，那么我們可以生成一個小于1000的數，如果生成的數小于5，那么就向后臺發起請求，否則直接失敗。高級一點的做法，是在cnd這樣的邊緣節點上部署一些簡單的隨機數服務，讓一定概率的請求到真正的服務后臺。這樣，1000個人搶口罩，實際上就只有5個人真正到后臺去搶購了。

基于大量的秒殺系統都是這么實現的，所以有很多人有遮掩的感覺，明明我已經秒提交了，為什么沒能搶購到口罩呢?這下大家應該都明白了吧。歡迎大家關注我，共同學習，共同進步。大家的支持是我繼續嘮嗑的動力。