程序員架構——用Redis輕松實現秒殺系統

導論

曾經被問過好多次怎樣實現秒殺系統的問題。因此這里把我設想的實現秒殺系統的價格設計分享出來。供大家參考。

秒殺系統的架構設計

秒殺系統，是典型的短時大量突發訪問類問題。對這類問題，有三種優化性能的思路：?

• 寫入內存而不是寫入硬盤?

• 異步處理而不是同步處理?

• 分布式處理?

用上這三招，不論秒殺時負載多大，都能輕松應對。更好的是，Redis能夠滿足上述三點。因此，用Redis就能輕松實現秒殺系統。?

用我這個方案，無論是電商平臺特價秒殺，12306火車票秒殺，都不是事:)

下面介紹一下為什么上述三種性能優化思路能夠解決秒殺系統的性能問題：

1. 寫入內存而不是寫入硬盤?

   傳統硬盤的讀寫性能是相當差的。SSD硬盤比傳統硬盤快100倍。而內存又比SSD硬盤快10倍以上。因此，寫入內存而不是寫入硬盤，就能使系統的能力提升上千倍。也就是說，原來你的秒殺系統可能需要1000臺服務器支撐，現在1臺服務器就可以扛住了。?

   你可能會有這樣的疑問：寫入內存而不是持久化，那么如果此時計算機宕機了，那么寫入的數據不就全部丟失了嗎？如果你就這么倒霉碰到服務器宕機，那你就沒秒到了，有什么大不了？?

   最后，后面真正處理秒殺訂單時，我們會把信息持久化到硬盤中。因此不會丟失關鍵數據。?

   Redis是一個緩存系統，數據寫入內存后就返回給客戶端了，能夠支持這個特性。

   
   

2. 異步處理而不是同步處理?

   像秒殺這樣短時大并發的系統，在性能負載上有一個明顯的波峰和長期的波谷。為了應對相當短時間的大并發而準備大量服務器來應對，在經濟上是相當不合算的。?

   因此，對付秒殺類需求，就應該化同步為異步。用戶請求寫入內存后立刻返回。后臺啟動多個線程從內存池中異步讀取數據，進行處理。如用戶請求可能是1秒鐘內進入的，系統實際處理完成可能花30分鐘。那么一臺服務器在異步情況下其處理能力大于同步情況下1800多倍！?

   異步處理，通常用MQ(消息隊列)來實現。Redis可以看作是一個高性能的MQ。因為它的數據讀寫都發生在內存中。

   
   

3. 分布式處理?

   好吧。也許你的客戶很多，秒殺系統即使用了上面兩招，還是捉襟見肘。沒關系，我們還有大招：分布式處理。如果一臺服務器撐不住秒殺系統，那么就多用幾臺服務器。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！?

這里介紹的方案雖然是針對秒殺系統的，但其背后的原理對其他高并發系統一樣有效。?

最后，我們再重溫一下高性能系統的優化原則：?

寫入內存而不是寫入硬盤?

異步處理而不是同步處理?

分布式處理

順便給大家推薦一個Java技術交流群：908676731，里面會分享一些資深架構師錄制的視頻資料：有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多！