正常電子商務流程（1）查詢商品；（2）建立訂單；（3）扣減庫存；（4）更新訂單；（5）付款；（6）賣家發貨
秒殺業務的特性（1）低廉價格；（2）大幅推廣；（3）瞬時售空；（4）一般是定時上架；（5）時間短、瞬時併發量高；

2 秒殺技術挑戰

假設某網站秒殺活動只推出一件商品，預計會吸引1萬人參加活動，也就說最大併發請求數是10000，秒殺系統需要面對的技術挑戰有：

對現有網站業務造成衝擊秒殺活動只是網站營銷的一個附加活動，這個活動具有時間短，併發訪問量大的特點，如果和網站原有應用部署在一起，必然會對現有業務造成衝擊，稍有不慎可能導致整個網站癱瘓。解決方案：將秒殺系統獨立部署，甚至使用獨立域名，使其與網站完全隔離

。
高併發下的應用、資料庫負載使用者在秒殺開始前，通過不停重新整理瀏覽器頁面以保證不會錯過秒殺，這些請求如果按照一般的網站應用架構，訪問應用伺服器、連線資料庫，會對應用伺服器和資料庫伺服器造成負載壓力。解決方案：重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，頁面內容靜態化，使用者請求不需要經過應用服務。
突然增加的網路及伺服器頻寬假設商品頁面大小200K（主要是商品圖片大小），那麼需要的網路和伺服器頻寬是2G（200K×10000），這些網路頻寬是因為秒殺活動新增的，超過網站平時使用的頻寬。解決方案：因為秒殺新增的網路頻寬，必須和運營商重新購買或者租借。為了減輕網站伺服器的壓力，需要將秒殺商品頁面快取在CDN，同樣需要和CDN服務商臨時租借新增的出口頻寬

。
直接下單秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點之前，只能瀏覽商品資訊，不能下單。而下單頁面也是一個普通的URL，如果得到這個URL，不用等到秒殺開始就可以下單了。解決方案：為了避免使用者直接訪問下單頁面URL，需要將改URL動態化，即使秒殺系統的開發者也無法在秒殺開始前訪問下單頁面的URL。辦法是在下單頁面URL加入由伺服器端生成的隨機數作為引數，在秒殺開始的時候才能得到。
如何控制秒殺商品頁面購買按鈕的點亮購買按鈕只有在秒殺開始的時候才能點亮，在此之前是灰色的。如果該頁面是動態生成的，當然可以在伺服器端構造響應頁面輸出，控制該按鈕是灰色還是點亮，但是為了減輕伺服器端負載壓力，更好地利用CDN、反向代理等效能優化手段，該頁面被設計為靜態頁面，快取在CDN、反向代理伺服器上，甚至使用者瀏覽器上。秒殺開始時，使用者重新整理頁面，請求根本不會到達應用伺服器。解決方案

：使用JavaScript指令碼控制，在秒殺商品靜態頁面中加入一個JavaScript檔案引用，該JavaScript檔案中包含秒殺開始標誌為否；當秒殺開始的時候生成一個新的JavaScript檔案（檔名保持不變，只是內容不一樣），更新秒殺開始標誌為是，加入下單頁面的URL及隨機數引數（這個隨機數只會產生一個，即所有人看到的URL都是同一個，伺服器端可以用redis這種分散式快取伺服器來儲存隨機數），並被使用者瀏覽器載入，控制秒殺商品頁面的展示。這個JavaScript檔案的載入可以加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理伺服器快取。這個JavaScript檔案非常小，即使每次瀏覽器重新整理都訪問JavaScript檔案伺服器也不會對伺服器叢集和網路頻寬造成太大壓力。
如何只允許第一個提交的訂單被髮送到訂單子系統由於最終能夠成功秒殺到商品的使用者只有一個，因此需要在使用者提交訂單時，檢查是否已經有訂單提交。如果已經有訂單提交成功，則需要更新 JavaScript檔案，更新秒殺開始標誌為否，購買按鈕變灰。事實上，由於最終能夠成功提交訂單的使用者只有一個，為了減輕下單頁面伺服器的負載壓力，可以控制進入下單頁面的入口，只有少數使用者能進入下單頁面，其他使用者直接進入秒殺結束頁面。解決方案：假設下單伺服器叢集有10臺伺服器，每臺伺服器只接受最多10個下單請求。在還沒有人提交訂單成功之前，如果一臺伺服器已經有十單了，而有的一單都沒處理，可能出現的使用者體驗不佳的場景是使用者第一次點選購買按鈕進入已結束頁面，再重新整理一下頁面，有可能被一單都沒有處理的伺服器處理，進入了填寫訂單的頁面，可以考慮通過cookie的方式來應對，符合一致性原則。當然可以採用最少連線的負載均衡演算法，出現上述情況的概率大大降低。
如何進行下單前置檢查
- 下單伺服器檢查本機已處理的下單請求數目：
如果超過10條，直接返回已結束頁面給使用者；

如果未超過10條，則使用者可進入填寫訂單及確認頁面；
- 檢查全域性已提交訂單數目：
已超過秒殺商品總數，返回已結束頁面給使用者；

未超過秒殺商品總數，提交到子訂單系統；
秒殺一般是定時上架該功能實現方式很多。不過目前比較好的方式是：提前設定好商品的上架時間，使用者可以在前臺看到該商品，但是無法點選“立即購買”的按鈕。但是需要考慮的是，有人可以繞過前端的限制，直接通過URL的方式發起購買，這就需要在前臺商品頁面，以及bug頁面到後端的資料庫，都要進行時鐘同步。越在後端控制，安全性越高。定時秒殺的話，就要避免賣家在秒殺前對商品做編輯帶來的不可預期的影響。這種特殊的變更需要多方面評估。一般禁止編輯，如需變更，可以走資料訂正多的流程。
減庫存的操作有兩種選擇，一種是拍下減庫存 另外一種是付款減庫存；目前採用的“拍下減庫存”的方式，拍下就是一瞬間的事，對使用者體驗會好些。
庫存會帶來“超賣”的問題：售出數量多於庫存數量由於庫存併發更新的問題，導致在實際庫存已經不足的情況下，庫存依然在減，導致賣家的商品賣得件數超過秒殺的預期。方案：採用樂觀鎖

1 2 3 update auction_auctions set quantity = #inQuantity# where auction_id = #itemId# and quantity = #dbQuantity#
秒殺器的應對秒殺器一般下單個購買及其迅速，根據購買記錄可以甄別出一部分。可以通過校驗碼達到一定的方法，這就要求校驗碼足夠安全，不被破解，採用的方式有：秒殺專用驗證碼，電視公佈驗證碼，秒殺答題。

3 秒殺架構原則

儘量將請求攔截在系統上游傳統秒殺系統之所以掛，請求都壓倒了後端資料層，資料讀寫鎖衝突嚴重，併發高響應慢，幾乎所有請求都超時，流量雖大，下單成功的有效流量甚小【一趟火車其實只有2000張票，200w個人來買，基本沒有人能買成功，請求有效率為0】。
讀多寫少的常用多使用快取這是一個典型的讀多寫少的應用場景【一趟火車其實只有2000張票，200w個人來買，最多2000個人下單成功，其他人都是查詢庫存，寫比例只有0.1%，讀比例佔99.9%】，非常適合使用快取。

4 秒殺架構設計

秒殺系統為秒殺而設計，不同於一般的網購行為，參與秒殺活動的使用者更關心的是如何能快速重新整理商品頁面，在秒殺開始的時候搶先進入下單頁面，而不是商品詳情等使用者體驗細節，因此秒殺系統的頁面設計應儘可能簡單。

商品頁面中的購買按鈕只有在秒殺活動開始的時候才變亮，在此之前及秒殺商品賣出後，該按鈕都是灰色的，不可以點選。

下單表單也儘可能簡單，購買數量只能是一個且不可以修改，送貨地址和付款方式都使用使用者預設設定，沒有預設也可以不填，允許等訂單提交後修改；只有第一個提交的訂單傳送給網站的訂單子系統，其餘使用者提交訂單後只能看到秒殺結束頁面。

要做一個這樣的秒殺系統，業務會分為兩個階段，第一個階段是秒殺開始前某個時間到秒殺開始，這個階段可以稱之為準備階段，使用者在準備階段等待秒殺； 第二個階段就是秒殺開始到所有參與秒殺的使用者獲得秒殺結果，這個就稱為秒殺階段吧。

4.1 前端層設計

首先要有一個展示秒殺商品的頁面，在這個頁面上做一個秒殺活動開始的倒計時， 在準備階段內使用者會陸續開啟這個秒殺的頁面，並且可能不停的重新整理頁面。這裡需要考慮兩個問題：

第一個是秒殺頁面的展示我們知道一個html頁面還是比較大的，即使做了壓縮，http頭和內容的大小也可能高達數十K，加上其他的css， js，圖片等資源，如果同時有幾千萬人蔘與一個商品的搶購，一般機房頻寬也就只有1G~10G，網路頻寬就極有可能成為瓶頸，所以這個頁面上各類靜態資源首先應分開存放，然後放到cdn節點上分散壓力，由於CDN節點遍佈全國各地，能緩衝掉絕大部分的壓力，而且還比機房頻寬便宜~
第二個是倒計時出於效能原因這個一般由js呼叫客戶端本地時間，就有可能出現客戶端時鐘與伺服器時鐘不一致，另外伺服器之間也是有可能出現時鐘不一致。客戶端與伺服器時鐘不一致可以採用客戶端定時和伺服器同步時間，這裡考慮一下效能問題，用於同步時間的介面由於不涉及到後端邏輯，只需要將當前web伺服器的時間傳送給客戶端就可以了，因此速度很快，就我以前測試的結果來看，一臺標準的web伺服器2W+QPS不會有問題，如果100W人同時刷，100W QPS也只需要50臺web，一臺硬體LB就可以了~，並且web伺服器群是可以很容易的橫向擴充套件的(LB+DNS輪詢)，這個介面可以只返回一小段json格式的資料，而且可以優化一下減少不必要cookie和其他http頭的資訊，所以資料量不會很大，一般來說網路不會成為瓶頸，即使成為瓶頸也可以考慮多機房專線連通，加智慧DNS的解決方案；web伺服器之間時間不同步可以採用統一時間伺服器的方式，比如每隔1分鐘所有參與秒殺活動的web伺服器就與時間伺服器做一次時間同步。
瀏覽器層請求攔截（1）產品層面，使用者點選“查詢”或者“購票”後，按鈕置灰，禁止使用者重複提交請求;（2）JS層面，限制使用者在x秒之內只能提交一次請求;

4.2 站點層設計

前端層的請求攔截，只能攔住小白使用者（不過這是99%的使用者喲），高階的程式設計師根本不吃這一套，寫個for迴圈，直接呼叫你後端的http請求，怎麼整？

（1）同一個uid，限制訪問頻度，做頁面快取，x秒內到達站點層的請求，均返回同一頁面

（2）同一個item的查詢，例如手機車次，做頁面快取，x秒內到達站點層的請求，均返回同一頁面

如此限流，又有99%的流量會被攔截在站點層。

4.3 服務層設計

站點層的請求攔截，只能攔住普通程式設計師，高階黑客，假設他控制了10w臺肉雞（並且假設買票不需要實名認證），這下uid的限制不行了吧？怎麼整？

（1）大哥，我是服務層，我清楚的知道小米只有1萬部手機，我清楚的知道一列火車只有2000張車票，我透10w個請求去資料庫有什麼意義呢？對於寫請求，做請求佇列，每次只透過有限的寫請求去資料層，如果均成功再放下一批，如果庫存不夠則佇列裡的寫請求全部返回“已售完”；

（2）對於讀請求，還用說麼？cache來抗，不管是memcached還是Redis，單機抗個每秒10w應該都是沒什麼問題的；

如此限流，只有非常少的寫請求，和非常少的讀快取mis的請求會透到資料層去，又有99.9%的請求被攔住了。

使用者請求分發模組：使用Nginx或Apache將使用者的請求分發到不同的機器上。
使用者請求預處理模組：判斷商品是不是還有剩餘來決定是不是要處理該請求。
使用者請求處理模組：把通過預處理的請求封裝成事務提交給資料庫，並返回是否成功。
資料庫介面模組：該模組是資料庫的唯一介面，負責與資料庫互動，提供RPC介面供查詢是否秒殺結束、剩餘數量等資訊。

使用者請求預處理模組經過HTTP伺服器的分發後，單個伺服器的負載相對低了一些，但總量依然可能很大，如果後臺商品已經被秒殺完畢，那麼直接給後來的請求返回秒殺失敗即可，不必再進一步傳送事務了，示例程式碼可以如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 packageseckill; import