導論
曾經被問過好多次怎樣實現秒殺系統的問題。昨天又在CSDN架構師微信群被問到了。因此這裡把我設想的實現秒殺系統的價格設計分享出來。供大家參考。
秒殺系統的架構設計
秒殺系統，是典型的短時大量突發訪問類問題。對這類問題，有三種優化效能的思路：
下面介紹一下為什麼上述三種效能優化思路能夠解決秒殺系統的效能問題：
寫入記憶體而不是寫入硬碟 傳統硬碟的讀寫效能是相當差的。SSD硬碟比傳統硬碟快100倍。而記憶體又比SSD硬碟快10倍以上。因此，寫入記憶體而不是寫入硬碟，就能使系統的能力提升上千倍。也就是說，原來你的秒殺系統可能需要1000臺伺服器支撐，現在1臺伺服器就可以扛住了。 你可能會有這樣的疑問：寫入記憶體而不是持久化，那麼如果此時計算機當機了，那麼寫入的資料不就全部丟失了嗎？如果你就這麼倒黴碰到伺服器當機，那你就沒秒到了，有什麼大不了？ 最後，後面真正處理秒殺訂單時，我們會把資訊持久化到硬碟中。因此不會丟失關鍵資料。 Redis是一個快取系統，資料寫入記憶體後就返回給客戶端了，能夠支援這個特性。
非同步處理而不是同步處理 像秒殺這樣短時大併發的系統，在效能負載上有一個明顯的波峰和長期的波谷。為了應對相當短時間的大併發而準備大量伺服器來應對，在經濟上是相當不合算的。 因此，對付秒殺類需求，就應該化同步為非同步。使用者請求寫入記憶體後立刻返回。後臺啟動多個執行緒從記憶體池中非同步讀取資料，進行處理。如使用者請求可能是1秒鐘內進入的，系統實際處理完成可能花30分鐘。那麼一臺伺服器在非同步情況下其處理能力大於同步情況下1800多倍！ 非同步處理，通常用MQ(訊息佇列)來實現。Redis可以看作是一個高效能的MQ。因為它的資料讀寫都發生在記憶體中。
分散式處理 好吧。也許你的客戶很多，秒殺系統即使用了上面兩招，還是捉襟見肘。沒關係，我們還有大招：分散式處理。如果一臺伺服器撐不住秒殺系統，那麼就多用幾臺伺服器。10臺不行，就上100臺。分散式處理，就是把海量使用者的請求分散到多個伺服器上。一般使用hash實現均勻分佈。 這類系統在大資料雲端計算時代的今天已經有很多了。無非是用Paxos演算法和Hash Ring實現的。 Redis Cluster正是這樣一個分散式的產品。
使用Redis實現描述系統
Redis和Redis Cluster（分散式版本），是一個分散式快取系統。其支援多種資料結構，也支援MQ。Redis在效能上做了大量優化。因此使用Redis或者Redis Cluster就可以輕鬆實現一個強大的秒殺系統。 基本上，你用Redis的這些命令就可以了。 RPUSH key value 插入秒殺請求
當插入的秒殺請求數達到上限時，停止所有後續插入。 後臺啟動多個工作執行緒，使用 LPOP key 讀取秒殺成功者的使用者id，進行後續處理。 或者使用LRANGE key start end命令讀取秒殺成功者的使用者id，進行後續處理。 每完成一條秒殺記錄的處理，就執行INCR key_num。一旦所有庫存處理完畢，就結束該商品的本次秒殺，關閉工作執行緒，也不再接收秒殺請求。
要是還撐不住，該怎麼辦
也許你會說，我們的客戶很多。即使部署了Redis Cluster，仍然撐不住。那該怎麼辦呢？ 記得某個偉人曾經說過：辦法總比困難多！
下面，我們具體分析下，還有哪些情況會壓垮我們架構在Redis（Cluster）上的秒殺系統。
指令碼攻擊
如現在有很多搶火車票的軟體。它們會自動發起http請求。一個客戶端一秒會發起很多次請求。如果有很多使用者使用了這樣的軟體，就可能會直接把我們的交換機給壓垮了。
這個問題其實屬於網路問題的範疇，和我們的秒殺系統不在一個層面上。因此不應該由我們來解決。很多交換機都有防止一個源IP發起過多請求的功能。開源軟體也有不少能實現這點。如linux上的TC可以控制。流行的Web伺服器Nginx（它也可以看做是一個七層軟交換機）也可以通過配置做到這一點。一個IP，一秒鐘我就允許你訪問我2次，其他軟體包直接給你丟了，你還能壓垮我嗎？
交換機撐不住了
可能你們的客戶併發訪問量實在太大了，交換機都撐不住了。 這也有辦法。我們可以用多個交換機為我們的秒殺系統服務。 原理就是DNS可以對一個域名返回多個IP，並且對不同的源IP，同一個域名返回不同的IP。如網通使用者訪問，就返回一個網通機房的IP；電信使用者訪問，就返回一個電信機房的IP。也就是用CDN了！ 我們可以部署多臺交換機為不同的使用者服務。 使用者通過這些交換機訪問後面資料中心的Redis Cluster進行秒殺作業。
總結
有了Redis Cluster的幫助，做個支援海量使用者的秒殺系統其實So Easy！ 這裡介紹的方案雖然是針對秒殺系統的，但其背後的原理對其他高併發系統一樣有效。 最後，我們再重溫一下高效能系統的優化原則：