亚洲综合精品伊人久久,精品无码一区二区三区电影

當前位置：首頁行業(yè)新聞如何設計一個高可用、高并發(fā)秒殺系統(tǒng)？

如何設計一個高可用、高并發(fā)秒殺系統(tǒng)？

2021-06-15 14:24:57 瀏覽：7481

如今的互聯(lián)網(wǎng)已經在海量服務領域有了很成熟的理論，在電商領域，存在著典型的秒殺業(yè)務場景，那何謂秒殺場景呢？簡單的來說就是一件商品的購買人數(shù)遠遠大于這件商品的庫存，而且這件商品在很短的時間內就會被搶購一空。

高并發(fā)的接口/系統(tǒng)有一個共同的特性，那就是”快”。在系統(tǒng)其它條件既定的情況下，系統(tǒng)處理請求越快，用戶得到反饋的時間就越短，單位時間內服務器能夠處理請求的數(shù)量就會越多。所以”快”幾乎可以算是高并發(fā)系統(tǒng)的要滿足的必要條件，要評估一個系統(tǒng)性能如何，某次優(yōu)化是否提高系統(tǒng)的容量，”快”是一個很直觀的衡量標準。

那么如何設計一個高可用、高并發(fā)秒殺系統(tǒng)呢？

秒殺系統(tǒng)一般設計思路

秒殺系統(tǒng)的特點是：

§ 瞬時請求量很高

§ 持續(xù)時間較短

所以秒殺系統(tǒng)需要解決的是「在高并發(fā)情況下，用戶請求及數(shù)據(jù)更新的問題」！

一般的設計思路：

§ （變相）擴容

§ 提高性能

具體方式有：

動靜分離

對于一般的應用來說，請求流程大致如下：

§ 服務端接收到請求，從數(shù)據(jù)庫中查詢相應數(shù)據(jù)

§ 選擇對應的展示模板

§ 通過模板和數(shù)據(jù)渲染出最終頁面

§ 將頁面返回給客戶端

當訪問量很大的時候，服務器壓力會非常的大！解決方案就是動靜分離！

做軟件開發(fā)的都知道要「將變化的內容和不變的內容隔離開」，以便于獨立進化。這里其實也是一樣的思路。

模板是個靜態(tài)的內容，部署后一般是不會變化的；而數(shù)據(jù)是個相對動態(tài)的內容，根據(jù)請求參數(shù)的不同，數(shù)據(jù)可能不同。所以我們需要將模板與數(shù)據(jù)分離。

以前的做法是后端事先生成渲染后的頁面，緩存起來或直接部署到靜態(tài)服務器或CDN，請求時直接從緩存（靜態(tài)服務器/CDN）中獲取頁面，而動態(tài)數(shù)據(jù)通過AJAX請求的方式獲取。服務器不再需要渲染頁面，只需要返回少量的數(shù)據(jù)即可。既降低了服務器壓力，又減少了服務端數(shù)據(jù)的傳輸。

而現(xiàn)在很流行的前后端分離就能很容易的解決這個問題。頁面獨立部署，數(shù)據(jù)異步獲取，頁面渲染由瀏覽器負責。這里和普通的前后端分離還有些差異，需要將相對靜態(tài)的數(shù)據(jù)都靜態(tài)化，以減少動態(tài)數(shù)據(jù)量。

分離后，靜態(tài)內容和動態(tài)內容就可以獨立進化。例如靜態(tài)內容可以部署到CDN上，用戶可以從最近的服務器獲取到數(shù)據(jù)。相對熱點的動態(tài)數(shù)據(jù)可以做緩存，降低數(shù)據(jù)庫壓力，進一步提高服務端響應。

獨立部署

「獨立部署」其實也可以看成是一種「動靜分離」。將秒殺系統(tǒng)這個相對動態(tài)的系統(tǒng)，和相對靜態(tài)的業(yè)務系統(tǒng)分開部署。

原因很好理解，秒殺系統(tǒng)的請求量很大，可能會由于預估不足或系統(tǒng)問題，導致了秒殺系統(tǒng)的負載過高、響應變慢。如果秒殺系統(tǒng)是業(yè)務系統(tǒng)的一部分，則會導致業(yè)務系統(tǒng)響應變慢，甚至導致系統(tǒng)沒有響應。且秒殺是個短期活動也不是核心業(yè)務，而業(yè)務系統(tǒng)是需要長期穩(wěn)定運行的。不能因為一個短期非核心的活動，而影響了核心的業(yè)務系統(tǒng)。

所以秒殺系統(tǒng)最好和業(yè)務系統(tǒng)分開獨立部署。即使秒殺系統(tǒng)掛了，也不會影響業(yè)務系統(tǒng)的正常對外服務。

同樣的道理，秒殺系統(tǒng)的數(shù)據(jù)庫也需要和業(yè)務系統(tǒng)的數(shù)據(jù)庫獨立開。

限流削峰

動靜分離，獨立部署能提高系統(tǒng)的響應能力和容量。但是可提供的訪問量是一定的，當超過了系統(tǒng)所能承受的容量，該怎么辦呢？你可能會說，可以擴容啊。的確是可以，但是擴容也是有限度的。假設單機能承受10萬的請求量，預計有1億的請求量，你要擴容1000臺服務器？！這會導致嚴重的浪費。

首先，上面提到了，秒殺是短期活動，為了秒殺多部署1000臺服務器，秒殺結束后這些服務器再銷毀？既浪費硬件資源、又浪費人力資源。

其次，秒殺的商品數(shù)量其實并不多，可能秒殺賺的那點錢還不夠付服務器和帶寬的費用。真·花錢賺吆喝！

我們該如何處理呢？

上面說了，秒殺的商品數(shù)量不多，也就是說，其實最后的真實成交量并不大。再進一步講，很多的請求都是沒用的。

其次，在秒殺前，買家會頻繁的刷頁面，這又額外增加了無用請求的數(shù)量。

我們只要把這些無用的請求提前都過濾掉，最終到達服務端的請求就會少很多，也就不需要這么多的服務器了。這就是限流削峰。具體做法有很多：

§ 秒殺時間未到時，秒殺按鈕置灰：也就是說在秒殺未到時間時，不可發(fā)送下單請求。前面我們已經將頁面靜態(tài)化，分發(fā)到了CDN，所以用戶的刷新操作只會到CDN。這就削除了刷新操作導致的請求。

§ 秒殺按鈕點擊后置灰：即避免double-click，一個用戶只能點擊一次。限制用戶點擊次數(shù)，避免秒殺工具帶來過量無效請求。

§ 秒殺前先做題：即在秒殺前需要先做題目，類似驗證碼功能，其實是降低了用戶的點擊頻率，也限制了秒殺工具的使用。不過體驗不好，不推薦使用。

§ 限制請求次數(shù)：可以用js判定，限制用戶多少時間間隔內，只能請求多少次。在代理層也可以基于ip做次數(shù)限制，限制單ip的請求數(shù)量。

§ 直接跳轉：假設秒殺已結束或秒殺隊列已滿，對后續(xù)的請求，直接跳轉到秒殺結束頁面。請求不再到達服務端。

§ 請求排隊：通過消息隊列、內存排隊等手段，對請求進行排隊。類似EDA、Reactor。當隊列滿了以后，可拒絕后續(xù)請求。

服務端優(yōu)化

上面的「請求排隊」，可以做在web服務層，也可以在服務端處理，亦可以兩處都處理。除了排隊，服務端的優(yōu)化的核心手段就是緩存，盡量減少到數(shù)據(jù)庫的數(shù)據(jù)訪問，將熱點數(shù)據(jù)緩存起來。

更極致的優(yōu)化可能還涉及到：

§ 減少序列化：大家都知道Java序列化和反序列化都是比較耗時的操作，即使使用第三方的序列化工具，也是需要消耗時間的，盡量減少序列化操作，能減少這部分的時間消耗

§ 不要使用框架：現(xiàn)在一般開發(fā)都會使用框架開發(fā)，例如SpringMVC。SpringMVC使用了前端控制器，還包括很多的Filter，攔截器等，額外的增加了請求時間。使用純Servlet，能降低此部分的時間消耗。因為畢竟秒殺邏輯簡單，用不用框架，開發(fā)效率影響不大。

§ 使用字節(jié)流：即使用InputStream、OutputStream，不要使用Writer,Reader。與「減少序列化」類似，編解碼也會消耗時間。

另外還有扣庫存邏輯處理：

§ 拍下減庫存：用戶搶到后即扣除庫存，但是如果用戶搶到了不付款，最后秒殺的商品可能實際并沒有賣出去。

§ 付款減庫存：到用戶付款后才去扣庫存。這可能導致下單數(shù)量遠超商品數(shù)量。導致的問題是，要么后付款的買家被提示付款失敗。要么就是超賣。

§ 預扣庫存：用戶搶到即扣除庫存。規(guī)定時間內沒有付款則取消訂單，恢復庫存。這個是常用手段

上面說的秒殺系統(tǒng)的一般設計思路。然后我們就要來考慮秒殺系統(tǒng)的公平性！

公平？公平！

習慣性的思維告訴我們先到先得原則，即優(yōu)先到達的請求，優(yōu)先排隊下單。這就導致，在秒殺結束前或請求被處理前，都需要等待，直到服務器處理后才有返回。

這明顯增加了服務端的壓力，這也是導致的吞吐性能被嚴重影響到。但不是根本原因。

根本原因是這樣做就真的公平嗎？！這就要看每個人對公平的理解了！我認為這世上「沒有絕對的公平，只有相對的公平」！

你在秒殺系統(tǒng)里排隊，保證先到先得，這就是公平嗎？

§ 如果一個買家是1M帶寬，另一個買家是100M光纖，他們同時秒殺，你能保證公平嗎？