5、伺服器解決效能瓶頸問題
2.超賣: 成功下訂單買到商品的人數，超過資料庫最大庫存數量
a 擴容：
加機器，這是最簡單的方法，通過增加前端池的整體承載量來抗峰值。
b 靜態化：
將頁面能夠靜態化的元素全部靜態化，並減少動態元素，通過cdn加速來抗峰值 [內容分 發網路,快取伺服器]
c 限流:
ip限流.針對某乙個ip位址，限制單位時間內訪問次數 [防止黃牛刷單]
d：其他
在活動入口的地方設定關卡遊戲或者問題環節，削弱峰值
i：首先mysql自身對於高併發的處理效能就會出現問題，一般來說，mysql的處理效能會隨著併發thread上公升而上公升，但是到了一定的併發度之後會出現明顯的拐點，之後一路下降，最終甚至會比單thread的效能還要差。
ii：其次，超賣的根結在於減庫存操作是乙個事務操作，需要先select，然後insert，最後update -1。最後這個-1操作是不能出現負數的，但是當多使用者在有庫存的情況下併發操作，出現負數這是無法避免的。
iii：最後，當減庫存和高併發碰到一起的時候，由於操作的庫存數目在同一行，就會出現爭搶innodb行鎖的問題，導致出現互相等待甚至死鎖，從而大大降低mysql的處理效能，最終導致前端頁面出現超時異常。解決方案1：
由於redis中[預設情況下]不存在鎖,故不會出現互相等待，並且由於redis的寫效能和讀效能都遠高於mysql，這就解決了高併發下的效能問題。然後通過佇列等非同步手段，將變化的資料非同步寫入到db中。解決方案2：優點：
解決效能問題缺點：
沒有解決超賣問題，同時由於非同步寫入db，存在某一時刻db和redis中資料不一致的風險。將所有寫db操作在單佇列中排隊，完全序列處理。當達到庫存解決方案3：閾yù值的時候就不再消費佇列，並關閉購買功能。這就解決了超賣問題。優點：
解決超賣問題，略微提公升效能。缺點：
效能受限於佇列處理機處理效能和db的寫入效能中最短的那個，另外多商品同時搶購的時候需要準備多條佇列。然後利用redis的原子自增操作，同時利用redis的事務特性來發號[watch 樂觀鎖]，保證拿到小於等於庫存閾值的號的人都可以成功提交訂單。然後資料非同步更新到db中。優點：
解決超賣問題，庫存讀寫都在記憶體中，故同時解決效能問題。缺點：由於非同步寫入db，可能存在資料不一致。另可能存在少買，也就是如果拿到號的人不真正下訂單，可能庫存減為0，但是訂單數並沒有達到庫存閾值
1.排隊：
可以使用訊息佇列，將同步請求轉化成非同步請求，中間通過乙個訊息佇列在一端[佇列入口]承接瞬時的流量峰值，在另一端[佇列出口]平滑的將訊息推送出去
2.設定關卡：
在活動入口的地方設定關卡遊戲或者問題環節，削弱峰值
3.分層過濾：
秒殺請求先經過cdn ==
> 前端系統 ==
> 後端系統 過濾掉無效請求
高併發如何處理（架構層面）
高併發系統各不相同。比如每秒百萬併發的中介軟體系統 每日百億請求的閘道器系統 瞬時每秒幾十萬請求的秒殺大促系統。他們在應對高併發的時候，因為系統各自特點的不同，所以應對架構都是不一樣的。另外，比如電商平台中的訂單系統 商品系統 庫存系統，在高併發場景下的架構設計也是不同的，因為背後的業務場景什麼的都...
《轉》 mysql處理高併發，防止庫存超賣
今天王總又給我們上了一課，其實mysql處理高併發，防止庫存超賣的問題，在去年的時候，王總已經提過 但是很可惜，即使當時大家都聽懂了，但是在現實開發中，還是沒這方面的意識。今天就我的一些理解，整理一下這個問題，並希望以後這樣的課程能多點。先來就庫存超賣的問題作描述 一般電子商務 都會遇到如 秒殺 之...
超賣問題和高併發問題
超賣問題 成功下訂單買到商品的人數，超過資料庫最大庫存數量。答 將存庫從mysql前移到redis中，所有的寫操作放到記憶體型資料庫中。由於redis中 預設情況下 不存在鎖,故不會出現互相等待，並且由於redis的寫效能和讀效能都遠高於mysql，這就解決了高併發下的效能問題。然後通過佇列等非同步...