摘要：一為什么難秒殺系統(tǒng)難做的原因庫(kù)存只有一份，所有人會(huì)在集中的時(shí)間讀和寫這些數(shù)據(jù)。又例如搶票，亦與秒殺類似，瞬時(shí)流量更甚。

????秒殺系統(tǒng)難做的原因：庫(kù)存只有一份，所有人會(huì)在集中的時(shí)間讀和寫這些數(shù)據(jù)。例如小米手機(jī)每周二的秒殺，可能手機(jī)只有1萬(wàn)部，但瞬時(shí)進(jìn)入的流量可能是幾百幾千萬(wàn)。又例如12306搶票，亦與秒殺類似，瞬時(shí)流量更甚。

主要需要解決的問題有兩個(gè)：

高并發(fā)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生的壓力

競(jìng)爭(zhēng)狀態(tài)下如何解決庫(kù)存的正確減少（超賣問題）

????對(duì)于第一個(gè)問題，已經(jīng)很容易想到用緩存來(lái)處理?yè)屬?gòu)，避免直接操作數(shù)據(jù)庫(kù)，例如使用Redis。重點(diǎn)在于第二個(gè)問題，常規(guī)寫法：
????查詢出對(duì)應(yīng)商品的庫(kù)存，看是否大于0，然后執(zhí)行生成訂單等操作，但是在判斷庫(kù)存是否大于0處，如果在高并發(fā)下就會(huì)有問題，導(dǎo)致庫(kù)存量出現(xiàn)負(fù)數(shù)

流量到了億級(jí)別，常見站點(diǎn)架構(gòu)如上：

瀏覽器端，最上層，會(huì)執(zhí)行到一些JS代碼

站點(diǎn)層，這一層會(huì)訪問后端數(shù)據(jù)，拼html頁(yè)面返回給瀏覽器

服務(wù)層，向上游屏蔽底層數(shù)據(jù)細(xì)節(jié)

數(shù)據(jù)層，最終的庫(kù)存是存在這里的，mysql是一個(gè)典型

1）將請(qǐng)求盡量攔截在系統(tǒng)上游：傳統(tǒng)秒殺系統(tǒng)之所以掛，請(qǐng)求都?jí)旱沽撕蠖藬?shù)據(jù)層，數(shù)據(jù)讀寫鎖沖突嚴(yán)重，并發(fā)高響應(yīng)慢，幾乎所有請(qǐng)求都超時(shí)，流量雖大，下單成功的有效流量甚小【一趟火車其實(shí)只有2000張票，200w個(gè)人來(lái)買，基本沒有人能買成功，請(qǐng)求有效率為0】
2）充分利用緩存：這是一個(gè)典型的讀多寫少的應(yīng)用場(chǎng)景【一趟火車其實(shí)只有2000張票，200w個(gè)人來(lái)買，最多2000個(gè)人下單成功，其他人都是查詢庫(kù)存，寫比例只有0.1%，讀比例占99.9%】，非常適合使用緩存。

4.1）瀏覽器層請(qǐng)求攔截

點(diǎn)擊了“查詢”按鈕之后，系統(tǒng)那個(gè)卡呀，進(jìn)度條漲的慢呀，作為用戶，我會(huì)不自覺的再去點(diǎn)擊“查詢”，繼續(xù)點(diǎn)，繼續(xù)點(diǎn)，點(diǎn)點(diǎn)點(diǎn)。。。有用么？平白無(wú)故的增加了系統(tǒng)負(fù)載（一個(gè)用戶點(diǎn)5次，80%的請(qǐng)求是這么多出來(lái)的），怎么整？

a 產(chǎn)品層面，用戶點(diǎn)擊“查詢”或者“購(gòu)票”后，按鈕置灰，禁止用戶重復(fù)提交請(qǐng)求
b JS層面，限制用戶在x秒之內(nèi)只能提交一次請(qǐng)求

如此限流，80%流量已攔。

4.2）站點(diǎn)層請(qǐng)求攔截與頁(yè)面緩存

瀏覽器層的請(qǐng)求攔截，只能攔住小白用戶（不過這是99%的用戶喲），高端的程序員根本不吃這一套，寫個(gè)for循環(huán)，直接調(diào)用你后端的http請(qǐng)求，怎么整？

a 同一個(gè)uid，限制訪問頻度，做頁(yè)面緩存，x秒內(nèi)到達(dá)站點(diǎn)層的請(qǐng)求，均返回同一頁(yè)面
b 同一個(gè)item的查詢，例如手機(jī)車次，做頁(yè)面緩存，x秒內(nèi)到達(dá)站點(diǎn)層的請(qǐng)求，均返回同一頁(yè)面

如此限流，又有99%的流量會(huì)被攔截在站點(diǎn)層

4.3）服務(wù)層請(qǐng)求攔截與數(shù)據(jù)緩存
站點(diǎn)層的請(qǐng)求攔截，只能攔住普通程序員，高級(jí)黑客，假設(shè)他控制了10w臺(tái)肉雞（并且假設(shè)買票不需要實(shí)名認(rèn)證），這下uid的限制不行了吧？怎么整？

a 大哥，我是服務(wù)層，我清楚的知道小米只有1萬(wàn)部手機(jī)，我清楚的知道一列火車只有2000張車票，我透10w個(gè)請(qǐng)求去數(shù)據(jù)庫(kù)有什么意義呢？對(duì)于寫請(qǐng)求，做請(qǐng)求隊(duì)列，每次只透有限的寫請(qǐng)求去數(shù)據(jù)層，如果均成功再放下一批，如果庫(kù)存不夠則隊(duì)列里的寫請(qǐng)求全部返回“已售完”

b 對(duì)于讀請(qǐng)求，還要我說么？cache抗，不管是memcached還是redis，單機(jī)抗個(gè)每秒10w應(yīng)該都是沒什么問題的

如此限流，只有非常少的寫請(qǐng)求，和非常少的讀緩存mis的請(qǐng)求會(huì)透到數(shù)據(jù)層去，又有99.9%的請(qǐng)求被攔住了

4.4）數(shù)據(jù)層閑庭信步
到了數(shù)據(jù)這一層，幾乎就沒有什么請(qǐng)求了，單機(jī)也能扛得住，還是那句話，庫(kù)存是有限的，小米的產(chǎn)能有限，透這么多請(qǐng)求來(lái)數(shù)據(jù)庫(kù)沒有意義。

4.5）mysql批量入庫(kù)提高INSERT效率

????使用redis隊(duì)列（list），push和pop操作保證了原子性的實(shí)現(xiàn)。即使有很多用戶同時(shí)到達(dá)，也是依次執(zhí)行。（mysql事務(wù)在高并發(fā)下性能下降很厲害）

先將商品庫(kù)存存入隊(duì)列：

connect("127.0.0.1",6379);  
$res=$redis->llen("goods_store");   

for($i=0; $i<$store; $i++){  
    $redis->lpush("goods_store",1);  
}  
echo $redis->llen("goods_store");  
?> 

客戶執(zhí)行下單操作：

$redis=new Redis();  
$result=$redis->connect("127.0.0.1",6379);
$count = $redis->lpop("goods_store");
if(!$count){
    echo "搶購(gòu)失??！";
    return;
}    

????緩存也是可以應(yīng)對(duì)寫請(qǐng)求的，比如我們就可以把數(shù)據(jù)庫(kù)中的庫(kù)存數(shù)據(jù)轉(zhuǎn)移到Redis緩存中，所有減庫(kù)存操作都在Redis中進(jìn)行，然后再通過后臺(tái)進(jìn)程把Redis中的用戶秒殺請(qǐng)求同步到數(shù)據(jù)庫(kù)中

沒什么總結(jié)了，上文應(yīng)該描述的非常清楚了，對(duì)于秒殺系統(tǒng)，再次重復(fù)下兩個(gè)架構(gòu)優(yōu)化思路：
1）盡量將請(qǐng)求攔截在系統(tǒng)上游
2）讀多寫少經(jīng)量多使用緩存
3) redis隊(duì)列緩存 + mysql 批量入庫(kù)

參考文檔1：秒殺系統(tǒng)架構(gòu)優(yōu)化思路
參考文檔2：【高并發(fā)簡(jiǎn)單解決方案】redis隊(duì)列緩存 + mysql 批量入庫(kù) + php離線整合
參考文檔3：PHP+Mysql高并發(fā)解決
參考文檔4：php結(jié)合redis實(shí)現(xiàn)高并發(fā)下的搶購(gòu)、秒殺功能