作者：猿碼道 jianshu.com/p/df4fbecb1a4b
1、秒殺業務分析
正常電子商務流程
（1）查詢商品； （2）建立訂單； （3）扣減庫存； （4）更新訂單； （5）付款； （6）賣家發貨；
秒殺業務的特性
（1）低廉價格； （2）大幅推廣； （3）瞬時售空； （4）一般是定時上架； （5）時間短、瞬時并發量高；
2、秒殺技術挑戰
假設某網站秒殺活動隻推出一件商品，預計會吸引1萬人參加活動，也就說最大并發請求數是10000，秒殺系統需要面對的技術挑戰有：
1.對現有網站業務造成沖擊
秒殺活動隻是網站營銷的一個附加活動，這個活動具有時間短，并發通路量大的特點，如果和網站原有應用部署在一起，必然會對現有業務造成沖擊，稍有不慎可能導緻整個網站癱瘓。
解決方案：将秒殺系統獨立部署，甚至使用獨立域名，使其與網站完全隔離。
2.高并發下的應用、資料庫負載
使用者在秒殺開始前，通過不停重新整理浏覽器頁面以保證不會錯過秒殺，這些請求如果按照一般的網站應用架構，通路應用伺服器、連接配接資料庫，會對應用伺服器和資料庫伺服器造成負載壓力。高可用高并發的 9 種技術架構，這個推薦看下。
解決方案：重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面，頁面内容靜态化，使用者請求不需要經過應用服務。
3.突然增加的網絡及伺服器帶寬
假設商品頁面大小200K（主要是商品圖檔大小），那麼需要的網絡和伺服器帶寬是2G（200K×10000），這些網絡帶寬是因為秒殺活動新增的，超過網站平時使用的帶寬。
解決方案：因為秒殺新增的網絡帶寬，必須和營運商重新購買或者租借。為了減輕網站伺服器的壓力，需要将秒殺商品頁面緩存在CDN，同樣需要和CDN服務商臨時租借新增的出口帶寬。
4.直接下單
秒殺的遊戲規則是到了秒殺才能開始對商品下單購買，在此時間點之前，隻能浏覽商品資訊，不能下單。而下單頁面也是一個普通的URL，如果得到這個URL，不用等到秒殺開始就可以下單了。
解決方案：為了避免使用者直接通路下單頁面URL，需要将改URL動态化，即使秒殺系統的開發者也無法在秒殺開始前通路下單頁面的URL。辦法是在下單頁面URL加入由伺服器端生成的随機數作為參數，在秒殺開始的時候才能得到。
5.如何控制秒殺商品頁面購買按鈕的點亮
購買按鈕隻有在秒殺開始的時候才能點亮，在此之前是灰色的。如果該頁面是動态生成的，當然可以在伺服器端構造響應頁面輸出，控制該按鈕是灰色還是點亮，但是為了減輕伺服器端負載壓力，更好地利用CDN、反向代理等性能優化手段，該頁面被設計為靜态頁面，緩存在CDN、反向代理伺服器上，甚至使用者浏覽器上。秒殺開始時，使用者重新整理頁面，請求根本不會到達應用伺服器。
解決方案：使用JavaScript腳本控制，在秒殺商品靜态頁面中加入一個JavaScript檔案引用，該JavaScript檔案中包含秒殺開始标志為否；當秒殺開始的時候生成一個新的JavaScript檔案（檔案名保持不變，隻是内容不一樣），更新秒殺開始标志為是，加入下單頁面的URL及随機數參數（這個随機數隻會産生一個，即所有人看到的URL都是同一個，伺服器端可以用redis這種分布式緩存伺服器來儲存随機數），并被使用者浏覽器加載，控制秒殺商品頁面的展示。這個JavaScript檔案的加載可以加上随機版本号（例如xx.js?v=32353823），這樣就不會被浏覽器、CDN和反向代理伺服器緩存。 這個JavaScript檔案非常小，即使每次浏覽器重新整理都通路JavaScript檔案伺服器也不會對伺服器叢集和網絡帶寬造成太大壓力。
6.如何隻允許第一個送出的訂單被發送到訂單子系統
由于最終能夠成功秒殺到商品的使用者隻有一個，是以需要在使用者送出訂單時，檢查是否已經有訂單送出。如果已經有訂單送出成功，則需要更新 JavaScript檔案，更新秒殺開始标志為否，購買按鈕變灰。事實上，由于最終能夠成功送出訂單的使用者隻有一個，為了減輕下單頁面伺服器的負載壓力，可以控制進入下單頁面的入口，隻有少數使用者能進入下單頁面，其他使用者直接進入秒殺結束頁面。
解決方案：假設下單伺服器叢集有10台伺服器，每台伺服器隻接受最多10個下單請求。在還沒有人送出訂單成功之前，如果一台伺服器已經有十單了，而有的一單都沒處理，可能出現的使用者體驗不佳的場景是使用者第一次點選購買按鈕進入已結束頁面，再重新整理一下頁面，有可能被一單都沒有處理的伺服器處理，進入了填寫訂單的頁面，可以考慮通過cookie的方式來應對，符合一緻性原則。當然可以采用最少連接配接的負載均衡算法，出現上述情況的機率大大降低。
7.如何進行下單前置檢查
下單伺服器檢查本機已處理的下單請求數目：
如果超過10條，直接傳回已結束頁面給使用者；
如果未超過10條，則使用者可進入填寫訂單及确認頁面；
檢查全局已送出訂單數目：
已超過秒殺商品總數，傳回已結束頁面給使用者；
未超過秒殺商品總數，送出到子訂單系統；
8.秒殺一般是定時上架
該功能實作方式很多。不過目前比較好的方式是：提前設定好商品的上架時間，使用者可以在前台看到該商品，但是無法點選“立即購買”的按鈕。但是需要考慮的是，有人可以繞過前端的限制，直接通過URL的方式發起購買，這就需要在前台商品頁面，以及bug頁面到後端的資料庫，都要進行時鐘同步。越在後端控制，安全性越高。
定時秒殺的話，就要避免賣家在秒殺前對商品做編輯帶來的不可預期的影響。這種特殊的變更需要多方面評估。一般禁止編輯，如需變更，可以走資料訂正的流程。
9.減庫存的操作
有兩種選擇，一種是拍下減庫存 另外一種是付款減庫存；目前采用的“拍下減庫存”的方式，拍下就是一瞬間的事，對使用者體驗會好些。老闆讓你抗住千萬級流量，如何做架構設計？推薦看下。
10.庫存會帶來“超賣”的問題：售出數量多于庫存數量
由于庫存并發更新的問題，導緻在實際庫存已經不足的情況下，庫存依然在減，導緻賣家的商品賣得件數超過秒殺的預期。方案：采用樂觀鎖
update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity# 還有一種方式，會更好些，叫做嘗試扣減庫存，扣減庫存成功才會進行下單邏輯：
update auction_auctions set
quantity = quantity-#count#
where auction_id = #itemId# and quantity >= #count# 11.秒殺器的應對
秒殺器一般下單個購買及其迅速，根據購買記錄可以甄别出一部分。可以通過校驗碼達到一定的方法，這就要求校驗碼足夠安全，不被破解，采用的方式有：秒殺專用驗證碼，電視公布驗證碼，秒殺答題。
3、秒殺架構原則
1.盡量将請求攔截在系統上遊
傳統秒殺系統之是以挂，請求都壓倒了後端資料層，資料讀寫鎖沖突嚴重，并發高響應慢，幾乎所有請求都逾時，流量雖大，下單成功的有效流量甚小【一趟火車其實隻有2000張票，200w個人來買，基本沒有人能買成功，請求有效率為0】。
2.讀多寫少的常用多使用緩存
這是一個典型的讀多寫少的應用場景【一趟火車其實隻有2000張票，200w個人來買，最多2000個人下單成功，其他人都是查詢庫存，寫比例隻有0.1%，讀比例占99.9%】，非常适合使用緩存。
4、秒殺架構設計
秒殺系統為秒殺而設計，不同于一般的網購行為，參與秒殺活動的使用者更關心的是如何能快速重新整理商品頁面，在秒殺開始的時候搶先進入下單頁面，而不是商品詳情等使用者體驗細節，是以秒殺系統的頁面設計應盡可能簡單。
商品頁面中的購買按鈕隻有在秒殺活動開始的時候才變亮，在此之前及秒殺商品賣出後，該按鈕都是灰色的，不可以點選。
下單表單也盡可能簡單，購買數量隻能是一個且不可以修改，送貨位址和付款方式都使用使用者預設設定，沒有預設也可以不填，允許等訂單送出後修改；隻有第一個送出的訂單發送給網站的訂單子系統，其餘使用者送出訂單後隻能看到秒殺結束頁面。
要做一個這樣的秒殺系統，業務會分為兩個階段：
第一個階段是秒殺開始前某個時間到秒殺開始， 這個階段可以稱之為準備階段，使用者在準備階段等待秒殺；
第二個階段就是秒殺開始到所有參與秒殺的使用者獲得秒殺結果， 這個就稱為秒殺階段吧。
4.1 前端層設計
首先要有一個展示秒殺商品的頁面，在這個頁面上做一個秒殺活動開始的倒計時，在準備階段内使用者會陸續打開這個秒殺的頁面， 并且可能不停的重新整理頁面。這裡需要考慮兩個問題：
第一個是秒殺頁面的展示
我們知道一個html頁面還是比較大的，即使做了壓縮，http頭和内容的大小也可能高達數十K，加上其他的css， js，圖檔等資源，如果同時有幾千萬人參與一個商品的搶購，一般機房帶寬也就隻有1G10G，網絡帶寬就極有可能成為瓶頸，是以這個頁面上各類靜态資源首先應分開存放，然後放到cdn節點上分散壓力，由于CDN節點遍布全國各地，能緩沖掉絕大部分的壓力，而且還比機房帶寬便宜
第二個是倒計時
出于性能原因這個一般由js調用用戶端本地時間，就有可能出現用戶端時鐘與伺服器時鐘不一緻，另外伺服器之間也是有可能出現時鐘不一緻。用戶端與伺服器時鐘不一緻可以采用用戶端定時和伺服器同步時間。
這裡考慮一下性能問題，用于同步時間的接口由于不涉及到後端邏輯，隻需要将目前web伺服器的時間發送給用戶端就可以了，是以速度很快，就我以前測試的結果來看，一台标準的web伺服器2W+QPS不會有問題，如果100W人同時刷，100W QPS也隻需要50台web，一台硬體LB就可以了~。
并且web伺服器群是可以很容易的橫向擴充的(LB+DNS輪詢)，這個接口可以隻傳回一小段json格式的資料，而且可以優化一下減少不必要cookie和其他http頭的資訊，是以資料量不會很大，一般來說網絡不會成為瓶頸，即使成為瓶頸也可以考慮多機房專線連通，加智能DNS的解決方案；web伺服器之間時間不同步可以采用統一時間伺服器的方式，比如每隔1分鐘所有參與秒殺活動的web伺服器就與時間伺服器做一次時間同步。秒殺系統必須考慮的 3 個技術問題！這篇也不錯。
浏覽器層請求攔截
産品層面，使用者點選“查詢”或者“購票”後，按鈕置灰，禁止使用者重複送出請求;
JS層面，限制使用者在x秒之内隻能送出一次請求;
4.2 站點層設計
前端層的請求攔截，隻能攔住小白使用者（不過這是99%的使用者喲），高端的程式員根本不吃這一套，寫個for循環，直接調用你後端的http請求，怎麼整？
同一個uid，限制通路頻度，做頁面緩存，x秒内到達站點層的請求，均傳回同一頁面
同一個item的查詢，例如手機車次，做頁面緩存，x秒内到達站點層的請求，均傳回同一頁面
如此限流，又有99%的流量會被攔截在站點層。
4.3 服務層設計
站點層的請求攔截，隻能攔住普通程式員，進階黑客，假設他控制了10w台殭屍電腦（并且假設買票不需要實名認證），這下uid的限制不行了吧？怎麼整？
大哥，我是服務層，我清楚的知道小米隻有1萬部手機，我清楚的知道一列火車隻有2000張車票，我透10w個請求去資料庫有什麼意義呢？對于寫請求，做請求隊列，每次隻透過有限的寫請求去資料層，如果均成功再放下一批，如果庫存不夠則隊列裡的寫請求全部傳回“已售完”；
對于讀請求，還用說麼？cache來抗，不管是memcached還是redis，單機抗個每秒10w應該都是沒什麼問題的；
如此限流，隻有非常少的寫請求，和非常少的讀緩存mis的請求會透到資料層去，又有99.9%的請求被攔住了。
使用者請求分發子產品：使用Nginx或Apache将使用者的請求分發到不同的機器上。
使用者請求預處理子產品：判斷商品是不是還有剩餘來決定是不是要處理該請求。
使用者請求處理子產品：把通過預處理的請求封裝成事務送出給資料庫，并傳回是否成功。
資料庫接口子產品：該子產品是資料庫的唯一接口，負責與資料庫互動，提供RPC接口供查詢是否秒殺結束、剩餘數量等資訊。
使用者請求預處理子產品
經過HTTP伺服器的分發後，單個伺服器的負載相對低了一些，但總量依然可能很大，如果背景商品已經被秒殺完畢，那麼直接給後來的請求傳回秒殺失敗即可，不必再進一步發送事務了，示例代碼可以如下所示：
package seckill;
import org.apache.http.HttpRequest;
/**
* 預處理階段，把不必要的請求直接駁回，必要的請求添加到隊列中進入下一階段.
*/
public class PreProcessor {
// 商品是否還有剩餘
private static boolean reminds = true;
private static void forbidden() {
// Do something.
}
public static boolean checkReminds() {
if (reminds) {
// 遠端檢測是否還有剩餘，該RPC接口應由資料庫伺服器提供，不必完全嚴格檢查.
if (!RPC.checkReminds()) {
reminds = false;
}
}
return reminds;
}
/**
* 每一個HTTP請求都要經過該預處理.
*/
public static void preProcess(HttpRequest request) {
if (checkReminds()) {
// 一個并發的隊列
RequestQueue.queue.add(request);
} else {
// 如果已經沒有商品了，則直接駁回請求即可.
forbidden();
}
}
} 并發隊列的選擇
Java的并發包提供了三個常用的并發隊列實作，分别是：ConcurrentLinkedQueue、LinkedBlockingQueue和ArrayBlockingQueue。
ArrayBlockingQueue是初始容量固定的阻塞隊列，我們可以用來作為資料庫子產品成功競拍的隊列，比如有10個商品，那麼我們就設定一個10大小的數組隊列。
ConcurrentLinkedQueue使用的是CAS原語無鎖隊列實作，是一個異步隊列，入隊的速度很快，出隊進行了加鎖，性能稍慢。
LinkedBlockingQueue也是阻塞的隊列，入隊和出隊都用了加鎖，當隊空的時候線程會暫時阻塞。
由于我們的系統入隊需求要遠大于出隊需求，一般不會出現隊空的情況，是以我們可以選擇ConcurrentLinkedQueue來作為我們的請求隊列實作：
package seckill;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ConcurrentLinkedQueue;
import org.apache.http.HttpRequest;
public class RequestQueue {
public static ConcurrentLinkedQueue<HttpRequest> queue = new ConcurrentLinkedQueue<HttpRequest>();
} 使用者請求子產品
package seckill;
import org.apache.http.HttpRequest;
public class Processor {
/**
* 發送秒殺事務到資料庫隊列.
*/
public static void kill(BidInfo info) {
DB.bids.add(info);
}
public static void process() {
BidInfo info = new BidInfo(RequestQueue.queue.poll());
if (info != null) {
kill(info);
}
}
}
class BidInfo {
BidInfo(HttpRequest request) {
// Do something.
}
} 資料庫子產品
資料庫主要是使用一個ArrayBlockingQueue來暫存有可能成功的使用者請求。
package seckill;
import java.util.concurrent.ArrayBlockingQueue;
/**
* DB應該是資料庫的唯一接口.
*/
public class DB {
public static int count = 10;
public static ArrayBlockingQueue<BidInfo> bids = new ArrayBlockingQueue<BidInfo>(10);
public static boolean checkReminds() {
// TODO
return true;
}
// 單線程操作
public static void bid() {
BidInfo info = bids.poll();
while (count-- > 0) {
// insert into table Bids values(item_id, user_id, bid_date, other)
// select count(id) from Bids where item_id = ?
// 如果資料庫商品數量大約總數，則标志秒殺已完成，設定标志位reminds = false.
info = bids.poll();
}
}
} 4.4 資料庫設計
4.4.1 基本概念
概念一“單庫”
概念二“分片”
分片解決的是“資料量太大”的問題，也就是通常說的“水準切分”。一旦引入分片，勢必有“資料路由”的概念，哪個資料通路哪個庫。路由規則通常有3種方法：
1、範圍：range
優點：簡單，容易擴充 缺點：各庫壓力不均（新号段更活躍）
2、哈希：hash 【大部分網際網路公司采用的方案二：哈希分庫，哈希路由】
優點：簡單，資料均衡，負載均勻 缺點：遷移麻煩（2庫擴3庫資料要遷移）
3、路由服務：router-config-server
優點：靈活性強，業務與路由算法解耦 缺點：每次通路資料庫前多一次查詢
概念三“分組”
分組解決“可用性”問題，分組通常通過主從複制的方式實作。
網際網路公司資料庫實際軟體架構是：又分片，又分組（如下圖）
4.4.2 設計思路
資料庫軟體架構師平時設計些什麼東西呢？至少要考慮以下四點：
如何保證資料可用性；
如何提高資料庫讀性能（大部分應用讀多寫少，讀會先成為瓶頸）；
如何保證一緻性；
如何提高擴充性；
1.如何保證資料的可用性？
解決可用性問題的思路是=>備援
如何保證站點的可用性？複制站點，備援站點 如何保證服務的可用性？複制服務，備援服務 如何保證資料的可用性？複制資料，備援資料
資料的備援，會帶來一個副作用=>引發一緻性問題（先不說一緻性問題，先說可用性）。
2.如何保證資料庫“讀”高可用？
備援讀庫
備援讀庫帶來的副作用？讀寫有延時，可能不一緻。
上面這個圖是很多網際網路公司mysql的架構，寫仍然是單點，不能保證寫高可用。
3.如何保證資料庫“寫”高可用？
備援寫庫
采用雙主互備的方式，可以備援寫庫帶來的副作用？雙寫同步，資料可能沖突（例如“自增id”同步沖突），如何解決同步沖突，有兩種常見解決方案：
兩個寫庫使用不同的初始值，相同的步長來增加id：1寫庫的id為0,2,4,6…；2寫庫的id為1,3,5,7…；
不使用資料的id，業務層自己生成唯一的id，保證資料不沖突；
實際中沒有使用上述兩種架構來做讀寫的“高可用”，采用的是“雙主當主從用”的方式：
仍是雙主，但隻有一個主提供服務（讀+寫），另一個主是“shadow-master”，隻用來保證高可用，平時不提供服務。
master挂了，shadow-master頂上（vip漂移，對業務層透明，不需要人工介入）。
這種方式的好處：
讀寫沒有延時；
讀寫高可用；
不足：
不能通過加從庫的方式擴充讀性能；
資源使用率為50%，一台備援主沒有提供服務；
那如何提高讀性能呢？進入第二個話題，如何提供讀性能。
4.如何擴充讀性能
提高讀性能的方式大緻有三種：
第一種是建立索引。這種方式不展開，要提到的一點是，不同的庫可以建立不同的索引。
寫庫不建立索引； 線上讀庫建立線上通路索引，例如uid； 線下讀庫建立線下通路索引，例如time；
第二種擴充讀性能的方式是，增加從庫，這種方法大家用的比較多，但是，存在兩個缺點：
從庫越多，同步越慢；
同步越慢，資料不一緻視窗越大（不一緻後面說，還是先說讀性能的提高）；
實際中沒有采用這種方法提高資料庫讀性能（沒有從庫），采用的是增加緩存。常見的緩存架構如下：
上遊是業務應用，下遊是主庫，從庫（讀寫分離），緩存。實際的玩法：服務+資料庫+緩存一套。
業務層不直接面向db和cache，服務層屏蔽了底層db、cache的複雜性。為什麼要引入服務層，今天不展開，采用了“服務+資料庫+緩存一套”的方式提供資料通路，用cache提高讀性能。
不管采用主從的方式擴充讀性能，還是緩存的方式擴充讀性能，資料都要複制多份（主+從，db+cache），一定會引發一緻性問題。
5.如何保證一緻性？
主從資料庫的一緻性，通常有兩種解決方案：
1、中間件
如果某一個key有寫操作，在不一緻時間視窗内，中間件會将這個key的讀操作也路由到主庫上。這個方案的缺點是，資料庫中間件的門檻較高（百度，騰訊，阿裡，360等一些公司有）。
2、強制讀主
上面實際用的“雙主當主從用”的架構，不存在主從不一緻的問題。第二類不一緻，是db與緩存間的不一緻：
常見的緩存架構如上，此時寫操作的順序是：
（1）淘汰cache； （2）寫資料庫；
讀操作的順序是：
（1）讀cache，如果cache hit則傳回； （2）如果cache miss，則讀從庫； （3）讀從庫後，将資料放回cache；
在一些異常時序情況下，有可能從【從庫讀到舊資料（同步還沒有完成），舊資料入cache後】，資料會長期不一緻。解決辦法是“緩存雙淘汰”，寫操作時序更新為：
（1）淘汰cache； （2）寫資料庫； （3）在經過“主從同步延時視窗時間”後，再次發起一個異步淘汰cache的請求；
這樣，即使有髒資料如cache，一個小的時間視窗之後，髒資料還是會被淘汰。帶來的代價是，多引入一次讀miss（成本可以忽略）。
除此之外，最佳實踐之一是：建議為所有cache中的item設定一個逾時時間。
3.如何提高資料庫的擴充性？
原來用hash的方式路由，分為2個庫，資料量還是太大，要分為3個庫，勢必需要進行資料遷移，有一個很帥氣的“資料庫秒級擴容”方案。
如何秒級擴容？
首先，我們不做2庫變3庫的擴容，我們做2庫變4庫（庫加倍）的擴容（未來4->8->16）
服務+資料庫是一套（省去了緩存），資料庫采用“雙主”的模式。
擴容步驟：
第一步，将一個主庫提升;
第二步，修改配置，2庫變4庫（原來MOD2，現在配置修改後MOD4），擴容完成；
原MOD2為偶的部分，現在會MOD4餘0或者2；原MOD2為奇的部分，現在會MOD4餘1或者3；資料不需要遷移，同時，雙主互相同步，一遍是餘0，一邊餘2，兩邊資料同步也不會沖突，秒級完成擴容！
最後，要做一些收尾工作：
将舊的雙主同步解除；
增加新的雙主（雙主是保證可用性的，shadow-master平時不提供服務）；
删除多餘的資料（餘0的主，可以将餘2的資料删除掉）；
這樣，秒級别内，我們就完成了2庫變4庫的擴充。
5、大并發帶來的挑戰
5.1、請求接口的合理設計
一個秒殺或者搶購頁面，通常分為2個部分，一個是靜态的HTML等内容，另一個就是參與秒殺的Web背景請求接口。
通常靜态HTML等内容，是通過CDN的部署，一般壓力不大，核心瓶頸實際上在背景請求接口上。這個後端接口，必須能夠支援高并發請求，同時，非常重要的一點，必須盡可能“快”，在最短的時間裡傳回使用者的請求結果。為了實作盡可能快這一點，接口的後端存儲使用記憶體級别的操作會更好一點。仍然直接面向MySQL之類的存儲是不合适的，如果有這種複雜業務的需求，都建議采用異步寫入。
當然，也有一些秒殺和搶購采用“滞後回報”，就是說秒殺當下不知道結果，一段時間後才可以從頁面中看到使用者是否秒殺成功。但是，這種屬于“偷懶”行為，同時給使用者的體驗也不好，容易被使用者認為是“暗箱操作”。
5.2 高并發的挑戰：一定要“快”
我們通常衡量一個Web系統的吞吐率的名額是QPS（Query Per Second，每秒處理請求數），解決每秒數萬次的高并發場景，這個名額非常關鍵。舉個例子，我們假設處理一個業務請求平均響應時間為100ms，同時，系統内有20台Apache的Web伺服器，配置MaxClients為500個（表示Apache的最大連接配接數目）。
那麼，我們的Web系統的理論峰值QPS為（理想化的計算方式）：
20*500/0.1 = 100000 （10萬QPS）
咦？我們的系統似乎很強大，1秒鐘可以處理完10萬的請求，5w/s的秒殺似乎是“紙老虎”哈。實際情況，當然沒有這麼理想。在高并發的實際場景下，機器都處于高負載的狀态，在這個時候平均響應時間會被大大增加。
就Web伺服器而言，Apache打開了越多的連接配接程序，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗，然後就直接導緻平均響應時間增加。是以上述的MaxClient數目，要根據CPU、記憶體等硬體因素綜合考慮，絕對不是越多越好。可以通過Apache自帶的abench來測試一下，取一個合适的值。然後，我們選擇記憶體操作級别的存儲的Redis，在高并發的狀态下，存儲的響應時間至關重要。網絡帶寬雖然也是一個因素，不過，這種請求資料包一般比較小，一般很少成為請求的瓶頸。負載均衡成為系統瓶頸的情況比較少，在這裡不做讨論哈。
那麼問題來了，假設我們的系統，在5w/s的高并發狀态下，平均響應時間從100ms變為250ms（實際情況，甚至更多）：
20*500/0.25 = 40000 （4萬QPS）
于是，我們的系統剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。
然後，這才是真正的惡夢開始。舉個例子，高速路口，1秒鐘來5部車，每秒通過5部車，高速路口運作正常。突然，這個路口1秒鐘隻能通過4部車，車流量仍然依舊，結果必定出現大塞車。（5條車道忽然變成4條車道的感覺）。
同理，某一個秒内，20*500個可用連接配接程序都在滿負荷工作中，卻仍然有1萬個新來請求，沒有連接配接程序可用，系統陷入到異常狀态也是預期之内。
其實在正常的非高并發的業務場景中，也有類似的情況出現，某個業務請求接口出現問題，響應時間極慢，将整個Web請求響應時間拉得很長，逐漸将Web伺服器的可用連接配接數占滿，其他正常的業務請求，無連接配接程序可用。
更可怕的問題是，是使用者的行為特點，系統越是不可用，使用者的點選越頻繁，惡性循環最終導緻“雪崩”（其中一台Web機器挂了，導緻流量分散到其他正常工作的機器上，再導緻正常的機器也挂，然後惡性循環），将整個Web系統拖垮。
5.3 重新開機與過載保護
如果系統發生“雪崩”，貿然重新開機服務，是無法解決問題的。最常見的現象是，啟動起來後，立刻挂掉。這個時候，最好在入口層将流量拒絕，然後再将重新開機。如果是redis/memcache這種服務也挂了，重新開機的時候需要注意“預熱”，并且很可能需要比較長的時間。
秒殺和搶購的場景，流量往往是超乎我們系統的準備和想象的。這個時候，過載保護是必要的。如果檢測到系統滿負載狀态，拒絕請求也是一種保護措施。在前端設定過濾是最簡單的方式，但是，這種做法是被使用者“千夫所指”的行為。更合适一點的是，将過載保護設定在CGI入口層，快速将客戶的直接請求傳回。
6、作弊的手段：進攻與防守
秒殺和搶購收到了“海量”的請求，實際上裡面的水分是很大的。不少使用者，為了“搶“到商品，會使用“刷票工具”等類型的輔助工具，幫助他們發送盡可能多的請求到伺服器。還有一部分進階使用者，制作強大的自動請求腳本。這種做法的理由也很簡單，就是在參與秒殺和搶購的請求中，自己的請求數目占比越多，成功的機率越高。
這些都是屬于“作弊的手段”，不過，有“進攻”就有“防守”，這是一場沒有硝煙的戰鬥哈。
6.1、同一個賬号，一次性發出多個請求
部分使用者通過浏覽器的插件或者其他工具，在秒殺開始的時間裡，以自己的賬号，一次發送上百甚至更多的請求。實際上，這樣的使用者破壞了秒殺和搶購的公平性。
這種請求在某些沒有做資料安全處理的系統裡，也可能造成另外一種破壞，導緻某些判斷條件被繞過。例如一個簡單的領取邏輯，先判斷使用者是否有參與記錄，如果沒有則領取成功，最後寫入到參與記錄中。這是個非常簡單的邏輯，但是，在高并發的場景下，存在深深的漏洞。多個并發請求通過負載均衡伺服器，配置設定到内網的多台Web伺服器，它們首先向存儲發送查詢請求，然後，在某個請求成功寫入參與記錄的時間差内，其他的請求獲查詢到的結果都是“沒有參與記錄”。這裡，就存在邏輯判斷被繞過的風險。
應對方案：
在程式入口處，一個賬号隻允許接受1個請求，其他請求過濾。不僅解決了同一個賬号，發送N個請求的問題，還保證了後續的邏輯流程的安全。實作方案，可以通過Redis這種記憶體緩存服務，寫入一個标志位（隻允許1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則可以繼續參加。
或者，自己實作一個服務，将同一個賬号的請求放入一個隊列中，處理完一個，再處理下一個。
6.2、多個賬号，一次性發送多個請求
很多公司的賬号注冊功能，在發展早期幾乎是沒有限制的，很容易就可以注冊很多個賬号。是以，也導緻了出現了一些特殊的工作室，通過編寫自動注冊腳本，積累了一大批“僵屍賬号”，數量龐大，幾萬甚至幾十萬的賬号不等，專門做各種刷的行為（這就是微網誌中的“僵屍粉“的來源）。
舉個例子，例如微網誌中有轉發抽獎的活動，如果我們使用幾萬個“僵屍号”去混進去轉發，這樣就可以大大提升我們中獎的機率。
這種賬号，使用在秒殺和搶購裡，也是同一個道理。例如，iPhone官網的搶購，火車票黃牛黨。
這種場景，可以通過檢測指定機器IP請求頻率就可以解決，如果發現某個IP請求頻率很高，可以給它彈出一個驗證碼或者直接禁止它的請求：
彈出驗證碼，最核心的追求，就是分辨出真實使用者。是以，大家可能經常發現，網站彈出的驗證碼，有些是“鬼神亂舞”的樣子，有時讓我們根本無法看清。他們這樣做的原因，其實也是為了讓驗證碼的圖檔不被輕易識别，因為強大的“自動腳本”可以通過圖檔識别裡面的字元，然後讓腳本自動填寫驗證碼。實際上，有一些非常創新的驗證碼，效果會比較好，例如給你一個簡單問題讓你回答，或者讓你完成某些簡單操作（例如百度貼吧的驗證碼）。
直接禁止IP，實際上是有些粗暴的，因為有些真實使用者的網絡場景恰好是同一出口IP的，可能會有“誤傷“。但是這一個做法簡單高效，根據實際場景使用可以獲得很好的效果。關注Java技術棧微信公衆号，在背景回複關鍵字：_架構_，可以擷取更多棧長整理的架構幹貨。
6.3、多個賬号，不同IP發送不同請求
所謂道高一尺，魔高一丈。有進攻，就會有防守，永不休止。這些“工作室”，發現你對單機IP請求頻率有控制之後，他們也針對這種場景，想出了他們的“新進攻方案”，就是不斷改變IP。
有同學會好奇，這些随機IP服務怎麼來的。有一些是某些機構自己占據一批獨立IP，然後做成一個随機代理IP的服務，有償提供給這些“工作室”使用。還有一些更為黑暗一點的，就是通過木馬黑掉普通使用者的電腦，這個木馬也不破壞使用者電腦的正常運作，隻做一件事情，就是轉發IP包，普通使用者的電腦被變成了IP代理出口。通過這種做法，黑客就拿到了大量的獨立IP，然後搭建為随機IP服務，就是為了掙錢。
說實話，這種場景下的請求，和真實使用者的行為，已經基本相同了，想做分辨很困難。再做進一步的限制很容易“誤傷“真實使用者，這個時候，通常隻能通過設定業務門檻高來限制這種請求了，或者通過賬号行為的”資料挖掘“來提前清理掉它們。
僵屍賬号也還是有一些共同特征的，例如賬号很可能屬于同一個号碼段甚至是連号的，活躍度不高，等級低，資料不全等等。根據這些特點，适當設定參與門檻，例如限制參與秒殺的賬号等級。通過這些業務手段，也是可以過濾掉一些僵屍号。
7、高并發下的資料安全
我們知道在多線程寫入同一個檔案的時候，會存現“線程安全”的問題（多個線程同時運作同一段代碼，如果每次運作結果和單線程運作的結果是一樣的，結果和預期相同，就是線程安全的）。如果是MySQL資料庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規模并發的場景中，是不推薦使用MySQL的。
秒殺和搶購的場景中，還有另外一個問題，就是“超發”，如果在這方面控制不慎，會産生發送過多的情況。我們也曾經聽說過，某些電商搞搶購活動，買家成功拍下後，商家卻不承認訂單有效，拒絕發貨。這裡的問題，也許并不一定是商家奸詐，而是系統技術層面存在超發風險導緻的。
7.1、超發的原因
假設某個搶購場景中，我們一共隻有100個商品，在最後一刻，我們已經消耗了99個商品，僅剩最後一個。這個時候，系統發來多個并發請求，這批請求讀取到的商品餘量都是99個，然後都通過了這一個餘量判斷，最終導緻超發。
在上面的這個圖中，就導緻了并發使用者B也“搶購成功”，多讓一個人獲得了商品。這種場景，在高并發的情況下非常容易出現。
7.2、悲觀鎖思路
解決線程安全的思路很多，可以從“悲觀鎖”的方向開始讨論。
悲觀鎖，也就是在修改資料的時候，采用鎖定狀态，排斥外部請求的修改。遇到加鎖的狀态，就必須等待。
雖然上述的方案的确解決了線程安全的問題，但是，别忘記，我們的場景是“高并發”。也就是說，會很多這樣的修改請求，每個請求都需要等待“鎖”，某些線程可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那裡。同時，這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連接配接數被耗盡，系統陷入異常。
7.3、FIFO隊列思路
那好，那麼我們稍微修改一下上面的場景，我們直接将請求放入隊列中的，采用FIFO（First Input First Output，先進先出），這樣的話，我們就不會導緻某些請求永遠擷取不到鎖。看到這裡，是不是有點強行将多線程變成單線程的感覺哈。
然後，我們現在解決了鎖的問題，全部請求采用“先進先出”的隊列方式來處理。那麼新的問題來了，高并發的場景下，因為請求很多，很可能一瞬間将隊列記憶體“撐爆”，然後系統又陷入到了異常狀态。或者設計一個極大的記憶體隊列，也是一種方案，但是，系統處理完一個隊列内請求的速度根本無法和瘋狂湧入隊列中的數目相比。也就是說，隊列内的請求會越積累越多，最終Web系統平均響應時候還是會大幅下降，系統還是陷入異常。
7.4、樂觀鎖思路
這個時候，我們就可以讨論一下“樂觀鎖”的思路了。樂觀鎖，是相對于“悲觀鎖”采用更為寬松的加鎖機制，大都是采用帶版本号（Version）更新。實作就是，這個資料所有請求都有資格去修改，但會獲得一個該資料的版本号，隻有版本号符合的才能更新成功，其他的傳回搶購失敗。這樣的話，我們就不需要考慮隊列的問題，不過，它會增大CPU的計算開銷。但是，綜合來說，這是一個比較好的解決方案。
有很多軟體和服務都“樂觀鎖”功能的支援，例如Redis中的watch就是其中之一。通過這個實作，我們保證了資料的安全。
8、總結
網際網路正在高速發展，使用網際網路服務的使用者越多，高并發的場景也變得越來越多。電商秒殺和搶購，是兩個比較典型的網際網路高并發場景。雖然我們解決問題的具體技術方案可能千差萬别，但是遇到的挑戰卻是相似的，是以解決問題的思路也異曲同工。