秒殺 URL 的設(shè)計(jì)

為了避免有程序訪問(wèn)經(jīng)驗(yàn)的人通過(guò)下單頁(yè)面url直接訪問(wèn)后臺(tái)接口來(lái)秒殺貨品，我們需要將秒殺的 URL 實(shí)現(xiàn)動(dòng)態(tài)化，即使是開(kāi)發(fā)整個(gè)系統(tǒng)的人都無(wú)法在秒殺開(kāi)始前知道秒殺的URL 。具體的做法就是通過(guò) md5 加密一串隨機(jī)字符作為秒殺的 URL，然后前端訪問(wèn)后臺(tái)獲取具體的 URL，后臺(tái)校驗(yàn)通過(guò)之后才可以繼續(xù)秒殺。

秒殺頁(yè)面靜態(tài)化

單體 Redis 升級(jí)為集群 Redis

使用 Nginx

精簡(jiǎn) SQL

Redis 預(yù)減庫(kù)存

接口限流

秒殺最終的本質(zhì)是數(shù)據(jù)庫(kù)的更新，但是有很多大量無(wú)效的請(qǐng)求，我們最終要做的就是如何把這些無(wú)效的請(qǐng)求過(guò)濾掉，防止?jié)B透到數(shù)據(jù)庫(kù)。限流的話，需要入手的方面很多：

同一個(gè)用戶(hù)xx秒內(nèi)重復(fù)請(qǐng)求直接拒絕

令牌桶算法限流

可以看到任務(wù)執(zhí)行的過(guò)程中，第1個(gè)是無(wú)需等待的，因?yàn)橐呀?jīng)在開(kāi)始的第1秒生產(chǎn)出了令牌。接下來(lái)的任務(wù)請(qǐng)求就必須等到令牌桶產(chǎn)生了令牌才可以繼續(xù)往下執(zhí)行。如果沒(méi)有獲取到就會(huì)阻塞（有一個(gè)停頓的過(guò)程）。不過(guò)這個(gè)方式不太好，因?yàn)橛脩?hù)如果在客戶(hù)端請(qǐng)求，如果較多的話，直接后臺(tái)在生產(chǎn)token就會(huì)卡頓（用戶(hù)體驗(yàn)較差），它是不會(huì)拋棄任務(wù)的，我們需要一個(gè)更優(yōu)秀的策略：如果超過(guò)某個(gè)時(shí)間沒(méi)有獲取到，直接拒絕該任務(wù)。接下來(lái)再來(lái)個(gè)案例：

其中用到了tryAcquire方法，這個(gè)方法的主要作用是設(shè)定一個(gè)超時(shí)的時(shí)間，如果在指定的時(shí)間內(nèi)預(yù)估（注意是預(yù)估并不會(huì)真實(shí)的等待），如果能拿到令牌就返回true，如果拿不到就返回false。然后我們讓無(wú)效的直接跳過(guò)，這里設(shè)定每秒生產(chǎn)1個(gè)令牌，讓每個(gè)任務(wù)嘗試在0.5秒獲取令牌，如果獲取不到，就直接跳過(guò)這個(gè)任務(wù)（放在秒殺環(huán)境里就是直接拋棄這個(gè)請(qǐng)求）。程序?qū)嶋H運(yùn)行如下：

只有第1個(gè)獲取到了令牌，順利執(zhí)行了，下面的基本都直接拋棄了，因?yàn)?.5秒內(nèi)，令牌桶（1秒1個(gè)）來(lái)不及生產(chǎn)就肯定獲取不到返回false了。

這個(gè)限流策略的效率有多高呢？假如我們的并發(fā)請(qǐng)求是400萬(wàn)瞬間的請(qǐng)求，將令牌產(chǎn)生的效率設(shè)為每秒20個(gè)，每次嘗試獲取令牌的時(shí)間是0.05秒，那么最終測(cè)試下來(lái)的結(jié)果是，每次只會(huì)放行4個(gè)左右的請(qǐng)求，大量的請(qǐng)求會(huì)被拒絕，這就是令牌桶算法的優(yōu)秀之處。

異步下單

為了提升下單的效率，并且防止下單服務(wù)的失敗。需要將下單這一操作進(jìn)行異步處理。最常采用的辦法是使用隊(duì)列，隊(duì)列最顯著的三個(gè)優(yōu)點(diǎn)：異步、削峰、解耦。這里可以采用 RabbitMQ，在后臺(tái)經(jīng)過(guò)了限流、庫(kù)存校驗(yàn)之后，流入到這一步驟的就是有效請(qǐng)求。然后發(fā)送到隊(duì)列里，隊(duì)列接受消息，異步下單。下完單，入庫(kù)沒(méi)有問(wèn)題可以用短信通知用戶(hù)秒殺成功。假如失敗的話，可以采用補(bǔ)償機(jī)制，重試。

服務(wù)降級(jí)

假如在秒殺過(guò)程中出現(xiàn)了某個(gè)服務(wù)器宕機(jī)，或者服務(wù)不可用，應(yīng)該做好后備工作。之前的博客里有介紹通過(guò)Hystrix進(jìn)行服務(wù)熔斷和降級(jí)，可以開(kāi)發(fā)一個(gè)備用服務(wù)，假如服務(wù)器真的宕機(jī)了，直接給用戶(hù)一個(gè)友好的提示返回，而不是直接卡死，服務(wù)器錯(cuò)誤等生硬的反饋。

總結(jié)

秒殺流程圖：

這就是我設(shè)計(jì)出來(lái)的秒殺流程圖，當(dāng)然不同的秒殺體量針對(duì)的技術(shù)選型都不一樣，這個(gè)流程可以支撐起幾十萬(wàn)的流量，如果是成千萬(wàn)破億那就得重新設(shè)計(jì)了。比如數(shù)據(jù)庫(kù)的分庫(kù)分表、隊(duì)列改成用Kafka、Redis增加集群數(shù)量等手段。通過(guò)本次設(shè)計(jì)主要是要表明的是我們?nèi)绾螒?yīng)對(duì)高并發(fā)的處理，并開(kāi)始嘗試解決它，在工作中多思考、多動(dòng)手能提升我們的能力水平，加油！如果本篇博客有任何錯(cuò)誤，請(qǐng)麻煩指出來(lái)，不勝感激。

來(lái)源：https://www.cnblogs.com/wyq178/p/11261711.html

文章轉(zhuǎn)載：高效運(yùn)維
（版權(quán)歸原作者所有，侵刪）