凡是做過電商的同學，都會遇到運營展開的秒殺，限時購等“高并發(fā)”的活動。
秒殺從規(guī)模上來說可以分為大秒和小秒。大秒指的是比如雙11這種特定的節(jié)日，商品規(guī)模超大、價格超低、流量超大的這種類型活動，小秒一般指的是商家自己配置的一些時段類型的活動，由商家自己指定時間上架。從形式來說還可以分為單時段秒殺和多時段秒殺。但是在這個場景里，我們一般就是指的單時段大型秒殺。
秒殺這種業(yè)務場景其實特點很明顯：
1、帶有短期流量峰值特性，即：短時間內(nèi)會有大量的請求涌入；
2、請求的數(shù)據(jù)帶有熱點性，即：大量的請求同一數(shù)據(jù)；
3、請求的成功有效率低，即：大量的請求中可能只有少量請求會成功處理業(yè)務；
4、請求的流量峰值發(fā)生在下單之前，即：付款階段很少存在流量峰值。
一、秒殺的技術挑戰(zhàn)
1、對現(xiàn)有網(wǎng)站業(yè)務造成沖擊：秒殺活動只是網(wǎng)站營銷的一個附加活動，這個活動具有時間短，并發(fā)訪問量大的特點，如果和網(wǎng)站原有應用部署在一起，必然會對現(xiàn)有業(yè)務造成沖擊，稍有不慎可能導致整個網(wǎng)站癱瘓；
2、高并發(fā)下的應用、數(shù)據(jù)庫負載：用戶在秒殺活動開始之前，通過不停的刷新瀏覽器頁面以保證不錯過秒殺，這些請求如果按照一般網(wǎng)站的應用架構，訪問應用服務器，連接數(shù)據(jù)庫，會對應用服務器和數(shù)據(jù)庫服務器造成極大的負載壓力；
3、突然增加的網(wǎng)絡及服務器帶寬：因為訪問秒殺頁面的用戶劇增，對資源的請求量也是劇增，網(wǎng)絡帶寬也上去了，超過平時網(wǎng)站使用的帶寬；
4、直接下單：秒殺的規(guī)則是到了秒殺秒殺時間才能開始對商品下單購買，在此時間點之前，只能瀏覽商品信息，不能下單。而下單頁面也是一個普通的URL，如果得到了這個URL，不用等到秒殺開始就可以下單了。
二、秒殺系統(tǒng)的應對策略
1、技術第一招：限流
對于秒殺出現(xiàn)的流量峰值，限流是最直接的削峰手段，被限制的請求可以直接返回，客戶端提示請求中提示?？上攵?0000/S的請求量被削成100/S的量，估計系統(tǒng)稍微優(yōu)化一下就能抗住。
2、第二招：消息隊列
說到消息隊列，每個程序員都不陌生，它相當于一個快速的數(shù)據(jù)容器，可以作為一個緩沖層來應對流量高峰。如果從它的使用場景上來看，它可以算是低速設備和高速設備之間的平衡者，使用消息隊列來進行削峰是一個很明顯的異步流程。應用到秒殺的場景下，大量的請求會先進入消息隊列，它不僅削平了流量的峰值，而且把秒殺下單的這個流程異步化，只要把請求都暫存入隊列，消費端慢慢消費即可，但是這里要注意，如果消費的速度遠遠慢于消息的投遞速度，可能會影響整個系統(tǒng)性能。
除了削峰之外，我始終認為消息隊列的最大作用是系統(tǒng)解耦，它把下單和支付解耦，下單和支付業(yè)務可以隨著自身系統(tǒng)的承載量來單獨擴容。
3、第三招：緩存
為什么要加入緩存這個選項呢？別忘了，除了大量的用戶下單這個寫操作之外，還有更大量的用戶請求下單結果這個讀操作。當用戶點擊秒殺按鈕之后，系統(tǒng)會彈出等待的提示框，很多系統(tǒng)是不停的去輪訓用戶的下單結果，我之前也寫過緩存的文章，曾經(jīng)提到過緩存最大的作用是提供讀操作的快速響應。其實很多系統(tǒng)應用上消息隊列+限流之后，針對秒殺業(yè)務已經(jīng)足夠了，其余的分庫分表等方案可以根據(jù)自己的業(yè)務量來確定。每個系統(tǒng)在滿足功能性的需求下，也在滿足非功能性需求的前提下越簡單越好，不是每個系統(tǒng)都需要淘寶的架構。
新網(wǎng)消息隊列RabbitMQ是一款支持持久化消息隊列的消息中間件。通過創(chuàng)建集群的方式來實現(xiàn)RabbitMQ以及所依賴的服務的部署，完全兼容RabbitMQ開源生態(tài)以及多語言客戶端，為用戶提供快速創(chuàng)建、方便管理的消息中間件。
新網(wǎng)消息隊列RabbitMQ支持多種模式，滿足不同使用場景，包括簡單隊列模式、work模式、發(fā)布/訂閱模式、路由模式、topic模式等，提供CPU使用率、內(nèi)存使用率、磁盤使用率、文件句柄使用數(shù)、Sockets句柄使用數(shù)等監(jiān)控項，支持設置多項報警策略，幫助用戶了解實例動態(tài)：http://www.xinnet.com/cs/rabbitmq.html