每當電子商務平臺搞活動，“秒殺”經常是提升網站活躍度的利器之一。比如活動日早上10點1元愛瘋7秒殺7臺，誰看到了估計都想去秒一把，萬一秒中了呢。秒殺的典型特征就是在特定的短時間突然涌入大量請求，對系統造成洪峰沖擊，如果系統設計得不好，很容易被直接打垮掉。

　　秒殺架構

　　按照“關注點分離”(SoC)的原則，秒殺業務跟普通的訂單業務關注點顯然是不一樣的，秒殺強調的是高效率、高性能，普通訂單強調的是業務流程的高一致性。所以我們首先應該將秒殺處理邏輯從普通的訂單邏輯中分離出來，進行獨立開發與部署。這樣分離的好處就是非常靈活，可以在秒殺設計中采用完全不同的技術和架構，在秒殺活動結束后也方便下架部署。

　　既然按照分離的思路，我們就不需要再局限于傳統的RMDBS和JavaEE了，因為二者本質上都是企業架構，單機每秒并發處理能力的量級也是在1000左右，如果加上復雜的業務邏輯的話，經常會下降到500以下了。我們將眼光放到Nginx和Redis上，二者的單機處理能力，最高都能達到每秒萬級乃至10萬級，輕松完爆RMDBS和JavaEE的處理能力。所以，我們希望在Nginx和Redis上做做文章，完全通過這兩把利器來完成秒殺的用戶行為部分。

　　如果我們只用Nginx和Redis來完成秒殺下單任務的話，加上秒殺本身具體的業務邏輯，那么即使達不到每秒10萬并發，單機每秒達到1萬應該也是可以達到的目標了。

　　針對秒殺方案的設計，我們最大化地簡化業務流程，只需要用戶在秒到之后提供一個手機號碼即可成功完成秒殺。我們在Redis中來記錄庫存，通過減1操作來扣減庫存。當庫存減到0時，結束秒殺。秒殺成功后，在Redis中使用隊列來記錄用戶的手機號碼和相關秒殺信息，結束用戶的秒殺動作，后續交由后端秒殺訂單處理模塊，按照其固定的處理效率，逐步消化處理之。編程語言直接使用Nginx(項目中實際使用的是OpenResty)中提供的LUA腳本來實現，我們用LUA來讀寫Redis，并且進行業務邏輯的操作。這樣秒殺活動的實現，完全不需要經過WEB服務器、APP服務器和DB服務器，直接在高效率的Nginx和Redis中完成了。在實際的運用中，處理效率也基本達到了每秒萬級的并發請求。

　　三、總結思考

　　看似使用雙雄利器Nginx+Redis能實現單機每秒萬級的秒殺了，你可能會有很多疑問，比如Redis還沒有來得及寫入持久化就宕機了怎么辦?Redis中扣減庫存，如果扣減成功但是后續卻失敗了，浪費庫存了怎么辦?還有用戶手機號碼填錯了怎么辦?這些問題，確實需要思考，但仔細想一下，其實不需要緊張。用阿里巴巴高級專家沈詢的話說：世界上解決一個計算機問題最簡單的方法，“恰好”不需要解決它!

　　秒殺正熱火的時候，偏偏Redis某個節點宕機了，那就算倒霉了，有什么大不了。Redis扣減庫存浪費了1個，又不是超賣，有什么大不了。用戶手機號碼填錯了，不管了吧。

　　雖然說恰好不需要解決它，但是在技術上，我們在Redis部署上，考慮使用集群，使用SSD可以加速Redis內存的持久化等。在業務上，浪費掉的秒殺庫存，可以在下一次秒殺中加上。用戶手機號碼填錯了，可以在業務上要求秒殺之前先校驗手機號碼或者先登錄等等。

　　當然，不同的秒殺業務，差距也相當大，但是很多思想是一致的，比如簡化業務流程，異步化訂單處理，與常規業務進行分離部署，使用獨立的更加適合秒殺場景的特定技術等等。