轉(zhuǎn)載自?秒殺系統(tǒng)設(shè)計的 5 個要點：前端三板斧＋后端兩條路

• 高并發(fā)，cache，鎖機制

• 基于緩存架構(gòu)redis,Memcached的先進先出隊列。

• 稍微大一點的秒殺，肯定是分布式的集群的，并發(fā)來自于多個節(jié)點的JVM，synchronized所有在JVM上加鎖是不行了

• 數(shù)據(jù)庫壓力

• 秒殺超賣問題

• 如何防止用戶來刷， 黑名單？IP限制？

• 利用memcached的帶原子性特性的操作做并發(fā)控制

秒殺簡單設(shè)計方案

比如有10件商品要秒殺，可以放到緩存中，讀寫時不要加鎖。 當并發(fā)量大的時候，可能有25個人秒殺成功，這樣后面的就可以直接拋秒殺結(jié)束的靜態(tài)頁面。進去的25個人中有15個人是不可能獲得商品的。所以可以根據(jù)進入的先后順序只能前10個人購買成功。后面15個人就拋商品已秒殺完。

假設(shè)我們的秒殺場景

比如某商品10件物品待秒. 假設(shè)有100臺web服務(wù)器(假設(shè)web服務(wù)器是Nginx + Tomcat),n臺app服務(wù)器,n個數(shù)據(jù)庫

第一步 如果Java層做過濾, 可以在每臺web服務(wù)器的業(yè)務(wù)處理模塊里做個計數(shù)器AtomicInteger(10)=待秒商品總數(shù),decreaseAndGet()>＝0的繼續(xù)做后續(xù)處理, <0的直接返回秒殺結(jié)束頁面，這樣經(jīng)過第一步的處理只剩下100臺*10個=1000個請求。

第二步, memcached 里以商品id作為key的value放個10, 每個web服務(wù)器在接到每個請求的同時, 向memcached服務(wù)器發(fā)起請求, 利用memcached的decr(key,1)操作返回值>=0的繼續(xù)處理, 其余的返回秒殺失敗頁面，這樣經(jīng)過第二步的處理只剩下100臺中最快速到達的10個請求。

第三步, 向App服務(wù)器發(fā)起下單操作事務(wù)。

第四步, App服務(wù)器向商品所在的數(shù)據(jù)庫請求減庫存操作(操作數(shù)據(jù)庫時可以 "update table set count=count-1 where id=商品id and count>0;" update 成功記錄數(shù)為1, 再向訂單數(shù)據(jù)庫添加訂單記錄, 都成功后提交整個事務(wù), 否則的話提示秒殺失敗，用戶進入支付流程。

看看淘寶的秒殺

一、前端

面對高并發(fā)的搶購活動，前端常用的三板斧是【擴容】【靜態(tài)化】【限流】

• 擴容：加機器，這是最簡單的方法，通過增加前端池的整體承載量來抗峰值。

• 靜態(tài)化：將活動頁面上的所有可以靜態(tài)的元素全部靜態(tài)化，并盡量減少動態(tài)元素。通過CDN來抗峰值。

• 限流：一般都會采用IP級別的限流，即針對某一個IP，限制單位時間內(nèi)發(fā)起請求數(shù)量。或者活動入口的時候增加游戲或者問題環(huán)節(jié)進行消峰操作。

• 有損服務(wù)：最后一招，在接近前端池承載能力的水位上限的時候，隨機拒絕部分請求來保護活動整體的可用性。

二、那么后端的數(shù)據(jù)庫在高并發(fā)和超賣下會遇到什么問題呢

• 首先MySQL自身對于高并發(fā)的處理性能就會出現(xiàn)問題，一般來說，MySQL的處理性能會隨著并發(fā)thread上升而上升，但是到了一定的并發(fā)度之后會出現(xiàn)明顯的拐點，之后一路下降，最終甚至?xí)葐蝨hread的性能還要差。

• 其次，超賣的根結(jié)在于減庫存操作是一個事務(wù)操作，需要先select，然后insert，最后update -1。最后這個-1操作是不能出現(xiàn)負數(shù)的，但是當多用戶在有庫存的情況下并發(fā)操作，出現(xiàn)負數(shù)這是無法避免的。

• 最后，當減庫存和高并發(fā)碰到一起的時候，由于操作的庫存數(shù)目在同一行，就會出現(xiàn)爭搶InnoDB行鎖的問題，導(dǎo)致出現(xiàn)互相等待甚至死鎖，從而大大降低MySQL的處理性能，最終導(dǎo)致前端頁面出現(xiàn)超時異常。

針對上述問題，如何解決呢？ 淘寶的高大上解決方案：

I：關(guān)閉死鎖檢測，提高并發(fā)處理性能。

II：修改源代碼，將排隊提到進入引擎層前，降低引擎層面的并發(fā)度。

III：組提交，降低server和引擎的交互次數(shù)，降低IO消耗。

解決方案1：將存庫從MySQL前移到Redis中，所有的寫操作放到內(nèi)存中，由于Redis中不存在鎖故不會出現(xiàn)互相等待，并且由于Redis的寫性能和讀性能都遠高于MySQL，這就解決了高并發(fā)下的性能問題。然后通過隊列等異步手段，將變化的數(shù)據(jù)異步寫入到DB中。

優(yōu)點：解決性能問題

缺點：沒有解決超賣問題，同時由于異步寫入DB，存在某一時刻DB和Redis中數(shù)據(jù)不一致的風(fēng)險。

解決方案2：引入隊列，然后將所有寫DB操作在單隊列中排隊，完全串行處理。當達到庫存閥值的時候就不在消費隊列，并關(guān)閉購買功能。這就解決了超賣問題。

優(yōu)點：解決超賣問題，略微提升性能。

缺點：性能受限于隊列處理機處理性能和DB的寫入性能中最短的那個，另外多商品同時搶購的時候需要準備多條隊列。

解決方案3：將寫操作前移到MC中，同時利用MC的輕量級的鎖機制CAS來實現(xiàn)減庫存操作。

優(yōu)點：讀寫在內(nèi)存中，操作性能快，引入輕量級鎖之后可以保證同一時刻只有一個寫入成功，解決減庫存問題。

缺點：沒有實測，基于CAS的特性不知道高并發(fā)下是否會出現(xiàn)大量更新失敗？不過加鎖之后肯定對并發(fā)性能會有影響。

解決方案4：將提交操作變成兩段式，先申請后確認。然后利用Redis的原子自增操作，同時利用Redis的事務(wù)特性來發(fā)號，保證拿到小于等于庫存閥值的號的人都可以成功提交訂單。然后數(shù)據(jù)異步更新到DB中。

優(yōu)點：解決超賣問題，庫存讀寫都在內(nèi)存中，故同時解決性能問題。

缺點：由于異步寫入DB，可能存在數(shù)據(jù)不一致。另可能存在少買，也就是如果拿到號的人不真正下訂單，可能庫存減為0，但是訂單數(shù)并沒有達到庫存閥值。

總結(jié)

1、前端三板斧【擴容】【限流】【靜態(tài)化】

2、后端兩條路【內(nèi)存】+【排隊】

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的秒杀系统设计的 5 个要点：前端三板斧＋后端两条路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。