前幾年，火車票購票網(wǎng)站12306，每到放假高峰期，在線票刷不出來，購買困難，甚至出現(xiàn)了各種插件支持搶票，這樣的場景，對于每個(gè)買過票的人，應(yīng)該印象深刻。小米手機(jī)的搶購活動，同樣異�；鸨�，在幾分鐘的時(shí)間內(nèi)，賣出幾十萬部手機(jī)。當(dāng)一個(gè)Web系統(tǒng)，在一秒鐘內(nèi)收到數(shù)以萬計(jì)甚至更多請求時(shí)，系統(tǒng)的優(yōu)化和穩(wěn)定至關(guān)重要。

在面試中，面試官提出這樣的問題，應(yīng)該從哪些角度分析。在工作中，也許沒有這么龐大復(fù)雜的應(yīng)用場景，但是，針對網(wǎng)站的優(yōu)化思路是一致的。本文從技術(shù)度度，分析下應(yīng)如何設(shè)計(jì)優(yōu)化系統(tǒng)，才能保障如此大規(guī)模的并發(fā)訪問。

秒殺系統(tǒng)主要解決三大問題：

一、瞬時(shí)的高并發(fā)訪問。搶購和普通的電商銷售有所不同，普通的電商銷售，流量是比較平均的，雖然有波峰波谷，但不會特別突出。而搶購是在特定時(shí)間點(diǎn)進(jìn)行的推銷活動，搶購開始前，用戶不斷刷新頁面，以獲得購買按鈕；搶購開始的一瞬間，集中并發(fā)購買。

二、數(shù)據(jù)正確性。搶購畢竟是一種購買行為，需要購買、扣減庫存、支付等復(fù)雜的流程，在此過程中，要保證數(shù)據(jù)的正確性，防止超賣（賣出量超過庫存）的發(fā)生。

三、防作弊。無論是火車票的購買，還是低價(jià)商品的促銷，肯定不希望某些客戶買到所有的商品，應(yīng)盡量保證公平性。通過購票插件購買火車票，阿里巴巴搶月餅事件等，需要限制技術(shù)性用戶繞過網(wǎng)站的限制，通過技術(shù)手段獲得不良收益。

解決上述問題，主要有如下的三個(gè)思路：訪問攔截，分流，限流。

主流的Web站點(diǎn)采用分層的架構(gòu)設(shè)計(jì)，如果你的應(yīng)用還沒有采用分層的架構(gòu)，那么先做分層設(shè)計(jì)吧。一般來說，瀏覽器采用了html/js/css技術(shù)，負(fù)責(zé)數(shù)據(jù)的展示；反向代理一般采用nginx，負(fù)責(zé)負(fù)載均衡；Web層是指Php，Tomcat等應(yīng)用服務(wù)器，負(fù)責(zé)用戶狀態(tài)的維護(hù)，http協(xié)議處理等；service層一般是rpc調(diào)用，當(dāng)然也有用http的，例如spring cloud；數(shù)據(jù)庫存儲一般是mongodb，mysql等持久化數(shù)據(jù)方案。用戶的一次數(shù)據(jù)訪問，例如查詢商品庫存，數(shù)據(jù)是從上層依次調(diào)用到DB，逐層返回?cái)?shù)據(jù)。

所謂訪問攔截，是指盡量把訪問攔截在上層，減輕下一層的壓力，即離用戶訪問更近的那一層。下面將從每一層講解如何做訪問攔截。

瀏覽器訪問攔截：產(chǎn)品層面，當(dāng)用戶點(diǎn)擊查詢或購買按鈕后，按鈕置灰，防止用戶重復(fù)提交數(shù)據(jù)。js層面，限制用戶在限定時(shí)間內(nèi)的接口調(diào)用次數(shù)，或者返回相同的值。例如，用戶重復(fù)刷新，每秒訪問10次接口，變成5秒鐘訪問一次，并發(fā)量將會降低50倍。此種方法，可以攔截90%的小白用戶的訪問，但是技術(shù)型的用戶可以繞過js，通過腳本或其他自動化方式調(diào)用接口，當(dāng)年出現(xiàn)的刷票神器，就屬于這類范疇。用戶量雖小，但是訪問量很大。關(guān)于防作弊的問題，后續(xù)討論。

CDN加速：CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其基本思路是盡可能避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母�快、更穩(wěn)定。簡單的來說，就是把原服務(wù)器上數(shù)據(jù)復(fù)制到其他服務(wù)器上，用戶訪問時(shí)，那臺服務(wù)器近訪問到的就是那臺服務(wù)器上的數(shù)據(jù)。CDN的劣勢是內(nèi)容的變更生效慢，所以僅適用于“幾乎不變”的資源，例如引用的js包，圖片等。

動靜分離與反向代理層訪問攔截：動態(tài)頁面是指根據(jù)實(shí)時(shí)數(shù)據(jù)渲染的，需要組織數(shù)據(jù)、渲染頁面；靜態(tài)頁面是存儲在文件系統(tǒng)的文件，不會根據(jù)數(shù)據(jù)變化而變化，讀取速度很快。為了提升效率，應(yīng)盡可能的靜態(tài)化，用靜態(tài)頁面，替換動態(tài)頁面。例如，商品信息頁，商品信息在發(fā)布后，是不會變化的，如果采用動態(tài)的方式，訪問數(shù)據(jù)庫讀取數(shù)據(jù)，service組裝數(shù)據(jù)，web渲染數(shù)據(jù)；如果發(fā)布商品信息時(shí)，就保存下商品信息的靜態(tài)頁面，訪問時(shí)只需要讀取一個(gè)文件就夠了。

做了動靜分離，靜態(tài)文件的訪問應(yīng)在哪一層返回？無論是tomcat，還是apache，都支持靜態(tài)文件的訪問，很多時(shí)候我們也是這么做的，把靜態(tài)文件作為web項(xiàng)目的一部分進(jìn)行發(fā)布。Nginx也支持靜態(tài)文件的訪問，更高效的做法是，把靜態(tài)文件交由nginx管理，訪問nginx直接返回靜態(tài)數(shù)據(jù)，減輕Web服務(wù)的壓力。

Web層和Service層訪問攔截：通過上述的訪問攔截，進(jìn)入到web層的，都是動態(tài)數(shù)據(jù)訪問。這部分的訪問攔截，主要采用緩存的策略，減少對下一層的數(shù)據(jù)訪問。緩存又可分為本地緩存和redis、memcache等緩存中間件。關(guān)于緩存，重點(diǎn)關(guān)注緩存的淘汰策略。一般有三種方式：超時(shí)更新，定時(shí)更新，通知更新。

訪問攔截，除了減少向下一層的訪問，還大幅提高系統(tǒng)的支持用戶數(shù)。訪問攔截，大大減少了每次請求的處理時(shí)間，假設(shè)：每個(gè)請求原來需要200ms時(shí)間，10W的并發(fā)量，每秒鐘可處理50W的請求；通過訪問攔截，每個(gè)請求的處理時(shí)間下降到100ms，同樣的并發(fā)量，每秒鐘可處理100W的請求。

通過上述的分析，各層通過訪問攔截，系統(tǒng)架構(gòu)演變成如下的結(jié)構(gòu)。

在并發(fā)量巨大的場景下，通過上述的優(yōu)化遠(yuǎn)遠(yuǎn)不夠的，因?yàn)閱闻_服務(wù)器的處理能力是有限的，即便在當(dāng)前硬件設(shè)備越來越便宜，也不可能無限擴(kuò)容。分流就是指通過多臺服務(wù)器，并發(fā)的處理請求，減輕單臺服務(wù)的負(fù)載。

DNS輪詢：Nginx的處理能力是有限的，單臺服務(wù)器支持10W左右的并發(fā)訪問，沒有問題。如果更大的負(fù)載怎么辦？Nginx是應(yīng)用服務(wù)的入口，不能再應(yīng)用服務(wù)這個(gè)層次增加服務(wù)器，提高并發(fā)處理能力。

通過瀏覽器輸入域名訪問某個(gè)服務(wù)，其過程如圖所示。DNS輪詢是ISP提供的一個(gè)服務(wù)，不同的用戶訪問同一個(gè)域名，獲取到不同的IP地址。例如：給www.example.com配置4個(gè)IP地址，如果有40W的并發(fā)訪問，每個(gè)IP將會獲得10W的并發(fā)訪問。當(dāng)然，域名的IP地址配置，可以支持不同的策略，例如按照電信運(yùn)營商分配，按照地域分配等。

Nginx負(fù)載均衡：Nginx可以支持10W的并發(fā)訪問，而應(yīng)用服務(wù)器卻達(dá)不到這個(gè)水準(zhǔn)，tomcat一般支持1W的并發(fā)訪問就很好了。Nginx支持配置請求的代理策略，把請求路由到多個(gè)Web服務(wù)器處理。Nginx支持的負(fù)載均衡策略包括：輪詢，權(quán)重，ip_hash，fair，url_hash等。

分布式架構(gòu)的負(fù)載策略：Web層調(diào)用service，以及service之間的調(diào)用，每個(gè)service都需要部署多份。目前最常用的兩個(gè)框架技術(shù)，spring cloud和dubbo，都采用客戶端負(fù)載均衡策略，路由到service的不同實(shí)例。

Redis負(fù)載：redis是內(nèi)存的緩存結(jié)構(gòu)，非常高效，瓶頸在于網(wǎng)絡(luò)IO，支持幾十萬的QPS。redis分流，可考慮分片的設(shè)計(jì)，把數(shù)據(jù)分配到多臺服務(wù)器上，減輕每臺機(jī)器的負(fù)載。一般情況下，分片策略多用戶redis數(shù)據(jù)擴(kuò)容方案。

Mysql讀寫分離：對寫請求，不適合做分流，因?yàn)榉至骱蟮臄?shù)據(jù)同步是大問題，導(dǎo)致數(shù)據(jù)不一致。對于寫請求，一般采用讀寫分離的策略，并且可以多臺讀庫。讀庫應(yīng)用MyIsam引擎，單獨(dú)設(shè)置合適的索引，提高讀性能。從庫并不是越多越好，因?yàn)閺膸煸蕉�，�?shù)據(jù)延遲越嚴(yán)重，要保持好平衡。

通過上述的分析，各層通過分流策略，系統(tǒng)架構(gòu)演變成如下的結(jié)構(gòu)。

訪問攔截和分流的策略，主要作用還是解決并發(fā)讀的問題。購買、支付等這類“寫請求”，不能像讀緩存一樣，寫緩存提高效率，數(shù)據(jù)持久化成功，才算交易成功。尤其搶購這種模式下，商品數(shù)量少，如果多臺服務(wù)同事寫數(shù)據(jù)，將造成mysql嚴(yán)重的行鎖沖突，執(zhí)行效率遠(yuǎn)遠(yuǎn)不如順序執(zhí)行。并且大量的所等待，延長單個(gè)操作的時(shí)長，占用工作線程，產(chǎn)生服務(wù)雪崩現(xiàn)象，短時(shí)間內(nèi)不能對外提供服務(wù)。解決此問題的思路是限流，限制寫操作的流量，使其正常運(yùn)行，不影響業(yè)務(wù)。

計(jì)數(shù)器：假設(shè)總共100個(gè)商品庫存，供大家搶貨，并發(fā)訪問極大�？梢栽赪eb層做一個(gè)計(jì)數(shù)器，搶單一次計(jì)數(shù)器加1，計(jì)數(shù)器到達(dá)100后，直接返回?fù)屬徥�敗。同樣的道理，�?jì)數(shù)器亦可在service層實(shí)現(xiàn)。這種情況下，假設(shè)有10臺web服務(wù)器，也只會放行100 * 10 = 1000次搶購。

按商品路由：在Web層，把對同一品類商品的搶購路由到一臺service處理。在service內(nèi)，自定義mysql連接池，使對同一個(gè)商品的操作，使用同一個(gè)連接。這樣就實(shí)現(xiàn)了對同一商品的順序處理，避免了鎖競爭。

異步化：是指把購買請求的接受和處理異步化。購買請求先放到隊(duì)列中，這個(gè)過程非常高效，返回客戶信息。搶購服務(wù)訂閱消息隊(duì)列，異步處理購買請求，處理成功給用戶發(fā)消息。異步化主要解決成產(chǎn)和消費(fèi)的速度不匹配問題，由此類場景都可以采用。

對于防作弊問題，是比較容易處理的。因?yàn)樗�有的購買，都是登陸用戶的行為，可以很方便的根據(jù)用戶ID進(jìn)行過濾，只允許一個(gè)客戶購買一次。在分布式環(huán)境下，要解決如何記錄用戶ID的問題，因?yàn)橥�一個(gè)用戶可能被不同的web，不同的service處理。

全局Cache：在redis中開辟一個(gè)空間，記錄所有用戶的商品購買，處理用戶購買請求是，校驗(yàn)緩存中是否已記錄此商品的購買，如果已經(jīng)購買，則不允許。要解決重復(fù)提交的問題，可考慮分布式鎖。

用戶ID路由：參考上一節(jié)的按商品路由，我們同樣可以把對一個(gè)用戶的處理，路由到同一個(gè)Service處理，只需要做本地緩存就夠了。此種方案最大的問題是，如果服務(wù)掛了，數(shù)據(jù)就錯(cuò)亂了。

本文僅代表作者個(gè)人觀點(diǎn)，不代表SEO研究協(xié)會網(wǎng)官方發(fā)聲，對觀點(diǎn)有疑義請先聯(lián)系作者本人進(jìn)行修改，若內(nèi)容非法請聯(lián)系平臺管理員，郵箱cxb5918@163.com。更多相關(guān)資訊，請到SEO研究協(xié)會網(wǎng)bingfeng168.cn學(xué)習(xí)互聯(lián)網(wǎng)營銷技術(shù)請到巨推學(xué)院www.jutuiedu.com。

標(biāo)簽： dns dns輪詢 isp Mysql seo web服務(wù)器 電商 電商銷售 服務(wù)器 互聯(lián)網(wǎng) 腳本 數(shù)據(jù)庫 網(wǎng)絡(luò) 學(xué)習(xí)互聯(lián)網(wǎng) 應(yīng)用服務(wù)器 域名

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。