點擊下方“IT牧場”，選擇“設爲星標”
-
正常電子商務流程
（1）查詢商品；
（2）創建訂單；
（3）扣減庫存；
（4）更新訂單；
（5）付款；
（6）賣家發貨；
-
秒殺業務的特性
（1）低廉價格；
（2）大幅推廣；
（3）瞬時售空；
（4）一般是定時上架；
（5）時間短、瞬時併發量高；
2 秒殺技術挑戰
-
對現有網站業務造成衝擊
解決方案 ：將秒殺系統獨立部署，甚至 使用獨立域名，使其與網站完全隔離 。
-
高併發下的應用、數據庫負載
解決方案 ：重新設計秒殺商品頁面，不使用網站原來的商品詳細頁面， 頁面內容靜態化，用戶請求不需要經過應用服務 。
-
突然增加的網絡及服務器帶寬
解決方案 ：因爲秒殺新增的網絡帶寬，必須和運營商重新購買或者租借。爲了減輕網站服務器的壓力，
需要將秒殺商品頁面緩存在CDN，同樣需要和CDN服務商臨時租借新增的出口帶寬 。
-
直接下單
解決方案 ：爲了避免用戶直接訪問下單頁面URL，需要將改URL動態化，即使秒殺系統的開發者也無法在秒殺開始前訪問下單頁面的URL。辦法是在
下單頁面URL加入由服務器端生成的隨機數作爲參數，在秒殺開始的時候才能得到 。
-
如何控制秒殺商品頁面購買按鈕的點亮
解決方案 ：使用JavaScript腳本控制，
在秒殺商品靜態頁面中加入一個JavaScript文件引用，該JavaScript文件中包含秒殺開始標誌爲否
；當秒殺開始的時候生成一個新的JavaScript文件（ 文件名保持不變，只是內容不一樣 ），更新秒殺開始標誌爲是，
加入下單頁面的URL及隨機數參數（這個隨機數只會產生一個，即所有人看到的URL都是同一個，服務器端可以用redis這種分佈式緩存服務器來保存隨機數）
，並被用戶瀏覽器加載，控制秒殺商品頁面的展示。
這個JavaScript文件的加載可以加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理服務器緩存 。這個JavaScript文件非常小，即使每次瀏覽器刷新都訪問JavaScript文件服務器也不會對服務器集羣和網絡帶寬造成太大壓力。
-
如何只允許第一個提交的訂單被髮送到訂單子系統
JavaScript文件，更新秒殺開始標誌爲否，購買按鈕變灰。事實上，由於最終能夠成功提交訂單的用戶只有一個，爲了減輕下單頁面服務器的負載壓力，可以
控制進入下單頁面的入口，只有少數用戶能進入下單頁面，其他用戶直接進入秒殺結束頁面 。
解決方案
：假設下單服務器集羣有10臺服務器，每臺服務器只接受最多10個下單請求。在還沒有人提交訂單成功之前，如果一臺服務器已經有十單了，而有的一單都沒處理，可能出現的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入已結束頁面，再刷新一下頁面，有可能被一單都沒有處理的服務器處理，進入了填寫訂單的頁面，
可以考慮通過cookie的方式來應對，符合一致性原則 。當然可以 採用最少連接的負載均衡算法 ，出現上述情況的概率大大降低。
-
如何進行下單前置檢查
-
下單服務器檢查本機已處理的下單請求數目：
如果超過10條，直接返回已結束頁面給用戶； 如果未超過10條，則用戶可進入填寫訂單及確認頁面；
-
檢查全局已提交訂單數目：
已超過秒殺商品總數，返回已結束頁面給用戶； 未超過秒殺商品總數，提交到子訂單系統；
-
秒殺一般是定時上架
有人可以繞過前端的限制，直接通過URL的方式發起購買
，這就需要在前臺商品頁面，以及bug頁面到後端的數據庫，都要進行時鐘同步。越在後端控制，安全性越高。
-
減庫存的操作
-
庫存會帶來“超賣”的問題：售出數量多於庫存數量
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#
-
秒殺器的應對
秒殺專用驗證碼，電視公佈驗證碼，秒殺答題 。
3 秒殺架構原則
-
儘量將請求攔截在系統上游
-
讀多寫少的常用多使用緩存
的應用場景【一趟火車其實只有2000張票，200w個人來買，最多2000個人下單成功，其他人都是查詢庫存，寫比例只有0.1%，讀比例佔99.9%】，
非常適合使用緩存 。
4 秒殺架構設計
，而不是商品詳情等用戶體驗細節，因此秒殺系統的頁面設計應儘可能簡單。
第一個階段是秒殺開始前某個時間到秒殺開始， 這個階段可以稱之爲 準備階段，用戶在準備階段等待秒殺 ； 第二個階段就是秒殺開始到所有參與秒殺的用戶獲得秒殺結果， 這個就稱爲 秒殺階段 吧。
4.1 前端層設計
。這裏需要考慮兩個問題：
-
第一個是秒殺頁面的展示
js，圖片等資源，如果同時有幾千萬人蔘與一個商品的搶購，一般機房帶寬也就只有1G
10G， 網絡帶寬就極有可能成爲瓶頸，所以這個頁面上 各類靜態資源首先應分開存放，然後放到cdn節點上分散壓力，由於CDN節點遍佈全國各地，能緩衝掉絕大部分的壓力，而且還比機房帶寬便宜
-
第二個是倒計時
客戶端與服務器時鐘不一致可以採用客戶端定時和服務器同步時間
，這裏考慮一下性能問題，用於同步時間的接口由於不涉及到後端邏輯，只需要將當前web服務器的時間發送給客戶端就可以了，因此速度很快，就我以前測試的結果來看，一臺標準的web服務器2W+QPS不會有問題，如果100W人同時刷，100W
QPS也只需要50臺web，一臺硬件LB就可以了~，並且web服務器羣是可以很容易的橫向擴展的(LB+DNS輪詢)，這個接口可以只返回一小段json格式的數據，而且可以優化一下減少不必要cookie和其他http頭的信息，所以數據量不會很大，
一般來說網絡不會成爲瓶頸，即使成爲瓶頸也可以考慮多機房專線連通，加智能DNS的解決方案 ；web服務器之間時間不同步可以採用統一時間服務器的方式，
比如每隔1分鐘所有參與秒殺活動的web服務器就與時間服務器做一次時間同步 。
-
瀏覽器層請求攔截
（1） 產品層面 ，用戶點擊“查詢”或者“購票”後，按鈕置灰，禁止用戶重複提交請求; （2） JS層面 ，限制用戶在x秒之內只能提交一次請求;
4.2 站點層設計
（1） 同一個uid，限制訪問頻度 ，做頁面緩存，x秒內到達站點層的請求，均返回同一頁面 （2） 同一個item的查詢，例如手機車次 ，做頁面緩存，x秒內到達站點層的請求，均返回同一頁面
4.3 服務層設計
（1）大哥，我是服務層，我清楚的知道小米只有1萬部手機，我清楚的知道一列火車只有2000張車票，我透10w個請求去數據庫有什麼意義呢？
對於寫請求，做請求隊列，每次只透過有限的寫請求去數據層，如果均成功再放下一批，如果庫存不夠則隊列裏的寫請求全部返回“已售完” ；（2） 對於讀請求，還用說麼？cache來抗 ，不管是memcached還是redis，單機抗個每秒10w應該都是沒什麼問題的；
用戶請求分發模塊 ：使用Nginx或Apache將用戶的請求分發到不同的機器上。 用戶請求預處理模塊 ：判斷商品是不是還有剩餘來決定是不是要處理該請求。 用戶請求處理模塊 ：把通過預處理的請求封裝成事務提交給數據庫，並返回是否成功。 數據庫接口模塊 ：該模塊是數據庫的唯一接口，負責與數據庫交互，提供RPC接口供查詢是否秒殺結束、剩餘數量等信息。
-
用戶請求預處理模塊
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();
}
}
}
-
併發隊列的選擇
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 基本概念
-
範圍：range
優點：簡單，容易擴展 缺點：各庫壓力不均（新號段更活躍）
-
哈希：hash 【大部分互聯網公司採用的方案二：哈希分庫，哈希路由】
優點：簡單，數據均衡，負載均勻 缺點：遷移麻煩（2庫擴3庫數據要遷移）
-
路由服務：router-config-server
優點：靈活性強，業務與路由算法解耦 缺點：每次訪問數據庫前多一次查詢
4.4.2 設計思路
如何保證數據可用性； 如何提高數據庫讀性能（大部分應用讀多寫少，讀會先成爲瓶頸）； 如何保證一致性； 如何提高擴展性；
-
如何保證數據的可用性？
如何保證站點的可用性？複製站點，冗餘站點 如何保證服務的可用性？複製服務，冗餘服務 如何保證數據的可用性？複製數據，冗餘數據
-
如何保證數據庫“讀”高可用？
-
如何保證數據庫“寫”高可用？
兩個寫庫使用不同的初始值，相同的步長來增加id：1寫庫的id爲0,2,4,6…；2寫庫的id爲1,3,5,7…； 不使用數據的id，業務層自己生成唯一的id，保證數據不衝突；
讀寫沒有延時； 讀寫高可用；
不能通過加從庫的方式擴展讀性能； 資源利用率爲50%，一臺冗餘主沒有提供服務；
-
如何擴展讀性能
寫庫 不建立索引； 線上讀庫 建立線上訪問索引，例如uid； 線下讀庫 建立線下訪問索引，例如time；
從庫越多，同步越慢； 同步越慢，數據不一致窗口越大（不一致後面說，還是先說讀性能的提高）；
。爲什麼要引入服務層，今天不展開，採用了“服務+數據庫+緩存一套”的方式提供數據訪問， 用cache提高讀性能 。
不管採用主從的方式擴展讀性能，還是緩存的方式擴展讀性能，數據都要複製多份（主+從，db+cache），一定會引發一致性問題。
-
如何保證一致性？
-
中間件
（百度，騰訊，阿里，360等一些公司有）。
-
強制讀主
（1）淘汰cache； （2）寫數據庫；
（1）讀cache，如果cache hit則返回； （2）如果cache miss，則讀從庫； （3）讀從庫後，將數據放回cache；
解決辦法是“緩存雙淘汰”
，寫操作時序升級爲：
（1）淘汰cache； （2）寫數據庫； （3）在經過“主從同步延時窗口時間”後，再次發起一個異步淘汰cache的請求；
-
如何提高數據庫的擴展性？
第一步 ，將一個主庫提升; 第二步 ，修改配置，2庫變4庫（原來MOD2，現在配置修改後MOD4），擴容完成；
；數據不需要遷移，同時，雙主互相同步，一遍是餘0，一邊餘2，兩邊數據同步也不會衝突，秒級完成擴容！
將舊的雙主同步解除； 增加新的雙主（雙主是保證可用性的，shadow-master平時不提供服務）； 刪除多餘的數據（餘0的主，可以將餘2的數據刪除掉）；
5 大併發帶來的挑戰
5.1 請求接口的合理設計
。這個後端接口，必須能夠支持高併發請求，同時，非常重要的一點，必須儘可能“快”，在最短的時間裏返回用戶的請求結果。
爲了實現儘可能快這一點，接口的後端存儲使用內存級別的操作會更好一點 。仍然直接面向MySQL之類的存儲是不合適的，
如果有這種複雜業務的需求，都建議採用異步寫入 。
，就是說秒殺當下不知道結果，一段時間後纔可以從頁面中看到用戶是否秒殺成功。但是，這種屬於“偷懶”行爲，同時給用戶的體驗也不好，容易被用戶認爲是“暗箱操作”。
5.2 高併發的挑戰：一定要“快”
。舉個例子，我們假設處理一個業務請求平均響應時間爲100ms，同時，系統內有20臺Apache的Web服務器，配置MaxClients爲500個（表示Apache的最大連接數目）。
20*500/0.1 = 100000 （10萬QPS）
在高併發的實際場景下，機器都處於高負載的狀態，在這個時候平均響應時間會被大大增加 。
。因此上述的 MaxClient數目，要根據CPU、內存等硬件因素綜合考慮，絕對不是越多越好 。可以
通過Apache自帶的abench來測試一下，取一個合適的值 。然後，我們
選擇內存操作級別的存儲的Redis，在高併發的狀態下，存儲的響應時間至關重要
。網絡帶寬雖然也是一個因素，不過，這種請求數據包一般比較小，一般很少成爲請求的瓶頸。負載均衡成爲系統瓶頸的情況比較少，在這裏不做討論哈。
20*500/0.25 = 40000 （4萬QPS）
惡性循環最終導致“雪崩”（其中一臺Web機器掛了，導致流量分散到其他正常工作的機器上，再導致正常的機器也掛，然後惡性循環） ，將整個Web系統拖垮。
5.3 重啓與過載保護
。如果是redis/memcache這種服務也掛了，重啓的時候需要注意“預熱”，並且很可能需要比較長的時間。
。在前端設置過濾是最簡單的方式，但是，這種做法是被用戶“千夫所指”的行爲。更合適一點的是， 將過載保護設置在CGI入口層，快速將客戶的直接請求返回
。
6 作弊的手段：進攻與防守
這種做法的理由也很簡單，就是在參與秒殺和搶購的請求中，自己的請求數目佔比越多，成功的概率越高 。
6.1 同一個賬號，一次性發出多個請求
多個併發請求通過負載均衡服務器，分配到內網的多臺Web服務器，它們首先向存儲發送查詢請求，然後，在某個請求成功寫入參與記錄的時間差內，其他的請求獲查詢到的結果都是“沒有參與記錄”
。這裏，就存在邏輯判斷被繞過的風險。
實現方案，可以通過Redis這種內存緩存服務，寫入一個標誌位（只允許1個請求寫成功，結合watch的樂觀鎖的特性），成功寫入的則可以繼續參加 。
6.2 多個賬號，一次性發送多個請求
也導致了出現了一些特殊的工作室，通過編寫自動註冊腳本，積累了一大批“殭屍賬號”，數量龐大，幾萬甚至幾十萬的賬號不等，專門做各種刷的行爲（這就是微博中的“殭屍粉“的來源）
。舉個例子，例如微博中有轉發抽獎的活動，如果我們使用幾萬個“殭屍號”去混進去轉發，這樣就可以大大提升我們中獎的概率。
彈出驗證碼，最核心的追求，就是分辨出真實用戶。
因此，大家可能經常發現，網站彈出的驗證碼，有些是“鬼神亂舞”的樣子，有時讓我們根本無法看清。他們這樣做的原因，其實也是爲了讓驗證碼的圖片不被輕易識別，因爲強大的“自動腳本”可以通過圖片識別裏面的字符，然後讓腳本自動填寫驗證碼。實際上，有一些非常創新的驗證碼，效果會比較好，例如給你一個簡單問題讓你回答，或者讓你完成某些簡單操作（例如百度貼吧的驗證碼）。直接禁止IP，實際上是有些粗暴的，因爲有些真實用戶的網絡場景恰好是同一出口IP的，可能會有“誤傷“
。但是這一個做法簡單高效，根據實際場景使用可以獲得很好的效果。
6.3 多個賬號，不同IP發送不同請求
這些“工作室”，發現你對單機IP請求頻率有控制之後，他們也針對這種場景，想出了他們的“新進攻方案”，就是不斷改變IP 。
。還有一些更爲黑暗一點的，就是
通過木馬黑掉普通用戶的電腦，這個木馬也不破壞用戶電腦的正常運作，只做一件事情，就是轉發IP包，普通用戶的電腦被變成了IP代理出口
。通過這種做法，黑客就拿到了大量的獨立IP，然後搭建爲隨機IP服務，就是爲了掙錢。
通常只能通過設置業務門檻高來限制這種請求了，或者通過賬號行爲的”數據挖掘“來提前清理掉它們 。
。根據這些特點，適當設置參與門檻，例如限制參與秒殺的賬號等級。 通過這些業務手段，也是可以過濾掉一些殭屍號 。
7 高併發下的數據安全
（多個線程同時運行同一段代碼，如果每次運行結果和單線程運行的結果是一樣的，結果和預期相同，就是線程安全的）。
如果是MySQL數據庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規模併發的場景中，是不推薦使用MySQL的 。
秒殺和搶購的場景中，還有另外一個問題，就是“超發”，如果在這方面控制不慎，會產生髮送過多的情況
。我們也曾經聽說過，某些電商搞搶購活動，買家成功拍下後，商家卻不承認訂單有效，拒絕發貨。這裏的問題，也許並不一定是商家奸詐，而是系統技術層面存在超發風險導致的。
7.1 超發的原因
7.2 悲觀鎖思路
悲觀鎖，也就是在修改數據的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。
我們的場景是“高併發”。也就是說，會很多這樣的修改請求，每個請求都需要等待“鎖”，某些線程可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那裏
。同時，這種請求會很多， 瞬間增大系統的平均響應時間，結果是可用連接數被耗盡，系統陷入異常 。
7.3 FIFO隊列思路
高併發的場景下，因爲請求很多，很可能一瞬間將隊列內存“撐爆”，然後系統又陷入到了異常狀態
。或者設計一個極大的內存隊列，也是一種方案，但是，系統處理完一個隊列內請求的速度根本無法和瘋狂湧入隊列中的數目相比。也就是說，隊列內的請求會越積累越多，最終Web系統平均響應時候還是會大幅下降，系統還是陷入異常。
7.4 樂觀鎖思路
實現就是，這個數據所有請求都有資格去修改，但會獲得一個該數據的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗。這樣的話，我們就不需要考慮隊列的問題，不過，
它會增大CPU的計算開銷 。但是，綜合來說，這是一個比較好的解決方案。
8 總結
來源 ：https://my.oschina.net/xianggao/blog/524943 版權申明： 內容來源網絡，版權歸原創者所有。 除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。 謝謝!
- EOF -
乾貨分享
最近將個人學習筆記整理成冊，使用PDF分享。關注我，回覆如下代碼，即可獲得百度盤地址，無套路領取！
•001：《Java併發與高併發解決方案》學習筆記；•002：《深入JVM內核——原理、診斷與優化》學習筆記；•003：《Java面試寶典》•004：《Docker開源書》•005：《Kubernetes開源書》•006：《DDD速成（領域驅動設計速成）》•007：全部•008：加技術羣討論
關注我
喜歡就點個"在看"唄^_^
本文分享自微信公衆號 - IT牧場（itmuch_com）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。