1 秒殺業(yè)務(wù)分析#

1. 正常電子商務(wù)流程

（1）查詢商品嚼锄；
（2）創(chuàng)建訂單减拭；
（3）扣減庫存；
（4）更新訂單区丑；
（5）付款拧粪；
（6）賣家發(fā)貨；

2. 秒殺業(yè)務(wù)的特性

（1）低廉價(jià)格沧侥；
（2）大幅推廣可霎；
（3）瞬時(shí)售空；
（4）一般是定時(shí)上架宴杀；
（5）時(shí)間短癣朗、瞬時(shí)并發(fā)量高；

2 秒殺技術(shù)挑戰(zhàn)#

假設(shè)某網(wǎng)站秒殺活動(dòng)只推出一件商品旺罢，預(yù)計(jì)會(huì)吸引1萬人參加活動(dòng)旷余，也就說最大并發(fā)請(qǐng)求數(shù)是10000，秒殺系統(tǒng)需要面對(duì)的技術(shù)挑戰(zhàn)有：

1. 對(duì)現(xiàn)有網(wǎng)站業(yè)務(wù)造成沖擊

秒殺活動(dòng)只是網(wǎng)站營銷的一個(gè)附加活動(dòng)扁达，這個(gè)活動(dòng)具有時(shí)間短正卧，并發(fā)訪問量大的特點(diǎn)，如果和網(wǎng)站原有應(yīng)用部署在一起罩驻，必然會(huì)對(duì)現(xiàn)有業(yè)務(wù)造成沖擊穗酥，稍有不慎可能導(dǎo)致整個(gè)網(wǎng)站癱瘓。

解決方案：將秒殺系統(tǒng)獨(dú)立部署，甚至使用獨(dú)立域名砾跃，使其與網(wǎng)站完全隔離骏啰。

2. 高并發(fā)下的應(yīng)用、數(shù)據(jù)庫負(fù)載

用戶在秒殺開始前抽高，通過不停刷新瀏覽器頁面以保證不會(huì)錯(cuò)過秒殺判耕，這些請(qǐng)求如果按照一般的網(wǎng)站應(yīng)用架構(gòu)，訪問應(yīng)用服務(wù)器翘骂、連接數(shù)據(jù)庫壁熄，會(huì)對(duì)應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器造成負(fù)載壓力。

解決方案：重新設(shè)計(jì)秒殺商品頁面碳竟，不使用網(wǎng)站原來的商品詳細(xì)頁面草丧，頁面內(nèi)容靜態(tài)化，用戶請(qǐng)求不需要經(jīng)過應(yīng)用服務(wù)莹桅。

3. 突然增加的網(wǎng)絡(luò)及服務(wù)器帶寬

假設(shè)商品頁面大小200K（主要是商品圖片大胁础），那么需要的網(wǎng)絡(luò)和服務(wù)器帶寬是2G（200K×10000）诈泼，這些網(wǎng)絡(luò)帶寬是因?yàn)槊霘⒒顒?dòng)新增的懂拾，超過網(wǎng)站平時(shí)使用的帶寬。

解決方案：因?yàn)槊霘⑿略龅木W(wǎng)絡(luò)帶寬铐达，必須和運(yùn)營商重新購買或者租借岖赋。為了減輕網(wǎng)站服務(wù)器的壓力，需要將秒殺商品頁面緩存在CDN瓮孙，同樣需要和CDN服務(wù)商臨時(shí)租借新增的出口帶寬唐断。

4. 直接下單

秒殺的游戲規(guī)則是到了秒殺才能開始對(duì)商品下單購買，在此時(shí)間點(diǎn)之前杭抠，只能瀏覽商品信息栗涂，不能下單。而下單頁面也是一個(gè)普通的URL祈争，如果得到這個(gè)URL，不用等到秒殺開始就可以下單了角寸。

解決方案：為了避免用戶直接訪問下單頁面URL菩混，需要將改URL動(dòng)態(tài)化，即使秒殺系統(tǒng)的開發(fā)者也無法在秒殺開始前訪問下單頁面的URL扁藕。辦法是在下單頁面URL加入由服務(wù)器端生成的隨機(jī)數(shù)作為參數(shù)沮峡，在秒殺開始的時(shí)候才能得到。

5. 如何控制秒殺商品頁面購買按鈕的點(diǎn)亮

購買按鈕只有在秒殺開始的時(shí)候才能點(diǎn)亮亿柑，在此之前是灰色的邢疙。如果該頁面是動(dòng)態(tài)生成的，當(dāng)然可以在服務(wù)器端構(gòu)造響應(yīng)頁面輸出，控制該按鈕是灰色還是點(diǎn)亮疟游，但是為了減輕服務(wù)器端負(fù)載壓力呼畸，更好地利用CDN、反向代理等性能優(yōu)化手段颁虐，該頁面被設(shè)計(jì)為靜態(tài)頁面蛮原，緩存在CDN、反向代理服務(wù)器上另绩，甚至用戶瀏覽器上儒陨。秒殺開始時(shí)，用戶刷新頁面笋籽，請(qǐng)求根本不會(huì)到達(dá)應(yīng)用服務(wù)器蹦漠。

解決方案：使用JavaScript腳本控制，在秒殺商品靜態(tài)頁面中加入一個(gè)JavaScript文件引用车海，該JavaScript文件中包含秒殺開始標(biāo)志為否笛园；當(dāng)秒殺開始的時(shí)候生成一個(gè)新的JavaScript文件（文件名保持不變，只是內(nèi)容不一樣）容劳，更新秒殺開始標(biāo)志為是喘沿，加入下單頁面的URL及隨機(jī)數(shù)參數(shù)（這個(gè)隨機(jī)數(shù)只會(huì)產(chǎn)生一個(gè)，即所有人看到的URL都是同一個(gè)竭贩，服務(wù)器端可以用redis這種分布式緩存服務(wù)器來保存隨機(jī)數(shù)）蚜印，并被用戶瀏覽器加載，控制秒殺商品頁面的展示留量。這個(gè)JavaScript文件的加載可以加上隨機(jī)版本號(hào)（例如xx.js?v=32353823）窄赋，這樣就不會(huì)被瀏覽器、CDN和反向代理服務(wù)器緩存楼熄。

這個(gè)JavaScript文件非常小忆绰，即使每次瀏覽器刷新都訪問JavaScript文件服務(wù)器也不會(huì)對(duì)服務(wù)器集群和網(wǎng)絡(luò)帶寬造成太大壓力。

6. 如何只允許第一個(gè)提交的訂單被發(fā)送到訂單子系統(tǒng)

由于最終能夠成功秒殺到商品的用戶只有一個(gè)可岂，因此需要在用戶提交訂單時(shí)错敢，檢查是否已經(jīng)有訂單提交。如果已經(jīng)有訂單提交成功缕粹，則需要更新 JavaScript文件稚茅，更新秒殺開始標(biāo)志為否，購買按鈕變灰平斩。事實(shí)上亚享，由于最終能夠成功提交訂單的用戶只有一個(gè)，為了減輕下單頁面服務(wù)器的負(fù)載壓力绘面，可以控制進(jìn)入下單頁面的入口欺税，只有少數(shù)用戶能進(jìn)入下單頁面侈沪，其他用戶直接進(jìn)入秒殺結(jié)束頁面。

解決方案：假設(shè)下單服務(wù)器集群有10臺(tái)服務(wù)器晚凿，每臺(tái)服務(wù)器只接受最多10個(gè)下單請(qǐng)求亭罪。在還沒有人提交訂單成功之前，如果一臺(tái)服務(wù)器已經(jīng)有十單了晃虫，而有的一單都沒處理皆撩，可能出現(xiàn)的用戶體驗(yàn)不佳的場(chǎng)景是用戶第一次點(diǎn)擊購買按鈕進(jìn)入已結(jié)束頁面，再刷新一下頁面哲银，有可能被一單都沒有處理的服務(wù)器處理扛吞，進(jìn)入了填寫訂單的頁面，可以考慮通過cookie的方式來應(yīng)對(duì)荆责，符合一致性原則滥比。當(dāng)然可以采用最少連接的負(fù)載均衡算法，出現(xiàn)上述情況的概率大大降低做院。

7. 如何進(jìn)行下單前置檢查

• 下單服務(wù)器檢查本機(jī)已處理的下單請(qǐng)求數(shù)目：

  如果超過10條盲泛，直接返回已結(jié)束頁面給用戶；

  如果未超過10條键耕，則用戶可進(jìn)入填寫訂單及確認(rèn)頁面寺滚；

• 檢查全局已提交訂單數(shù)目：

  已超過秒殺商品總數(shù)，返回已結(jié)束頁面給用戶屈雄；

  未超過秒殺商品總數(shù)村视，提交到子訂單系統(tǒng)；

8. 秒殺一般是定時(shí)上架

該功能實(shí)現(xiàn)方式很多酒奶。不過目前比較好的方式是：提前設(shè)定好商品的上架時(shí)間蚁孔，用戶可以在前臺(tái)看到該商品，但是無法點(diǎn)擊“立即購買”的按鈕惋嚎。但是需要考慮的是杠氢，有人可以繞過前端的限制，直接通過URL的方式發(fā)起購買另伍，這就需要在前臺(tái)商品頁面鼻百，以及bug頁面到后端的數(shù)據(jù)庫，都要進(jìn)行時(shí)鐘同步摆尝。越在后端控制愕宋，安全性越高。

定時(shí)秒殺的話结榄，就要避免賣家在秒殺前對(duì)商品做編輯帶來的不可預(yù)期的影響。這種特殊的變更需要多方面評(píng)估囤捻。一般禁止編輯臼朗，如需變更，可以走數(shù)據(jù)訂正的流程。

9. 減庫存的操作

有兩種選擇视哑，一種是拍下減庫存 另外一種是付款減庫存绣否；目前采用的“拍下減庫存”的方式，拍下就是一瞬間的事挡毅，對(duì)用戶體驗(yàn)會(huì)好些蒜撮。

10. 庫存會(huì)帶來“超賣”的問題：售出數(shù)量多于庫存數(shù)量

由于庫存并發(fā)更新的問題，導(dǎo)致在實(shí)際庫存已經(jīng)不足的情況下跪呈，庫存依然在減段磨，導(dǎo)致賣家的商品賣得件數(shù)超過秒殺的預(yù)期。方案：采用樂觀鎖

update auction_auctions set
quantity = #inQuantity#
where auction_id = #itemId# and quantity = #dbQuantity#

還有一種方式耗绿，會(huì)更好些苹支，叫做嘗試扣減庫存，扣減庫存成功才會(huì)進(jìn)行下單邏輯：

update auction_auctions set 
quantity = quantity-#count# 
where auction_id = #itemId# and quantity >= #count# 

11. 秒殺器的應(yīng)對(duì)

秒殺器一般下單個(gè)購買及其迅速误阻，根據(jù)購買記錄可以甄別出一部分债蜜。可以通過校驗(yàn)碼達(dá)到一定的方法究反，這就要求校驗(yàn)碼足夠安全寻定，不被破解，采用的方式有：秒殺專用驗(yàn)證碼精耐，電視公布驗(yàn)證碼狼速，秒殺答題。

3 秒殺架構(gòu)原則#

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è)人來買舶掖，基本沒有人能買成功镊屎，請(qǐng)求有效率為0】。

2. 讀多寫少的常用多使用緩存

這是一個(gè)典型的讀多寫少的應(yīng)用場(chǎng)景【一趟火車其實(shí)只有2000張票，200w個(gè)人來買丐箩，最多2000個(gè)人下單成功，其他人都是查詢庫存将饺，寫比例只有0.1%矢渊，讀比例占99.9%】，非常適合使用緩存躬审。

4 秒殺架構(gòu)設(shè)計(jì)#

秒殺系統(tǒng)為秒殺而設(shè)計(jì)棘街，不同于一般的網(wǎng)購行為蟆盐，參與秒殺活動(dòng)的用戶更關(guān)心的是如何能快速刷新商品頁面，在秒殺開始的時(shí)候搶先進(jìn)入下單頁面遭殉，而不是商品詳情等用戶體驗(yàn)細(xì)節(jié)石挂，因此秒殺系統(tǒng)的頁面設(shè)計(jì)應(yīng)盡可能簡(jiǎn)單。

商品頁面中的購買按鈕只有在秒殺活動(dòng)開始的時(shí)候才變亮险污，在此之前及秒殺商品賣出后痹愚，該按鈕都是灰色的，不可以點(diǎn)擊蛔糯。

下單表單也盡可能簡(jiǎn)單拯腮，購買數(shù)量只能是一個(gè)且不可以修改，送貨地址和付款方式都使用用戶默認(rèn)設(shè)置渤闷，沒有默認(rèn)也可以不填疾瓮，允許等訂單提交后修改；只有第一個(gè)提交的訂單發(fā)送給網(wǎng)站的訂單子系統(tǒng)飒箭，其余用戶提交訂單后只能看到秒殺結(jié)束頁面狼电。

要做一個(gè)這樣的秒殺系統(tǒng)，業(yè)務(wù)會(huì)分為兩個(gè)階段：

第一個(gè)階段是秒殺開始前某個(gè)時(shí)間到秒殺開始弦蹂， 這個(gè)階段可以稱之為準(zhǔn)備階段肩碟，用戶在準(zhǔn)備階段等待秒殺；

第二個(gè)階段就是秒殺開始到所有參與秒殺的用戶獲得秒殺結(jié)果凸椿， 這個(gè)就稱為秒殺階段吧削祈。

4.1 前端層設(shè)計(jì)##

首先要有一個(gè)展示秒殺商品的頁面，在這個(gè)頁面上做一個(gè)秒殺活動(dòng)開始的倒計(jì)時(shí)脑漫，在準(zhǔn)備階段內(nèi)用戶會(huì)陸續(xù)打開這個(gè)秒殺的頁面髓抑， 并且可能不停的刷新頁面。這里需要考慮兩個(gè)問題：

1. 第一個(gè)是秒殺頁面的展示

我們知道一個(gè)html頁面還是比較大的优幸，即使做了壓縮吨拍，http頭和內(nèi)容的大小也可能高達(dá)數(shù)十K，加上其他的css网杆， js羹饰，圖片等資源，如果同時(shí)有幾千萬人參與一個(gè)商品的搶購碳却，一般機(jī)房帶寬也就只有1G_{10G队秩，**網(wǎng)絡(luò)帶寬就極有可能成為瓶頸**，所以這個(gè)頁面上**各類靜態(tài)資源首先應(yīng)分開存放昼浦，然后放到cdn節(jié)點(diǎn)上分散壓力**馍资，由于CDN節(jié)點(diǎn)遍布全國各地，能緩沖掉絕大部分的壓力关噪，而且還比機(jī)房帶寬便宜}

2. 第二個(gè)是倒計(jì)時(shí)

出于性能原因這個(gè)一般由js調(diào)用客戶端本地時(shí)間鸟蟹，就有可能出現(xiàn)客戶端時(shí)鐘與服務(wù)器時(shí)鐘不一致物舒，另外服務(wù)器之間也是有可能出現(xiàn)時(shí)鐘不一致。客戶端與服務(wù)器時(shí)鐘不一致可以采用客戶端定時(shí)和服務(wù)器同步時(shí)間戏锹，這里考慮一下性能問題，用于同步時(shí)間的接口由于不涉及到后端邏輯火诸，只需要將當(dāng)前web服務(wù)器的時(shí)間發(fā)送給客戶端就可以了锦针，因此速度很快，就我以前測(cè)試的結(jié)果來看置蜀，一臺(tái)標(biāo)準(zhǔn)的web服務(wù)器2W+QPS不會(huì)有問題奈搜，如果100W人同時(shí)刷，100W QPS也只需要50臺(tái)web盯荤，一臺(tái)硬件LB就可以了~馋吗，并且web服務(wù)器群是可以很容易的橫向擴(kuò)展的(LB+DNS輪詢)，這個(gè)接口可以只返回一小段json格式的數(shù)據(jù)秋秤，而且可以優(yōu)化一下減少不必要cookie和其他http頭的信息宏粤，所以數(shù)據(jù)量不會(huì)很大，一般來說網(wǎng)絡(luò)不會(huì)成為瓶頸灼卢，即使成為瓶頸也可以考慮多機(jī)房專線連通绍哎，加智能DNS的解決方案；web服務(wù)器之間時(shí)間不同步可以采用統(tǒng)一時(shí)間服務(wù)器的方式鞋真，比如每隔1分鐘所有參與秒殺活動(dòng)的web服務(wù)器就與時(shí)間服務(wù)器做一次時(shí)間同步崇堰。

3. 瀏覽器層請(qǐng)求攔截

（1）產(chǎn)品層面，用戶點(diǎn)擊“查詢”或者“購票”后涩咖，按鈕置灰海诲，禁止用戶重復(fù)提交請(qǐng)求;

（2）JS層面，限制用戶在x秒之內(nèi)只能提交一次請(qǐng)求;

4.2 站點(diǎn)層設(shè)計(jì)##

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

（1）同一個(gè)uid零院，限制訪問頻度溉跃，做頁面緩存，x秒內(nèi)到達(dá)站點(diǎn)層的請(qǐng)求告抄，均返回同一頁面

（2）同一個(gè)item的查詢撰茎，例如手機(jī)車次，做頁面緩存打洼，x秒內(nèi)到達(dá)站點(diǎn)層的請(qǐng)求龄糊，均返回同一頁面

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

4.3 服務(wù)層設(shè)計(jì)##

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

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

（2）對(duì)于讀請(qǐng)求两蟀，還用說么？cache來抗震缭，不管是memcached還是redis赂毯，單機(jī)抗個(gè)每秒10w應(yīng)該都是沒什么問題的；

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

1. 用戶請(qǐng)求分發(fā)模塊：使用Nginx或Apache將用戶的請(qǐng)求分發(fā)到不同的機(jī)器上膛堤。

2. 用戶請(qǐng)求預(yù)處理模塊：判斷商品是不是還有剩余來決定是不是要處理該請(qǐng)求。

3. 用戶請(qǐng)求處理模塊：把通過預(yù)處理的請(qǐng)求封裝成事務(wù)提交給數(shù)據(jù)庫晌该，并返回是否成功肥荔。

4. 數(shù)據(jù)庫接口模塊：該模塊是數(shù)據(jù)庫的唯一接口，負(fù)責(zé)與數(shù)據(jù)庫交互朝群，提供RPC接口供查詢是否秒殺結(jié)束燕耿、剩余數(shù)量等信息。

1. 用戶請(qǐng)求預(yù)處理模塊

經(jīng)過HTTP服務(wù)器的分發(fā)后姜胖，單個(gè)服務(wù)器的負(fù)載相對(duì)低了一些誉帅，但總量依然可能很大，如果后臺(tái)商品已經(jīng)被秒殺完畢，那么直接給后來的請(qǐng)求返回秒殺失敗即可蚜锨，不必再進(jìn)一步發(fā)送事務(wù)了档插，示例代碼可以如下所示：

package seckill;
import org.apache.http.HttpRequest;
/**
    * 預(yù)處理階段，把不必要的請(qǐng)求直接駁回亚再，必要的請(qǐng)求添加到隊(duì)列中進(jìn)入下一階段.
    */
public class PreProcessor {
      // 商品是否還有剩余
      private static boolean reminds = true;
      private static void forbidden() {
          // Do something.
      }
      public static boolean checkReminds() {
          if (reminds) {
              // 遠(yuǎn)程檢測(cè)是否還有剩余郭膛，該RPC接口應(yīng)由數(shù)據(jù)庫服務(wù)器提供，不必完全嚴(yán)格檢查.
              if (!RPC.checkReminds()) {
                  reminds = false;
              }
          }
          return reminds;
      }
    /**
     * 每一個(gè)HTTP請(qǐng)求都要經(jīng)過該預(yù)處理.
     */
      public static void preProcess(HttpRequest request) {
          if (checkReminds()) {
              // 一個(gè)并發(fā)的隊(duì)列
              RequestQueue.queue.add(request);
          } else {
              // 如果已經(jīng)沒有商品了氛悬，則直接駁回請(qǐng)求即可.
              forbidden();
          }
      }
}

• 并發(fā)隊(duì)列的選擇

  Java的并發(fā)包提供了三個(gè)常用的并發(fā)隊(duì)列實(shí)現(xiàn)饲鄙，分別是：ConcurrentLinkedQueue、LinkedBlockingQueue和ArrayBlockingQueue圆雁。

  ArrayBlockingQueue是初始容量固定的阻塞隊(duì)列，我們可以用來作為數(shù)據(jù)庫模塊成功競(jìng)拍的隊(duì)列帆谍，比如有10個(gè)商品伪朽，那么我們就設(shè)定一個(gè)10大小的數(shù)組隊(duì)列。

  ConcurrentLinkedQueue使用的是CAS原語無鎖隊(duì)列實(shí)現(xiàn)汛蝙，是一個(gè)異步隊(duì)列烈涮，入隊(duì)的速度很快，出隊(duì)進(jìn)行了加鎖窖剑，性能稍慢坚洽。

  LinkedBlockingQueue也是阻塞的隊(duì)列，入隊(duì)和出隊(duì)都用了加鎖西土，當(dāng)隊(duì)空的時(shí)候線程會(huì)暫時(shí)阻塞讶舰。

  由于我們的系統(tǒng)入隊(duì)需求要遠(yuǎn)大于出隊(duì)需求，一般不會(huì)出現(xiàn)隊(duì)空的情況需了，所以我們可以選擇ConcurrentLinkedQueue來作為我們的請(qǐng)求隊(duì)列實(shí)現(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>();
}

2. 用戶請(qǐng)求模塊

package seckill;
import org.apache.http.HttpRequest;
public class Processor {
    /**
     * 發(fā)送秒殺事務(wù)到數(shù)據(jù)庫隊(duì)列.
     */
    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.
    }
}

3. 數(shù)據(jù)庫模塊
   數(shù)據(jù)庫主要是使用一個(gè)ArrayBlockingQueue來暫存有可能成功的用戶請(qǐng)求跳昼。

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ù)，則標(biāo)志秒殺已完成肋乍，設(shè)置標(biāo)志位reminds = false.
              info = bids.poll();
          }
      }
}

4.4 數(shù)據(jù)庫設(shè)計(jì)##

4.4.1 基本概念###

概念一“單庫”

概念一“單庫”

概念二“分片”

概念二“分片”

分片解決的是“數(shù)據(jù)量太大”的問題鹅颊，也就是通常說的“水平切分”。一旦引入分片墓造，勢(shì)必有“數(shù)據(jù)路由”的概念堪伍，哪個(gè)數(shù)據(jù)訪問哪個(gè)庫。路由規(guī)則通常有3種方法：

1. 范圍：range

優(yōu)點(diǎn)：簡(jiǎn)單觅闽，容易擴(kuò)展

缺點(diǎn)：各庫壓力不均（新號(hào)段更活躍）

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

優(yōu)點(diǎn)：簡(jiǎn)單，數(shù)據(jù)均衡谱煤，負(fù)載均勻

缺點(diǎn)：遷移麻煩（2庫擴(kuò)3庫數(shù)據(jù)要遷移）

3. 路由服務(wù)：router-config-server

優(yōu)點(diǎn)：靈活性強(qiáng)摊求，業(yè)務(wù)與路由算法解耦

缺點(diǎn)：每次訪問數(shù)據(jù)庫前多一次查詢

概念三“分組”

概念三“分組”

分組解決“可用性”問題，分組通常通過主從復(fù)制的方式實(shí)現(xiàn)。

互聯(lián)網(wǎng)公司數(shù)據(jù)庫實(shí)際軟件架構(gòu)是：又分片室叉，又分組（如下圖）

又分片睹栖，又分組

4.4.2 設(shè)計(jì)思路###

數(shù)據(jù)庫軟件架構(gòu)師平時(shí)設(shè)計(jì)些什么東西呢？至少要考慮以下四點(diǎn)：

1. 如何保證數(shù)據(jù)可用性茧痕；
2. 如何提高數(shù)據(jù)庫讀性能（大部分應(yīng)用讀多寫少野来，讀會(huì)先成為瓶頸）；
3. 如何保證一致性踪旷；
4. 如何提高擴(kuò)展性曼氛；

1. 如何保證數(shù)據(jù)的可用性？

解決可用性問題的思路是=>冗余

如何保證站點(diǎn)的可用性令野？復(fù)制站點(diǎn)舀患，冗余站點(diǎn)

如何保證服務(wù)的可用性？復(fù)制服務(wù)气破，冗余服務(wù)

如何保證數(shù)據(jù)的可用性聊浅？復(fù)制數(shù)據(jù)，冗余數(shù)據(jù)

數(shù)據(jù)的冗余现使，會(huì)帶來一個(gè)副作用=>引發(fā)一致性問題（先不說一致性問題低匙，先說可用性）。

2. 如何保證數(shù)據(jù)庫“讀”高可用碳锈？

冗余讀庫

讀高可用

冗余讀庫帶來的副作用顽冶？讀寫有延時(shí)，可能不一致售碳。

上面這個(gè)圖是很多互聯(lián)網(wǎng)公司mysql的架構(gòu)强重，寫仍然是單點(diǎn)，不能保證寫高可用贸人。

3. 如何保證數(shù)據(jù)庫“寫”高可用竿屹？

冗余寫庫

寫高可用

采用雙主互備的方式，可以冗余寫庫帶來的副作用灸姊？雙寫同步拱燃，數(shù)據(jù)可能沖突（例如“自增id”同步?jīng)_突），如何解決同步?jīng)_突力惯，有兩種常見解決方案：

1. 兩個(gè)寫庫使用不同的初始值碗誉，相同的步長(zhǎng)來增加id：1寫庫的id為0,2,4,6...；2寫庫的id為1,3,5,7...父晶；

2. 不使用數(shù)據(jù)的id哮缺，業(yè)務(wù)層自己生成唯一的id，保證數(shù)據(jù)不沖突甲喝；

實(shí)際中沒有使用上述兩種架構(gòu)來做讀寫的“高可用”尝苇，采用的是“雙主當(dāng)主從用”的方式：

雙主當(dāng)主從用

仍是雙主，但只有一個(gè)主提供服務(wù)（讀+寫），另一個(gè)主是“shadow-master”糠溜，只用來保證高可用淳玩，平時(shí)不提供服務(wù)。

master掛了非竿，shadow-master頂上（vip漂移蜕着，對(duì)業(yè)務(wù)層透明，不需要人工介入）红柱。這種方式的好處：

1. 讀寫沒有延時(shí)承匣；

2. 讀寫高可用；

不足：

1. 不能通過加從庫的方式擴(kuò)展讀性能锤悄；

2. 資源利用率為50%韧骗，一臺(tái)冗余主沒有提供服務(wù)；

那如何提高讀性能呢零聚？進(jìn)入第二個(gè)話題宽闲，如何提供讀性能。

4. 如何擴(kuò)展讀性能

提高讀性能的方式大致有三種握牧，第一種是建立索引。這種方式不展開娩梨，要提到的一點(diǎn)是沿腰，不同的庫可以建立不同的索引。

不同的庫可以建立不同的索引

寫庫不建立索引狈定；

線上讀庫建立線上訪問索引颂龙，例如uid；

線下讀庫建立線下訪問索引纽什，例如time措嵌；

第二種擴(kuò)充讀性能的方式是，增加從庫芦缰，這種方法大家用的比較多企巢，但是，存在兩個(gè)缺點(diǎn)：

1. 從庫越多让蕾，同步越慢浪规；

2. 同步越慢，數(shù)據(jù)不一致窗口越大（不一致后面說探孝，還是先說讀性能的提高）笋婿；

實(shí)際中沒有采用這種方法提高數(shù)據(jù)庫讀性能（沒有從庫），采用的是增加緩存顿颅。常見的緩存架構(gòu)如下：

常見玩法：數(shù)據(jù)庫+緩存

上游是業(yè)務(wù)應(yīng)用缸濒，下游是主庫，從庫（讀寫分離），緩存庇配。實(shí)際的玩法：服務(wù)+數(shù)據(jù)庫+緩存一套斩跌。

服務(wù)+數(shù)據(jù)庫+緩存一套

業(yè)務(wù)層不直接面向db和cache，服務(wù)層屏蔽了底層db讨永、cache的復(fù)雜性滔驶。為什么要引入服務(wù)層，今天不展開卿闹，采用了“服務(wù)+數(shù)據(jù)庫+緩存一套”的方式提供數(shù)據(jù)訪問揭糕，用cache提高讀性能。

不管采用主從的方式擴(kuò)展讀性能锻霎，還是緩存的方式擴(kuò)展讀性能著角，數(shù)據(jù)都要復(fù)制多份（主+從，db+cache）旋恼，一定會(huì)引發(fā)一致性問題吏口。

5. 如何保證一致性？

主從數(shù)據(jù)庫的一致性冰更，通常有兩種解決方案：

1. 中間件

   中間件

   如果某一個(gè)key有寫操作产徊，在不一致時(shí)間窗口內(nèi)，中間件會(huì)將這個(gè)key的讀操作也路由到主庫上蜀细。這個(gè)方案的缺點(diǎn)是舟铜，數(shù)據(jù)庫中間件的門檻較高（百度，騰訊奠衔，阿里谆刨，360等一些公司有）。

2. 強(qiáng)制讀主

   強(qiáng)制讀主

   上面實(shí)際用的“雙主當(dāng)主從用”的架構(gòu)归斤，不存在主從不一致的問題痊夭。第二類不一致，是db與緩存間的不一致：

   常見玩法：數(shù)據(jù)庫+緩存

   常見的緩存架構(gòu)如上脏里，此時(shí)寫操作的順序是：

   （1）淘汰cache她我；

   （2）寫數(shù)據(jù)庫；

   讀操作的順序是：

   （1）讀cache迫横，如果cache hit則返回鸦难；

   （2）如果cache miss，則讀從庫员淫；

   （3）讀從庫后合蔽，將數(shù)據(jù)放回cache；

   在一些異常時(shí)序情況下介返，有可能從【從庫讀到舊數(shù)據(jù)（同步還沒有完成）拴事，舊數(shù)據(jù)入cache后】沃斤，數(shù)據(jù)會(huì)長(zhǎng)期不一致。解決辦法是“緩存雙淘汰”刃宵，寫操作時(shí)序升級(jí)為：

   （1）淘汰cache衡瓶；

   （2）寫數(shù)據(jù)庫；

   （3）在經(jīng)過“主從同步延時(shí)窗口時(shí)間”后牲证，再次發(fā)起一個(gè)異步淘汰cache的請(qǐng)求哮针；

   這樣，即使有臟數(shù)據(jù)如cache坦袍，一個(gè)小的時(shí)間窗口之后十厢，臟數(shù)據(jù)還是會(huì)被淘汰。帶來的代價(jià)是捂齐，多引入一次讀miss（成本可以忽略）蛮放。

   除此之外，最佳實(shí)踐之一是：建議為所有cache中的item設(shè)置一個(gè)超時(shí)時(shí)間奠宜。

3. 如何提高數(shù)據(jù)庫的擴(kuò)展性包颁？

原來用hash的方式路由，分為2個(gè)庫压真，數(shù)據(jù)量還是太大娩嚼，要分為3個(gè)庫，勢(shì)必需要進(jìn)行數(shù)據(jù)遷移滴肿，有一個(gè)很帥氣的“數(shù)據(jù)庫秒級(jí)擴(kuò)容”方案岳悟。

如何秒級(jí)擴(kuò)容？

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

原來分2庫

服務(wù)+數(shù)據(jù)庫是一套（省去了緩存）和屎，數(shù)據(jù)庫采用“雙主”的模式拴驮。

擴(kuò)容步驟：

第一步，將一個(gè)主庫提升;

第二步柴信，修改配置套啤，2庫變4庫（原來MOD2，現(xiàn)在配置修改后MOD4）随常，擴(kuò)容完成潜沦；

原MOD2為偶的部分，現(xiàn)在會(huì)MOD4余0或者2绪氛；原MOD2為奇的部分唆鸡，現(xiàn)在會(huì)MOD4余1或者3；數(shù)據(jù)不需要遷移枣察，同時(shí)争占，雙主互相同步燃逻，一遍是余0，一邊余2臂痕，兩邊數(shù)據(jù)同步也不會(huì)沖突伯襟，秒級(jí)完成擴(kuò)容！

最后握童，要做一些收尾工作：

1. 將舊的雙主同步解除姆怪；

2. 增加新的雙主（雙主是保證可用性的，shadow-master平時(shí)不提供服務(wù)）澡绩；

3. 刪除多余的數(shù)據(jù)（余0的主稽揭，可以將余2的數(shù)據(jù)刪除掉）；

2庫變4庫的擴(kuò)展

這樣英古，秒級(jí)別內(nèi)淀衣，我們就完成了2庫變4庫的擴(kuò)展。

5 大并發(fā)帶來的挑戰(zhàn)#

5.1 請(qǐng)求接口的合理設(shè)計(jì)##

一個(gè)秒殺或者搶購頁面召调，通常分為2個(gè)部分膨桥，一個(gè)是靜態(tài)的HTML等內(nèi)容，另一個(gè)就是參與秒殺的Web后臺(tái)請(qǐng)求接口唠叛。

通常靜態(tài)HTML等內(nèi)容只嚣，是通過CDN的部署，一般壓力不大艺沼，核心瓶頸實(shí)際上在后臺(tái)請(qǐng)求接口上册舞。這個(gè)后端接口，必須能夠支持高并發(fā)請(qǐng)求障般，同時(shí)调鲸，非常重要的一點(diǎn)，必須盡可能“快”挽荡，在最短的時(shí)間里返回用戶的請(qǐng)求結(jié)果藐石。為了實(shí)現(xiàn)盡可能快這一點(diǎn)，接口的后端存儲(chǔ)使用內(nèi)存級(jí)別的操作會(huì)更好一點(diǎn)定拟。仍然直接面向MySQL之類的存儲(chǔ)是不合適的于微，如果有這種復(fù)雜業(yè)務(wù)的需求，都建議采用異步寫入青自。

秒殺業(yè)務(wù)流程設(shè)計(jì)

當(dāng)然株依，也有一些秒殺和搶購采用“滯后反饋”，就是說秒殺當(dāng)下不知道結(jié)果延窜，一段時(shí)間后才可以從頁面中看到用戶是否秒殺成功恋腕。但是，這種屬于“偷懶”行為逆瑞，同時(shí)給用戶的體驗(yàn)也不好吗坚，容易被用戶認(rèn)為是“暗箱操作”祈远。

5.2 高并發(fā)的挑戰(zhàn)：一定要“快”##

我們通常衡量一個(gè)Web系統(tǒng)的吞吐率的指標(biāo)是QPS（Query Per Second，每秒處理請(qǐng)求數(shù)）商源，解決每秒數(shù)萬次的高并發(fā)場(chǎng)景车份，這個(gè)指標(biāo)非常關(guān)鍵。舉個(gè)例子牡彻，我們假設(shè)處理一個(gè)業(yè)務(wù)請(qǐng)求平均響應(yīng)時(shí)間為100ms扫沼，同時(shí)，系統(tǒng)內(nèi)有20臺(tái)Apache的Web服務(wù)器庄吼，配置MaxClients為500個(gè)（表示Apache的最大連接數(shù)目）缎除。

那么，我們的Web系統(tǒng)的理論峰值QPS為（理想化的計(jì)算方式）：

20*500/0.1 = 100000 （10萬QPS）

咦总寻？我們的系統(tǒng)似乎很強(qiáng)大器罐，1秒鐘可以處理完10萬的請(qǐng)求，5w/s的秒殺似乎是“紙老虎”哈渐行。實(shí)際情況轰坊，當(dāng)然沒有這么理想。在高并發(fā)的實(shí)際場(chǎng)景下祟印，機(jī)器都處于高負(fù)載的狀態(tài)肴沫，在這個(gè)時(shí)候平均響應(yīng)時(shí)間會(huì)被大大增加。

就Web服務(wù)器而言蕴忆，Apache打開了越多的連接進(jìn)程颤芬，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗套鹅，然后就直接導(dǎo)致平均響應(yīng)時(shí)間增加站蝠。因此上述的MaxClient數(shù)目，要根據(jù)CPU卓鹿、內(nèi)存等硬件因素綜合考慮复局，絕對(duì)不是越多越好汗洒√趾校可以通過Apache自帶的abench來測(cè)試一下苏潜，取一個(gè)合適的值存谎。然后拔疚，我們選擇內(nèi)存操作級(jí)別的存儲(chǔ)的Redis，在高并發(fā)的狀態(tài)下既荚，存儲(chǔ)的響應(yīng)時(shí)間至關(guān)重要稚失。網(wǎng)絡(luò)帶寬雖然也是一個(gè)因素，不過恰聘，這種請(qǐng)求數(shù)據(jù)包一般比較小句各，一般很少成為請(qǐng)求的瓶頸吸占。負(fù)載均衡成為系統(tǒng)瓶頸的情況比較少，在這里不做討論哈凿宾。

那么問題來了矾屯，假設(shè)我們的系統(tǒng)，在5w/s的高并發(fā)狀態(tài)下初厚，平均響應(yīng)時(shí)間從100ms變?yōu)?50ms（實(shí)際情況件蚕，甚至更多）：

20*500/0.25 = 40000 （4萬QPS）

于是，我們的系統(tǒng)剩下了4w的QPS产禾，面對(duì)5w每秒的請(qǐng)求排作，中間相差了1w。

然后亚情，這才是真正的惡夢(mèng)開始妄痪。舉個(gè)例子，高速路口楞件，1秒鐘來5部車衫生，每秒通過5部車，高速路口運(yùn)作正常履因。突然障簿，這個(gè)路口1秒鐘只能通過4部車，車流量仍然依舊栅迄，結(jié)果必定出現(xiàn)大塞車站故。（5條車道忽然變成4條車道的感覺）。

同理毅舆，某一個(gè)秒內(nèi)西篓，20*500個(gè)可用連接進(jìn)程都在滿負(fù)荷工作中，卻仍然有1萬個(gè)新來請(qǐng)求憋活，沒有連接進(jìn)程可用岂津，系統(tǒng)陷入到異常狀態(tài)也是預(yù)期之內(nèi)。

Paste_Image.png

其實(shí)在正常的非高并發(fā)的業(yè)務(wù)場(chǎng)景中悦即，也有類似的情況出現(xiàn)吮成，某個(gè)業(yè)務(wù)請(qǐng)求接口出現(xiàn)問題，響應(yīng)時(shí)間極慢辜梳，將整個(gè)Web請(qǐng)求響應(yīng)時(shí)間拉得很長(zhǎng)粱甫，逐漸將Web服務(wù)器的可用連接數(shù)占滿，其他正常的業(yè)務(wù)請(qǐng)求作瞄，無連接進(jìn)程可用茶宵。

更可怕的問題是，是用戶的行為特點(diǎn)宗挥，系統(tǒng)越是不可用乌庶，用戶的點(diǎn)擊越頻繁种蝶，惡性循環(huán)最終導(dǎo)致“雪崩”（其中一臺(tái)Web機(jī)器掛了，導(dǎo)致流量分散到其他正常工作的機(jī)器上瞒大，再導(dǎo)致正常的機(jī)器也掛螃征，然后惡性循環(huán)），將整個(gè)Web系統(tǒng)拖垮透敌。

5.3 重啟與過載保護(hù)##

如果系統(tǒng)發(fā)生“雪崩”会傲，貿(mào)然重啟服務(wù)，是無法解決問題的拙泽。最常見的現(xiàn)象是淌山，啟動(dòng)起來后，立刻掛掉顾瞻。這個(gè)時(shí)候泼疑，最好在入口層將流量拒絕，然后再將重啟荷荤。如果是redis/memcache這種服務(wù)也掛了退渗，重啟的時(shí)候需要注意“預(yù)熱”，并且很可能需要比較長(zhǎng)的時(shí)間蕴纳。

秒殺和搶購的場(chǎng)景会油，流量往往是超乎我們系統(tǒng)的準(zhǔn)備和想象的。這個(gè)時(shí)候古毛，過載保護(hù)是必要的翻翩。如果檢測(cè)到系統(tǒng)滿負(fù)載狀態(tài)，拒絕請(qǐng)求也是一種保護(hù)措施稻薇。在前端設(shè)置過濾是最簡(jiǎn)單的方式嫂冻，但是，這種做法是被用戶“千夫所指”的行為塞椎。更合適一點(diǎn)的是桨仿，將過載保護(hù)設(shè)置在CGI入口層，快速將客戶的直接請(qǐng)求返回案狠。

6 作弊的手段：進(jìn)攻與防守#

秒殺和搶購收到了“海量”的請(qǐng)求服傍，實(shí)際上里面的水分是很大的。不少用戶骂铁，為了“搶“到商品吹零，會(huì)使用“刷票工具”等類型的輔助工具，幫助他們發(fā)送盡可能多的請(qǐng)求到服務(wù)器从铲。還有一部分高級(jí)用戶瘪校，制作強(qiáng)大的自動(dòng)請(qǐng)求腳本澄暮。這種做法的理由也很簡(jiǎn)單名段，就是在參與秒殺和搶購的請(qǐng)求中阱扬，自己的請(qǐng)求數(shù)目占比越多，成功的概率越高伸辟。

這些都是屬于“作弊的手段”麻惶，不過，有“進(jìn)攻”就有“防守”信夫，這是一場(chǎng)沒有硝煙的戰(zhàn)斗哈窃蹋。

6.1 同一個(gè)賬號(hào)，一次性發(fā)出多個(gè)請(qǐng)求##

部分用戶通過瀏覽器的插件或者其他工具静稻，在秒殺開始的時(shí)間里警没，以自己的賬號(hào)，一次發(fā)送上百甚至更多的請(qǐng)求振湾。實(shí)際上杀迹，這樣的用戶破壞了秒殺和搶購的公平性。

這種請(qǐng)求在某些沒有做數(shù)據(jù)安全處理的系統(tǒng)里押搪，也可能造成另外一種破壞树酪，導(dǎo)致某些判斷條件被繞過。例如一個(gè)簡(jiǎn)單的領(lǐng)取邏輯大州，先判斷用戶是否有參與記錄续语，如果沒有則領(lǐng)取成功，最后寫入到參與記錄中厦画。這是個(gè)非常簡(jiǎn)單的邏輯疮茄，但是，在高并發(fā)的場(chǎng)景下根暑，存在深深的漏洞娃豹。多個(gè)并發(fā)請(qǐng)求通過負(fù)載均衡服務(wù)器，分配到內(nèi)網(wǎng)的多臺(tái)Web服務(wù)器购裙，它們首先向存儲(chǔ)發(fā)送查詢請(qǐng)求懂版，然后，在某個(gè)請(qǐng)求成功寫入?yún)⑴c記錄的時(shí)間差內(nèi)躏率，其他的請(qǐng)求獲查詢到的結(jié)果都是“沒有參與記錄”躯畴。這里，就存在邏輯判斷被繞過的風(fēng)險(xiǎn)薇芝。

Paste_Image.png

應(yīng)對(duì)方案：

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

Paste_Image.png

或者，自己實(shí)現(xiàn)一個(gè)服務(wù)百侧，將同一個(gè)賬號(hào)的請(qǐng)求放入一個(gè)隊(duì)列中砰识，處理完一個(gè)，再處理下一個(gè)佣渴。

6.2 多個(gè)賬號(hào)辫狼，一次性發(fā)送多個(gè)請(qǐng)求##

很多公司的賬號(hào)注冊(cè)功能，在發(fā)展早期幾乎是沒有限制的辛润，很容易就可以注冊(cè)很多個(gè)賬號(hào)予借。因此，也導(dǎo)致了出現(xiàn)了一些特殊的工作室频蛔，通過編寫自動(dòng)注冊(cè)腳本灵迫，積累了一大批“僵尸賬號(hào)”，數(shù)量龐大晦溪，幾萬甚至幾十萬的賬號(hào)不等瀑粥，專門做各種刷的行為（這就是微博中的“僵尸粉“的來源）。舉個(gè)例子三圆，例如微博中有轉(zhuǎn)發(fā)抽獎(jiǎng)的活動(dòng)狞换，如果我們使用幾萬個(gè)“僵尸號(hào)”去混進(jìn)去轉(zhuǎn)發(fā)，這樣就可以大大提升我們中獎(jiǎng)的概率舟肉。

這種賬號(hào)修噪，使用在秒殺和搶購里，也是同一個(gè)道理路媚。例如黄琼，iPhone官網(wǎng)的搶購，火車票黃牛黨整慎。

Paste_Image.png

應(yīng)對(duì)方案：

這種場(chǎng)景脏款，可以通過檢測(cè)指定機(jī)器IP請(qǐng)求頻率就可以解決，如果發(fā)現(xiàn)某個(gè)IP請(qǐng)求頻率很高裤园，可以給它彈出一個(gè)驗(yàn)證碼或者直接禁止它的請(qǐng)求：

1. 彈出驗(yàn)證碼撤师，最核心的追求，就是分辨出真實(shí)用戶拧揽。因此剃盾，大家可能經(jīng)常發(fā)現(xiàn)腺占，網(wǎng)站彈出的驗(yàn)證碼，有些是“鬼神亂舞”的樣子痒谴，有時(shí)讓我們根本無法看清衰伯。他們這樣做的原因，其實(shí)也是為了讓驗(yàn)證碼的圖片不被輕易識(shí)別闰歪，因?yàn)閺?qiáng)大的“自動(dòng)腳本”可以通過圖片識(shí)別里面的字符，然后讓腳本自動(dòng)填寫驗(yàn)證碼蓖墅。實(shí)際上库倘，有一些非常創(chuàng)新的驗(yàn)證碼，效果會(huì)比較好论矾，例如給你一個(gè)簡(jiǎn)單問題讓你回答教翩，或者讓你完成某些簡(jiǎn)單操作（例如百度貼吧的驗(yàn)證碼）。

2. 直接禁止IP贪壳，實(shí)際上是有些粗暴的饱亿，因?yàn)橛行┱鎸?shí)用戶的網(wǎng)絡(luò)場(chǎng)景恰好是同一出口IP的，可能會(huì)有“誤傷“闰靴。但是這一個(gè)做法簡(jiǎn)單高效彪笼，根據(jù)實(shí)際場(chǎng)景使用可以獲得很好的效果。

6.3 多個(gè)賬號(hào)蚂且，不同IP發(fā)送不同請(qǐng)求##

所謂道高一尺配猫，魔高一丈。有進(jìn)攻杏死，就會(huì)有防守泵肄，永不休止。這些“工作室”淑翼，發(fā)現(xiàn)你對(duì)單機(jī)IP請(qǐng)求頻率有控制之后腐巢，他們也針對(duì)這種場(chǎng)景，想出了他們的“新進(jìn)攻方案”玄括，就是不斷改變IP冯丙。

Paste_Image.png

有同學(xué)會(huì)好奇，這些隨機(jī)IP服務(wù)怎么來的遭京。有一些是某些機(jī)構(gòu)自己占據(jù)一批獨(dú)立IP银还，然后做成一個(gè)隨機(jī)代理IP的服務(wù)，有償提供給這些“工作室”使用洁墙。還有一些更為黑暗一點(diǎn)的蛹疯，就是通過木馬黑掉普通用戶的電腦，這個(gè)木馬也不破壞用戶電腦的正常運(yùn)作热监，只做一件事情捺弦，就是轉(zhuǎn)發(fā)IP包，普通用戶的電腦被變成了IP代理出口。通過這種做法列吼，黑客就拿到了大量的獨(dú)立IP幽崩，然后搭建為隨機(jī)IP服務(wù)，就是為了掙錢寞钥。

應(yīng)對(duì)方案：

說實(shí)話慌申，這種場(chǎng)景下的請(qǐng)求，和真實(shí)用戶的行為理郑，已經(jīng)基本相同了蹄溉，想做分辨很困難。再做進(jìn)一步的限制很容易“誤傷“真實(shí)用戶您炉，這個(gè)時(shí)候柒爵，通常只能通過設(shè)置業(yè)務(wù)門檻高來限制這種請(qǐng)求了，或者通過賬號(hào)行為的”數(shù)據(jù)挖掘“來提前清理掉它們赚爵。

僵尸賬號(hào)也還是有一些共同特征的棉胀，例如賬號(hào)很可能屬于同一個(gè)號(hào)碼段甚至是連號(hào)的，活躍度不高冀膝，等級(jí)低唁奢，資料不全等等。根據(jù)這些特點(diǎn)窝剖，適當(dāng)設(shè)置參與門檻驮瞧，例如限制參與秒殺的賬號(hào)等級(jí)。通過這些業(yè)務(wù)手段枯芬，也是可以過濾掉一些僵尸號(hào)论笔。

7 高并發(fā)下的數(shù)據(jù)安全#

我們知道在多線程寫入同一個(gè)文件的時(shí)候，會(huì)存現(xiàn)“線程安全”的問題（多個(gè)線程同時(shí)運(yùn)行同一段代碼千所，如果每次運(yùn)行結(jié)果和單線程運(yùn)行的結(jié)果是一樣的狂魔，結(jié)果和預(yù)期相同，就是線程安全的）淫痰。如果是MySQL數(shù)據(jù)庫最楷，可以使用它自帶的鎖機(jī)制很好的解決問題，但是待错，在大規(guī)模并發(fā)的場(chǎng)景中籽孙，是不推薦使用MySQL的。秒殺和搶購的場(chǎng)景中火俄，還有另外一個(gè)問題犯建，就是“超發(fā)”，如果在這方面控制不慎瓜客，會(huì)產(chǎn)生發(fā)送過多的情況适瓦。我們也曾經(jīng)聽說過竿开，某些電商搞搶購活動(dòng)，買家成功拍下后玻熙，商家卻不承認(rèn)訂單有效否彩，拒絕發(fā)貨。這里的問題嗦随，也許并不一定是商家奸詐列荔，而是系統(tǒng)技術(shù)層面存在超發(fā)風(fēng)險(xiǎn)導(dǎo)致的。

7.1 超發(fā)的原因##

假設(shè)某個(gè)搶購場(chǎng)景中枚尼，我們一共只有100個(gè)商品贴浙，在最后一刻，我們已經(jīng)消耗了99個(gè)商品姑原，僅剩最后一個(gè)悬而。這個(gè)時(shí)候呜舒，系統(tǒng)發(fā)來多個(gè)并發(fā)請(qǐng)求锭汛，這批請(qǐng)求讀取到的商品余量都是99個(gè)，然后都通過了這一個(gè)余量判斷袭蝗，最終導(dǎo)致超發(fā)唤殴。

Paste_Image.png

在上面的這個(gè)圖中，就導(dǎo)致了并發(fā)用戶B也“搶購成功”到腥，多讓一個(gè)人獲得了商品朵逝。這種場(chǎng)景，在高并發(fā)的情況下非常容易出現(xiàn)乡范。

7.2 悲觀鎖思路##

解決線程安全的思路很多配名，可以從“悲觀鎖”的方向開始討論。

悲觀鎖晋辆，也就是在修改數(shù)據(jù)的時(shí)候渠脉，采用鎖定狀態(tài)，排斥外部請(qǐng)求的修改瓶佳。遇到加鎖的狀態(tài)芋膘，就必須等待。

Paste_Image.png

雖然上述的方案的確解決了線程安全的問題霸饲，但是为朋，別忘記，我們的場(chǎng)景是“高并發(fā)”厚脉。也就是說习寸，會(huì)很多這樣的修改請(qǐng)求，每個(gè)請(qǐng)求都需要等待“鎖”傻工，某些線程可能永遠(yuǎn)都沒有機(jī)會(huì)搶到這個(gè)“鎖”融涣，這種請(qǐng)求就會(huì)死在那里童番。同時(shí)，這種請(qǐng)求會(huì)很多威鹿，瞬間增大系統(tǒng)的平均響應(yīng)時(shí)間剃斧，結(jié)果是可用連接數(shù)被耗盡，系統(tǒng)陷入異常忽你。

7.3 FIFO隊(duì)列思路##

那好幼东，那么我們稍微修改一下上面的場(chǎng)景，我們直接將請(qǐng)求放入隊(duì)列中的科雳，采用FIFO（First Input First Output根蟹，先進(jìn)先出），這樣的話糟秘，我們就不會(huì)導(dǎo)致某些請(qǐng)求永遠(yuǎn)獲取不到鎖简逮。看到這里尿赚，是不是有點(diǎn)強(qiáng)行將多線程變成單線程的感覺哈散庶。

Paste_Image.png

然后，我們現(xiàn)在解決了鎖的問題凌净，全部請(qǐng)求采用“先進(jìn)先出”的隊(duì)列方式來處理悲龟。那么新的問題來了，高并發(fā)的場(chǎng)景下冰寻，因?yàn)檎?qǐng)求很多须教，很可能一瞬間將隊(duì)列內(nèi)存“撐爆”，然后系統(tǒng)又陷入到了異常狀態(tài)斩芭∏嵯伲或者設(shè)計(jì)一個(gè)極大的內(nèi)存隊(duì)列，也是一種方案划乖，但是贬养，系統(tǒng)處理完一個(gè)隊(duì)列內(nèi)請(qǐng)求的速度根本無法和瘋狂涌入隊(duì)列中的數(shù)目相比。也就是說迁筛，隊(duì)列內(nèi)的請(qǐng)求會(huì)越積累越多煤蚌，最終Web系統(tǒng)平均響應(yīng)時(shí)候還是會(huì)大幅下降，系統(tǒng)還是陷入異常细卧。

7.4 樂觀鎖思路##

這個(gè)時(shí)候尉桩，我們就可以討論一下“樂觀鎖”的思路了。樂觀鎖贪庙，是相對(duì)于“悲觀鎖”采用更為寬松的加鎖機(jī)制蜘犁，大都是采用帶版本號(hào)（Version）更新。實(shí)現(xiàn)就是止邮，這個(gè)數(shù)據(jù)所有請(qǐng)求都有資格去修改这橙，但會(huì)獲得一個(gè)該數(shù)據(jù)的版本號(hào)奏窑，只有版本號(hào)符合的才能更新成功，其他的返回?fù)屬徥∏＿@樣的話埃唯，我們就不需要考慮隊(duì)列的問題，不過鹰晨，它會(huì)增大CPU的計(jì)算開銷墨叛。但是，綜合來說模蜡，這是一個(gè)比較好的解決方案漠趁。

Paste_Image.png

有很多軟件和服務(wù)都“樂觀鎖”功能的支持，例如Redis中的watch就是其中之一忍疾。通過這個(gè)實(shí)現(xiàn)闯传，我們保證了數(shù)據(jù)的安全。

8 總結(jié)#

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