愛鋒貝

標題: 萬字長文，解密秒殺架構(gòu)！(建議收藏) [打印本頁]
作者: ★小梁帶你玩手機★    時間: 2022-9-22 09:36
標題: 萬字長文，解密秒殺架構(gòu)！(建議收藏)
網(wǎng)購相信大家一定不陌生，很多小伙伴甚至號稱“剁手達人”，今天我們就來聊下電商中的秒殺系統(tǒng)是如何架構(gòu)？

(, 下載次數(shù): 14)
1 秒殺業(yè)務(wù)分析

1. 正常電子商務(wù)流程
（1）查詢商品；
（2）創(chuàng)建訂單；
（3）扣減庫存；
（4）更新訂單；
（5）付款；
（6）賣家發(fā)貨
2. 秒殺業(yè)務(wù)的特性
（1）低廉價格；
（2）大幅推廣；
（3）瞬時售空；
（4）一般是定時上架；
（5）時間短、瞬時并發(fā)量高；
2 秒殺技術(shù)挑戰(zhàn)

假設(shè)某網(wǎng)站秒殺活動只推出一件商品，預計會吸引1萬人參加活動，也就說最大并發(fā)請求數(shù)是10000，秒殺系統(tǒng)需要面對的技術(shù)挑戰(zhàn)有：
秒殺活動只是網(wǎng)站營銷的一個附加活動，這個活動具有時間短，并發(fā)訪問量大的特點，如果和網(wǎng)站原有應(yīng)用部署在一起，必然會對現(xiàn)有業(yè)務(wù)造成沖擊，稍有不慎可能導致整個網(wǎng)站癱瘓。
解決方案：將秒殺系統(tǒng)獨立部署，甚至 使用獨立域名，使其與網(wǎng)站完全隔離 。
用戶在秒殺開始前，通過不停刷新瀏覽器頁面以保證不會錯過秒殺，這些請求如果按照一般的網(wǎng)站應(yīng)用架構(gòu)，訪問應(yīng)用服務(wù)器、連接數(shù)據(jù)庫，會對應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器造成負載壓力。
解決方案：重新設(shè)計秒殺商品頁面，不使用網(wǎng)站原來的商品詳細頁面， 頁面內(nèi)容靜態(tài)化，用戶請求不需要經(jīng)過應(yīng)用服務(wù) 。
假設(shè)商品頁面大小200K（主要是商品圖片大?。?，那么需要的網(wǎng)絡(luò)和服務(wù)器帶寬是2G（200K×10000），這些網(wǎng)絡(luò)帶寬是因為秒殺活動新增的，超過網(wǎng)站平時使用的帶寬。
解決方案：因為秒殺新增的網(wǎng)絡(luò)帶寬，必須和運營商重新購買或者租借。為了減輕網(wǎng)站服務(wù)器的壓力， 需要將秒殺商品頁面緩存在CDN，同樣需要和CDN服務(wù)商臨時租借新增的出口帶寬 。
秒殺的游戲規(guī)則是到了秒殺才能開始對商品下單購買，在此時間點之前，只能瀏覽商品信息，不能下單。而下單頁面也是一個普通的URL，如果得到這個URL，不用等到秒殺開始就可以下單了。
解決方案：為了避免用戶直接訪問下單頁面URL，需要將改URL動態(tài)化，即使秒殺系統(tǒng)的開發(fā)者也無法在秒殺開始前訪問下單頁面的URL。辦法是在 下單頁面URL加入由服務(wù)器端生成的隨機數(shù)作為參數(shù)，在秒殺開始的時候才能得到 。
購買按鈕只有在秒殺開始的時候才能點亮，在此之前是灰色的。如果該頁面是動態(tài)生成的，當然可以在服務(wù)器端構(gòu)造響應(yīng)頁面輸出，控制該按鈕是灰色還 是點亮，但是為了減輕服務(wù)器端負載壓力，更好地利用CDN、反向代理等性能優(yōu)化手段，該頁面被設(shè)計為靜態(tài)頁面，緩存在CDN、反向代理服務(wù)器上，甚至用戶瀏覽器上。秒殺開始時，用戶刷新頁面，請求根本不會到達應(yīng)用服務(wù)器。
解決方案：使用JavaScript腳本控制， 在秒殺商品靜態(tài)頁面中加入一個JavaScript文件引用，該JavaScript文件中包含 秒殺開始標志為否 ；當秒殺開始的時候生成一個新的JavaScript文件（文件名保持不變，只是內(nèi)容不一樣），更新秒殺開始標志為是， 加入下單頁面的URL及隨機數(shù)參數(shù)（這個隨機數(shù)只會產(chǎn)生一個，即所有人看到的URL都是同一個，服務(wù)器端可以用redis這種分布式緩存服務(wù)器來保存隨機數(shù)） ，并被用戶瀏覽器加載，控制秒殺商品頁面的展示。 這個JavaScript文件的加載可以加上隨機版本號（例如xx.js?v=32353823），這樣就不會被瀏覽器、CDN和反向代理服務(wù)器緩存 。
這個JavaScript文件非常小，即使每次瀏覽器刷新都訪問JavaScript文件服務(wù)器也不會對服務(wù)器集群和網(wǎng)絡(luò)帶寬造成太大壓力。
由于最終能夠成功秒殺到商品的用戶只有一個，因此需要在用戶提交訂單時，檢查是否已經(jīng)有訂單提交。如果已經(jīng)有訂單提交成功，則需要更新 JavaScript文件，更新秒殺開始標志為否，購買按鈕變灰。事實上，由于最終能夠成功提交訂單的用戶只有一個，為了減輕下單頁面服務(wù)器的負載壓力， 可以控制進入下單頁面的入口，只有少數(shù)用戶能進入下單頁面，其他用戶直接進入秒殺結(jié)束頁面。
解決方案：假設(shè)下單服務(wù)器集群有10臺服務(wù)器，每臺服務(wù)器只接受最多10個下單請求。在還沒有人提交訂單成功之前，如果一臺服務(wù)器已經(jīng)有十單了，而有的一單都沒處理，可能出現(xiàn)的用戶體驗不佳的場景是用戶第一次點擊購買按鈕進入已結(jié)束頁面，再刷新一下頁面，有可能被一單都沒有處理的服務(wù)器處理，進入了填寫訂單的頁面， 可以考慮通過cookie的方式來應(yīng)對，符合一致性原則 。當然可以 采用最少連接的負載均衡算法 ，出現(xiàn)上述情況的概率大大降低。

如果超過10條，直接返回已結(jié)束頁面給用戶；
如果未超過10條，則用戶可進入填寫訂單及確認頁面；
已超過秒殺商品總數(shù)，返回已結(jié)束頁面給用戶；
未超過秒殺商品總數(shù)，提交到子訂單系統(tǒng)；
該功能實現(xiàn)方式很多。不過目前比較好的方式是：提前設(shè)定好商品的上架時間，用戶可以在前臺看到該商品，但是無法點擊“立即購買”的按鈕。但是需要考慮的是， 有人可以繞過前端的限制，直接通過URL的方式發(fā)起購買 ，這就需要在前臺商品頁面，以及bug頁面到后端的數(shù)據(jù)庫，都要進行時鐘同步。越在后端控制，安全性越高。
定時秒殺的話，就要避免賣家在秒殺前對商品做編輯帶來的不可預期的影響。這種特殊的變更需要多方面評估。一般禁止編輯，如需變更，可以走數(shù)據(jù)訂正多的流程。
有兩種選擇，一種是 拍下減庫存 另外一種是 付款減庫存 ；目前采用的 “拍下減庫存” 的方式，拍下就是一瞬間的事，對用戶體驗會好些。
庫存會帶來“超賣”的問題：售出數(shù)量多于庫存數(shù)量

由于庫存并發(fā)更新的問題，導致在實際庫存已經(jīng)不足的情況下，庫存依然在減，導致賣家的商品賣得件數(shù)超過秒殺的預期。方案： 采用樂觀鎖
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#
秒殺器一般下單個購買及其迅速，根據(jù)購買記錄可以甄別出一部分?？梢酝ㄟ^校驗碼達到一定的方法，這就要求校驗碼足夠安全，不被破解，采用的方式有： 秒殺專用驗證碼，電視公布驗證碼，秒殺答題 。
3 秒殺架構(gòu)原則

傳統(tǒng)秒殺系統(tǒng)之所以掛，請求都壓倒了后端數(shù)據(jù)層，數(shù)據(jù)讀寫鎖沖突嚴重，并發(fā)高響應(yīng)慢，幾乎所有請求都超時，流量雖大，下單成功的有效流量甚小【一趟火車其實只有2000張票，200w個人來買，基本沒有人能買成功，請求有效率為0】。
這是一個典型的 讀多寫少 的應(yīng)用場景【一趟火車其實只有2000張票，200w個人來買，最多2000個人下單成功，其他人都是查詢庫存，寫比例只有0.1%，讀比例占99.9%】， 非常適合使用緩存 。
4 秒殺架構(gòu)設(shè)計

秒殺系統(tǒng)為秒殺而設(shè)計，不同于一般的網(wǎng)購行為，參與秒殺活動的用戶更關(guān)心的是如何能快速刷新商品頁面，在秒殺開始的時候搶先進入下單頁面，而不是商品詳情等用戶體驗細節(jié)，因此秒殺系統(tǒng)的頁面設(shè)計應(yīng)盡可能簡單。
商品頁面中的購買按鈕只有在秒殺活動開始的時候才變亮，在此之前及秒殺商品賣出后，該按鈕都是灰色的，不可以點擊。
下單表單也盡可能簡單，購買數(shù)量只能是一個且不可以修改，送貨地址和付款方式都使用用戶默認設(shè)置，沒有默認也可以不填，允許等訂單提交后修改；只有第一個提交的訂單發(fā)送給網(wǎng)站的訂單子系統(tǒng)，其余用戶提交訂單后只能看到秒殺結(jié)束頁面。
要做一個這樣的秒殺系統(tǒng)，業(yè)務(wù)會分為兩個階段， 第一個階段是秒殺開始前某個時間到秒殺開始 ， 這個階段可以稱之為 準備階段 ，用戶在準備階段等待秒殺； 第二個階段就是秒殺開始到所有參與秒殺的用戶獲得秒殺結(jié)果 ， 這個就稱為 秒殺階段 吧。
4.1 前端層設(shè)計

首先要有一個展示秒殺商品的頁面， 在這個頁面上做一個秒殺活動開始的倒計時， 在準備階段內(nèi)用戶會陸續(xù)打開這個秒殺的頁面， 并且可能不停的刷新頁面 。這里需要考慮兩個問題：
我們知道一個html頁面還是比較大的， 即使做了壓縮，http頭和內(nèi)容的大小也可能高達數(shù)十K，加上其他的css， js，圖片等資源 ，如果同時有幾千萬人參與一個商品的搶購，一般機房帶寬也就只有1G~10G， 網(wǎng)絡(luò)帶寬就極有可能成為瓶頸 ，所以這個頁面上 各類靜態(tài)資源首先應(yīng)分開存放，然后放到cdn節(jié)點上分散壓力 ，由于CDN節(jié)點遍布全國各地，能緩沖掉絕大部分的壓力，而且還比機房帶寬便宜~
出于性能原因這個一般由js調(diào)用客戶端本地時間，就有可能出現(xiàn)客戶端時鐘與服務(wù)器時鐘不一致，另外服務(wù)器之間也是有可能出現(xiàn)時鐘不一致。 客戶端與服務(wù)器時鐘不一致可以采用客戶端定時和服務(wù)器同步時間 ，這里考慮一下性能問題， 用于同步時間的接口由于不涉及到后端邏輯，只需要將當前web服務(wù)器的時間發(fā)送給客戶端就可以了，因此速度很快 ，就我以前測試的結(jié)果來看，一臺標準的web服務(wù)器2W+QPS不會有問題，如果100W人同時刷，100W QPS也只需要50臺web，一臺硬件LB就可以了~，并且web服務(wù)器群是可以很容易的橫向擴展的(LB+DNS輪詢)，這個接口可以只返回一小段json格式的數(shù)據(jù)，而且可以優(yōu)化一下減少不必要cookie和其他http頭的信息，所以數(shù)據(jù)量不會很大， 一般來說網(wǎng)絡(luò)不會成為瓶頸，即使成為瓶頸也可以考慮多機房專線連通，加智能DNS的解決方案 ；web服務(wù)器之間時間不同步可以采用統(tǒng)一時間服務(wù)器的方式， 比如每隔1分鐘所有參與秒殺活動的web服務(wù)器就與時間服務(wù)器做一次時間同步 。
瀏覽器層請求攔截

（1） 產(chǎn)品層面 ，用戶點擊“查詢”或者“購票”后，按鈕置灰，禁止用戶重復提交請求;
（2） JS層面 ，限制用戶在x秒之內(nèi)只能提交一次請求;
4.2 站點層設(shè)計

前端層的請求攔截，只能攔住小白用戶（不過這是99%的用戶喲），高端的程序員根本不吃這一套，寫個for循環(huán)，直接調(diào)用你后端的http請求，怎么整？
（1） 同一個uid，限制訪問頻度 ，做頁面緩存，x秒內(nèi)到達站點層的請求，均返回同一頁面
（2） 同一個item的查詢，例如手機車次 ，做頁面緩存，x秒內(nèi)到達站點層的請求，均返回同一頁面
如此限流，又有99%的流量會被攔截在站點層。
4.3 服務(wù)層設(shè)計

站點層的請求攔截，只能攔住普通程序員，高級黑客，假設(shè)他控制了10w臺肉雞（并且假設(shè)買票不需要實名認證），這下uid的限制不行了吧？怎么整？
（1）大哥，我是服務(wù)層，我清楚的知道小米只有1萬部手機，我清楚的知道一列火車只有2000張車票，我透10w個請求去數(shù)據(jù)庫有什么意義呢？ 對于寫請求，做請求隊列，每次只透過有限的寫請求去數(shù)據(jù)層，如果均成功再放下一批，如果庫存不夠則隊列里的寫請求全部返回“已售完” ；
（2） 對于讀請求，還用說么？cache來抗 ，不管是memcached還是redis，單機抗個每秒10w應(yīng)該都是沒什么問題的；
如此限流，只有非常少的寫請求，和非常少的讀緩存mis的請求會透到數(shù)據(jù)層去，又有99.9%的請求被攔住了。

經(jīng)過HTTP服務(wù)器的分發(fā)后，單個服務(wù)器的負載相對低了一些，但總量依然可能很大，如果后臺商品已經(jīng)被秒殺完畢，那么直接給后來的請求返回秒殺失敗即可，不必再進一步發(fā)送事務(wù)了，示例代碼可以如下所示：
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接口應(yīng)由數(shù)據(jù)庫服務(wù)器提供，不必完全嚴格檢查.
            if (!RPC.checkReminds()) {
                reminds = false;
            }
        }
        return reminds;
    }
    /**
     * 每一個HTTP請求都要經(jīng)過該預處理.
     */
    public static void preProcess(HttpRequest request) {
        if (checkReminds()) {
            // 一個并發(fā)的隊列
            RequestQueue.queue.add(request);
        } else {
            // 如果已經(jīng)沒有商品了，則直接駁回請求即可.
            forbidden();
        }
    }
}
Java的并發(fā)包提供了三個常用的并發(fā)隊列實現(xiàn)，分別是： ConcurrentLinkedQueue 、 LinkedBlockingQueue 和 ArrayBlockingQueue 。
ArrayBlockingQueue是 初始容量固定的阻塞隊列 ，我們可以用來作為數(shù)據(jù)庫模塊成功競拍的隊列，比如有10個商品，那么我們就設(shè)定一個10大小的數(shù)組隊列。
ConcurrentLinkedQueue使用的是 CAS原語無鎖隊列實現(xiàn)，是一個異步隊列 ，入隊的速度很快，出隊進行了加鎖，性能稍慢。
LinkedBlockingQueue也是 阻塞的隊列，入隊和出隊都用了加鎖 ，當隊空的時候線程會暫時阻塞。
由于我們的系統(tǒng) 入隊需求要遠大于出隊需求 ，一般不會出現(xiàn)隊空的情況，所以我們可以選擇ConcurrentLinkedQueue來作為我們的請求隊列實現(xiàn)：
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 {
    /**
     * 發(fā)送秒殺事務(wù)到數(shù)據(jù)庫隊列.
     */
    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.
    }
}
數(shù)據(jù)庫主要是使用一個ArrayBlockingQueue來暫存有可能成功的用戶請求。
package seckill;
import java.util.concurrent.ArrayBlockingQueue;
/**
* DB應(yīng)該是數(shù)據(jù)庫的唯一接口.
*/
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 = ?
            // 如果數(shù)據(jù)庫商品數(shù)量大約總數(shù)，則標志秒殺已完成，設(shè)置標志位reminds = false.
            info = bids.poll();
        }
    }
}
4.4 數(shù)據(jù)庫設(shè)計

4.3.1 基本概念

概念一“單庫”


(, 下載次數(shù): 14)
概念二“分片”


(, 下載次數(shù): 12)
分片解決的是“數(shù)據(jù)量太大”的問題，也就是通常說的“水平切分”。一旦引入分片，勢必有“數(shù)據(jù)路由”的概念，哪個數(shù)據(jù)訪問哪個庫。路由規(guī)則通常有3種方法：
1. 范圍：range

優(yōu)點：簡單，容易擴展
缺點：各庫壓力不均（新號段更活躍）
2. 哈希：hash

大部分互聯(lián)網(wǎng)公司采用的方案二：哈希分庫，哈希路由

優(yōu)點：簡單，數(shù)據(jù)均衡，負載均勻
缺點：遷移麻煩（2庫擴3庫數(shù)據(jù)要遷移）
3. 路由服務(wù)：router-config-server

優(yōu)點：靈活性強，業(yè)務(wù)與路由算法解耦
缺點：每次訪問數(shù)據(jù)庫前多一次查詢
概念三“分組”


(, 下載次數(shù): 11)
分組解決“可用性”問題，分組通常通過主從復制的方式實現(xiàn)。
互聯(lián)網(wǎng)公司數(shù)據(jù)庫實際軟件架構(gòu)是：又分片，又分組（如下圖）


(, 下載次數(shù): 14)
4.3.2 設(shè)計思路

數(shù)據(jù)庫軟件架構(gòu)師平時設(shè)計些什么東西呢？至少要考慮以下四點：
1. 如何保證數(shù)據(jù)的可用性？

解決可用性問題的思路是=>冗余
如何保證站點的可用性？復制站點，冗余站點
如何保證服務(wù)的可用性？復制服務(wù)，冗余服務(wù)
如何保證數(shù)據(jù)的可用性？復制數(shù)據(jù)，冗余數(shù)據(jù)
數(shù)據(jù)的冗余，會帶來一個副作用=>引發(fā)一致性問題（先不說一致性問題，先說可用性） 。
2. 如何保證數(shù)據(jù)庫“讀”高可用？

冗余讀庫

(, 下載次數(shù): 12)
冗余讀庫帶來的副作用？讀寫有延時，可能不一致
上面這個圖是很多互聯(lián)網(wǎng)公司mysql的架構(gòu)，寫依舊是單點，不能保證寫高可用。
3. 如何保證數(shù)據(jù)庫“寫”高可用？

冗余寫庫

(, 下載次數(shù): 10)
采用雙主互備的方式，可以冗余寫庫帶來的副作用？雙寫同步，數(shù)據(jù)可能沖突（例如“自增id”同步?jīng)_突）,如何解決同步?jīng)_突，有兩種常見解決方案：
實際中沒有使用上述兩種架構(gòu)來做讀寫的“高可用”， 采用的是“雙主當主從用”的方式 ：

(, 下載次數(shù): 13)
仍是雙主，但 只有一個主提供服務(wù)（讀+寫），另一個主是“shadow-master”，只用來保證高可用，平時不提供服務(wù) 。master掛了，shadow-master頂上（vip漂移，對業(yè)務(wù)層透明，不需要人工介入）。這種方式的好處：
不足：
那如何提高讀性能呢？進入第二個話題，如何提供讀性能。
4. 如何擴展讀性能

提高讀性能的方式大致有三種， 第一種是建立索引 。這種方式不展開，要提到的一點是， 不同的庫可以建立不同的索引 。

(, 下載次數(shù): 10)
寫庫不建立索引；
線上讀庫建立線上訪問索引，例如uid；
線下讀庫建立線下訪問索引，例如time；
第二種擴充讀性能的方式是，增加從庫，這種方法大家用的比較多，但是，存在兩個缺點：
實際中沒有采用這種方法提高數(shù)據(jù)庫讀性能（沒有從庫）， 采用的是增加緩存 。常見的緩存架構(gòu)如下：

(, 下載次數(shù): 11)
上游是業(yè)務(wù)應(yīng)用，下游是主庫，從庫（讀寫分離），緩存。

實際的玩法： 服務(wù)+數(shù)據(jù)庫+緩存一套

(, 下載次數(shù): 9)
業(yè)務(wù)層不直接面向db和cache， 服務(wù)層屏蔽了底層db、cache的復雜性 。為什么要引入服務(wù)層，今天不展開，采用了“服務(wù)+數(shù)據(jù)庫+緩存一套”的方式提供數(shù)據(jù)訪問， 用cache提高讀性能 。
不管采用主從的方式擴展讀性能，還是緩存的方式擴展讀性能，數(shù)據(jù)都要復制多份（主+從，db+cache）， 一定會引發(fā)一致性問題 。
5. 如何保證一致性？

主從數(shù)據(jù)庫的一致性，通常有兩種解決方案：
1. 中間件


(, 下載次數(shù): 11)
如果某一個key有寫操作，在不一致時間窗口內(nèi)，中間件會將這個key的讀操作也路由到主庫上。這個方案的缺點是， 數(shù)據(jù)庫中間件的門檻較高 （百度，騰訊，阿里，360等一些公司有）。
2. 強制讀主


(, 下載次數(shù): 12)
上面實際用的“雙主當主從用”的架構(gòu)，不存在主從不一致的問題。

第二類不一致， 是db與緩存間的不一致 ：


常見的緩存架構(gòu)如上，此時 寫操作 的順序是：
（1）淘汰cache；
（2）寫數(shù)據(jù)庫；
讀操作的順序是：
（1）讀cache，如果cache hit則返回；
（2）如果cache miss，則讀從庫；
（3）讀從庫后，將數(shù)據(jù)放回cache；
在一些異常時序情況下，有可能從【從庫讀到舊數(shù)據(jù)（同步還沒有完成），舊數(shù)據(jù)入cache后】，數(shù)據(jù)會長期不一致。 解決辦法是“緩存雙淘汰” ，寫操作時序升級為：
（1）淘汰cache；
（2）寫數(shù)據(jù)庫；
（3）在經(jīng)驗“主從同步延時窗口時間”后，再次發(fā)起一個異步淘汰cache的請求；
這樣，即使有臟數(shù)據(jù)如cache，一個小的時間窗口之后，臟數(shù)據(jù)還是會被淘汰。帶來的代價是，多引入一次讀miss（成本可以忽略）。
除此之外，最佳實踐之一是： 建議為所有cache中的item設(shè)置一個超時時間 。
6. 如何提高數(shù)據(jù)庫的擴展性？

原來用hash的方式路由，分為2個庫，數(shù)據(jù)量還是太大，要分為3個庫，勢必需要進行數(shù)據(jù)遷移，有一個很帥氣的“數(shù)據(jù)庫秒級擴容”方案。
如何秒級擴容？

首先，我們不做2庫變3庫的擴容，我們做2庫變4庫（庫加倍）的擴容（未來4->8->16）


(, 下載次數(shù): 11)
服務(wù)+數(shù)據(jù)庫是一套（省去了緩存）， 數(shù)據(jù)庫采用“雙主”的模式 。
擴容步驟：

第一步，將一個主庫提升;
第二步，修改配置，2庫變4庫（原來MOD2，現(xiàn)在配置修改后MOD4），擴容完成；
原MOD2為偶的部分，現(xiàn)在會MOD4余0或者2；原MOD2為奇的部分，現(xiàn)在會MOD4余1或者3；數(shù)據(jù)不需要遷移，同時，雙主互相同步，一遍是余0，一邊余2，兩邊數(shù)據(jù)同步也不會沖突，秒級完成擴容！
最后，要做一些收尾工作：

(, 下載次數(shù): 11)
這樣，秒級別內(nèi)，我們就完成了2庫變4庫的擴展。
5 大并發(fā)帶來的挑戰(zhàn)

5.1 請求接口的合理設(shè)計

一個秒殺或者搶購頁面，通常分為2個部分，一個是 靜態(tài)的HTML等內(nèi)容 ，另一個就是 參與秒殺的Web后臺請求接口 。
通常靜態(tài)HTML等內(nèi)容，是通過CDN的部署，一般壓力不大，核心瓶頸實際上在后臺請求接口上。這個后端接口，必須能夠支持高并發(fā)請求，同時，非常重要的一點，必須盡可能“快”，在最短的時間里返回用戶的請求結(jié)果。 為了實現(xiàn)盡可能快這一點，接口的后端存儲使用內(nèi)存級別的操作會更好一點 。依舊直接面向MySQL之類的存儲是不合適的， 如果有這種復雜業(yè)務(wù)的需求，都建議采用異步寫入 。

(, 下載次數(shù): 11)
當然，也有一些秒殺和搶購 采用“滯后反饋” ，就是說秒殺當下不知道結(jié)果，一段時間后才可以從頁面中看到用戶是否秒殺成功。但是，這種屬于“偷懶”行為，同時給用戶的體驗也不好，容易被用戶認為是“暗箱操作”。
5.2 高并發(fā)的挑戰(zhàn)：一定要“快”

我們通常衡量一個 Web系統(tǒng)的吞吐率的指標是QPS（Query Per Second，每秒處理請求數(shù)），解決每秒數(shù)萬次的高并發(fā)場景，這個指標非常關(guān)鍵 。舉個例子，我們假設(shè)處理一個業(yè)務(wù)請求平均響應(yīng)時間為100ms，同時，系統(tǒng)內(nèi)有20臺Apache的Web服務(wù)器，配置MaxClients為500個（表示Apache的最大連接數(shù)目）。
那么，我們的Web系統(tǒng)的理論峰值QPS為（理想化的計算方式）：
20*500/0.1 = 100000 （10萬QPS）
咦？我們的系統(tǒng)似乎很強大，1秒鐘可以處理完10萬的請求，5w/s的秒殺似乎是“紙老虎”哈。實際情況，當然沒有這么理想。 在高并發(fā)的實際場景下，機器都處于高負載的狀態(tài)，在這個時候平均響應(yīng)時間會被大大增加 。
就Web服務(wù)器而言，Apache打開了越多的連接進程，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗，然后就直接導致平均響應(yīng)時間增加。因此上述的 MaxClient數(shù)目，要根據(jù)CPU、內(nèi)存等硬件因素綜合考慮，絕對不是越多越好 。可以 通過Apache自帶的abench來測試一下 ，取一個合適的值。然后，我們 選擇內(nèi)存操作級別的存儲的Redis，在高并發(fā)的狀態(tài)下，存儲的響應(yīng)時間至關(guān)重要 。網(wǎng)絡(luò)帶寬雖然也是一個因素，不過，這種請求數(shù)據(jù)包一般比較小，一般很少成為請求的瓶頸。負載均衡成為系統(tǒng)瓶頸的情況比較少，在這里不做討論哈。
那么問題來了，假設(shè)我們的系統(tǒng)，在5w/s的高并發(fā)狀態(tài)下，平均響應(yīng)時間從100ms變?yōu)?50ms（實際情況，甚至更多）：
20*500/0.25 = 40000 （4萬QPS）
于是，我們的系統(tǒng)剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。
然后，這才是真正的惡夢開始。舉個例子，高速路口，1秒鐘來5部車，每秒通過5部車，高速路口運作正常。突然，這個路口1秒鐘只能通過4部車，車流量依舊依舊，結(jié)果必定出現(xiàn)大塞車。（5條車道忽然變成4條車道的感覺）。
同理，某一個秒內(nèi)，20*500個可用連接進程都在滿負荷工作中，卻依舊有1萬個新來請求，沒有連接進程可用，系統(tǒng)陷入到異常狀態(tài)也是預期之內(nèi)。

(, 下載次數(shù): 12)
其實在正常的非高并發(fā)的業(yè)務(wù)場景中，也有類似的情況出現(xiàn)，某個業(yè)務(wù)請求接口出現(xiàn)問題，響應(yīng)時間極慢，將整個Web請求響應(yīng)時間拉得很長，逐漸將Web服務(wù)器的可用連接數(shù)占滿，其他正常的業(yè)務(wù)請求，無連接進程可用。
更可怕的問題是，是用戶的行為特點，系統(tǒng)越是不可用，用戶的點擊越頻繁， 惡性循環(huán)最終導致“雪崩”（其中一臺Web機器掛了，導致流量分散到其他正常工作的機器上，再導致正常的機器也掛，然后惡性循環(huán)） ，將整個Web系統(tǒng)拖垮。
5.3 重啟與過載保護

如果系統(tǒng)發(fā)生“雪崩”，貿(mào)然重啟服務(wù)，是無法解決問題的。最常見的現(xiàn)象是，啟動起來后，立刻掛掉。這個時候， 最好在入口層將流量拒絕，然后再將重啟 。 如果是redis/memcache這種服務(wù)也掛了，重啟的時候需要注意“預熱”，并且很可能需要比較長的時間 。
秒殺和搶購的場景，流量往往是超乎我們系統(tǒng)的準備和想象的。這個時候，過載保護是必要的。 如果檢測到系統(tǒng)滿負載狀態(tài)，拒絕請求也是一種保護措施 。在前端設(shè)置過濾是最簡單的方式，但是，這種做法是被用戶“千夫所指”的行為。更合適一點的是， 將過載保護設(shè)置在CGI入口層，快速將客戶的直接請求返回 。
6 作弊的手段：進攻與防守

秒殺和搶購收到了“海量”的請求，實際上里面的水分是很大的。不少用戶，為了“搶“到商品，會使用“刷票工具”等類型的輔助工具，幫助他們發(fā)送盡可能多的請求到服務(wù)器。還有一部分高級用戶，制作強大的自動請求腳本。 這種做法的理由也很簡單，就是在參與秒殺和搶購的請求中，自己的請求數(shù)目占比越多，成功的概率越高 。
這些都是屬于“作弊的手段”，不過，有“進攻”就有“防守”，這是一場沒有硝煙的戰(zhàn)斗哈。
6.1 同一個賬號，一次性發(fā)出多個請求

部分用戶通過瀏覽器的插件或者其他工具，在秒殺開始的時間里， 以自己的賬號，一次發(fā)送上百甚至更多的請求 。實際上，這樣的用戶破壞了秒殺和搶購的公平性。
這種請求在某些沒有做數(shù)據(jù)安全處理的系統(tǒng)里，也可能造成另外一種破壞，導致某些判斷條件被繞過。例如一個簡單的領(lǐng)取邏輯，先判斷用戶是否有參與記錄，如果沒有則領(lǐng)取成功，最后寫入到參與記錄中。這是個非常簡單的邏輯，但是，在高并發(fā)的場景下，存在深深的漏洞。 多個并發(fā)請求通過負載均衡服務(wù)器，分配到內(nèi)網(wǎng)的多臺Web服務(wù)器，它們首先向存儲發(fā)送查詢請求，然后，在某個請求成功寫入?yún)⑴c記錄的時間差內(nèi)，其他的請求獲查詢到的結(jié)果都是“沒有參與記錄” 。這里，就存在邏輯判斷被繞過的風險。

(, 下載次數(shù): 9)
應(yīng)對方案：

在程序入口處，一個賬號只允許接受1個請求，其他請求過濾。不僅解決了同一個賬號，發(fā)送N個請求的問題，還保證了后續(xù)的邏輯流程的安全。 實現(xiàn)方案，可以通過Redis這種內(nèi)存緩存服務(wù)，寫入一個標志位（只允許1個請求寫成功，結(jié)合watch的樂觀鎖的特性），成功寫入的則可以繼續(xù)參加 。

(, 下載次數(shù): 14)
或者，自己實現(xiàn)一個服務(wù)，將同一個賬號的請求放入一個隊列中，處理完一個，再處理下一個。
6.2 多個賬號，一次性發(fā)送多個請求

很多公司的賬號注冊功能，在發(fā)展早期幾乎是沒有限制的，很容易就可以注冊很多個賬號。因此， 也導致了出現(xiàn)了一些特殊的工作室，通過編寫自動注冊腳本，積累了一大批“僵尸賬號”，數(shù)量龐大，幾萬甚至幾十萬的賬號不等，專門做各種刷的行為（這就是微博中的“僵尸粉“的來源） 。舉個例子，例如微博中有轉(zhuǎn)發(fā)抽獎的活動，如果我們使用幾萬個“僵尸號”去混進去轉(zhuǎn)發(fā)，這樣就可以大大提升我們中獎的概率。
這種賬號，使用在秒殺和搶購里，也是同一個道理。例如，iPhone官網(wǎng)的搶購，火車票黃牛黨。

(, 下載次數(shù): 10)
應(yīng)對方案：

這種場景，可以 通過檢測指定機器IP請求頻率就可以解決，如果發(fā)現(xiàn)某個IP請求頻率很高，可以給它彈出一個驗證碼或者直接禁止它的請求 ：
6.3 多個賬號，不同IP發(fā)送不同請求

所謂道高一尺，魔高一丈。有進攻，就會有防守，永不休止。 這些“工作室”，發(fā)現(xiàn)你對單機IP請求頻率有控制之后，他們也針對這種場景，想出了他們的“新進攻方案”，就是不斷改變IP 。

(, 下載次數(shù): 10)
有同學會好奇，這些隨機IP服務(wù)怎么來的。 有一些是某些機構(gòu)自己占據(jù)一批獨立IP，然后做成一個隨機代理IP的服務(wù)，有償提供給這些“工作室”使用 。還有一些更為黑暗一點的，就是 通過木馬黑掉普通用戶的電腦，這個木馬也不破壞用戶電腦的正常運作，只做一件事情，就是轉(zhuǎn)發(fā)IP包，普通用戶的電腦被變成了IP代理出口 。通過這種做法，黑客就拿到了大量的獨立IP，然后搭建為隨機IP服務(wù)，就是為了掙錢。
應(yīng)對方案：

說實話，這種場景下的請求，和真實用戶的行為，已經(jīng)基本相同了，想做分辨很困難。再做進一步的限制很容易“誤傷“真實用戶，這個時候， 通常只能通過設(shè)置業(yè)務(wù)門檻高來限制這種請求了，或者通過賬號行為的”數(shù)據(jù)挖掘“來提前清理掉它們 。
僵尸賬號也還是有一些共同特征的，例如 賬號很可能屬于同一個號碼段甚至是連號的，活躍度不高，等級低，資料不全等等 。根據(jù)這些特點，適當設(shè)置參與門檻，例如限制參與秒殺的賬號等級。 通過這些業(yè)務(wù)手段，也是可以過濾掉一些僵尸號 。
7 高并發(fā)下的數(shù)據(jù)安全

我們知道在 多線程寫入同一個文件的時候，會存現(xiàn)“線程安全”的問題 （多個線程同時運行同一段代碼，如果每次運行結(jié)果和單線程運行的結(jié)果是一樣的，結(jié)果和預期相同，就是線程安全的）。 如果是MySQL數(shù)據(jù)庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規(guī)模并發(fā)的場景中，是不推薦使用MySQL的 。秒殺和搶購的場景中，還有另外一個問題，就是“超發(fā)”，如果在這方面控制不慎，會產(chǎn)生發(fā)送過多的情況。我們也曾經(jīng)聽說過，某些電商搞搶購活動，買家成功拍下后，商家卻不承認訂單有效，拒絕發(fā)貨。這里的問題，也許并不一定是商家奸詐，而是系統(tǒng)技術(shù)層面存在超發(fā)風險導致的。
7.1 超發(fā)的原因

假設(shè)某個搶購場景中，我們一共只有100個商品，在最后一刻，我們已經(jīng)消耗了99個商品，僅剩最后一個。這個時候，系統(tǒng)發(fā)來多個并發(fā)請求，這批請求讀取到的商品余量都是99個，然后都通過了這一個余量判斷，最終導致超發(fā)。

(, 下載次數(shù): 11)
在上面的這個圖中，就導致了并發(fā)用戶B也“搶購成功”，多讓一個人獲得了商品。這種場景，在高并發(fā)的情況下非常容易出現(xiàn)。
7.2 悲觀鎖思路

解決線程安全的思路很多，可以從“悲觀鎖”的方向開始討論。
悲觀鎖，也就是在修改數(shù)據(jù)的時候，采用鎖定狀態(tài)，排斥外部請求的修改。遇到加鎖的狀態(tài)，就必須等待。

(, 下載次數(shù): 14)
雖然上述的方案的確解決了線程安全的問題，但是，別忘記， 我們的場景是“高并發(fā)”。也就是說，會很多這樣的修改請求，每個請求都需要等待“鎖”，某些線程可能永遠都沒有機會搶到這個“鎖”，這種請求就會死在那里 。同時，這種請求會很多， 瞬間增大系統(tǒng)的平均響應(yīng)時間，結(jié)果是可用連接數(shù)被耗盡，系統(tǒng)陷入異常 。
7.3 FIFO隊列思路

那好，那么我們稍微修改一下上面的場景， 我們直接將請求放入隊列中的，采用FIFO（First Input First Output，先進先出），這樣的話，我們就不會導致某些請求永遠獲取不到鎖 。看到這里，是不是有點強行將多線程變成單線程的感覺哈。

(, 下載次數(shù): 11)
然后，我們現(xiàn)在解決了鎖的問題，全部請求采用“先進先出”的隊列方式來處理。那么新的問題來了， 高并發(fā)的場景下，因為請求很多，很可能一瞬間將隊列內(nèi)存“撐爆”，然后系統(tǒng)又陷入到了異常狀態(tài) ?；蛘咴O(shè)計一個極大的內(nèi)存隊列，也是一種方案，但是，系統(tǒng)處理完一個隊列內(nèi)請求的速度根本無法和瘋狂涌入隊列中的數(shù)目相比。也就是說，隊列內(nèi)的請求會越積累越多，最終Web系統(tǒng)平均響應(yīng)時候還是會大幅下降，系統(tǒng)還是陷入異常。
7.4 樂觀鎖思路

這個時候，我們就可以討論一下“樂觀鎖”的思路了。 樂觀鎖，是相對于“悲觀鎖”采用更為寬松的加鎖機制，大都是采用帶版本號（Version）更新。實現(xiàn)就是，這個數(shù)據(jù)所有請求都有資格去修改，但會獲得一個該數(shù)據(jù)的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗 。這樣的話，我們就不需要考慮隊列的問題，不過， 它會增大CPU的計算開銷 。但是，綜合來說，這是一個比較好的解決方案。

(, 下載次數(shù): 11)
有很多軟件和服務(wù)都“樂觀鎖”功能的支持，例如 Redis中的watch就是其中之一 。通過這個實現(xiàn)，我們保證了數(shù)據(jù)的安全。
8 總結(jié)

互聯(lián)網(wǎng)正在高速發(fā)展，使用互聯(lián)網(wǎng)服務(wù)的用戶越多，高并發(fā)的場景也變得越來越多。電商秒殺和搶購，是兩個比較典型的互聯(lián)網(wǎng)高并發(fā)場景。雖然我們解決問題的具體技術(shù)方案可能千差萬別，但是遇到的挑戰(zhàn)卻是相似的， 因此解決問題的思路也異曲同工 。

-----------------------------



歡迎光臨 愛鋒貝 (http://m.7gfy2te7.cn/) Powered by Discuz! X3.4