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

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

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

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

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

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

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

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

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

瀏覽器訪問攔截：產(chǎn)品層面，當(dāng)用戶點擊查詢或購買按鈕后，按鈕置灰，防止用戶重復(fù)提交數(shù)據(jù)。js層面，限制用戶在限定時間內(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ù)器上，用戶訪問時，那臺服務(wù)器近訪問到的就是那臺服務(wù)器上的數(shù)據(jù)。CDN的劣勢是內(nèi)容的變更生效慢，所以僅適用于“幾乎不變”的資源，例如引用的js包，圖片等。

動靜分離與反向代理層訪問攔截：動態(tài)頁面是指根據(jù)實時數(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ā)布商品信息時，就保存下商品信息的靜態(tài)頁面，訪問時只需要讀取一個文件就夠了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

標簽： 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)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。