超賣問題和高併發問題

超賣問題：成功下訂單買到商品的人數，超過資料庫最大庫存數量。

答：將存庫從mysql前移到redis中，所有的寫操作放到記憶體型資料庫中。

由於redis中[預設情況下]不存在鎖,故不會出現互相等待，並且由於redis的寫效能和讀效能都遠高於mysql，這就解決了高併發下的效能問題。然後通過佇列等非同步手段，將變化的資料非同步寫入到db中。

缺點：沒有解決超賣問題，同時由於非同步寫入db，存在某一時刻db和redis中資料不一致的風險。

答：將所有寫db操作在單佇列中排隊，完全序列處理。當達到庫存閾值的時候就不再消費佇列，並關閉購買功能。這就解決了超賣問題。

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

答：mysql的二段式提交將提交操作變成兩段式，先申請後確認。

然後利用redis的原子自增操作，同時利用redis的事務特性來發號[watch 樂觀鎖]，保證拿到小於等於庫存閾值的號的人都可以成功提交訂單。然後資料非同步更新到db中。

缺點：由於非同步寫入db，可能存在資料不一致。另可能存在少買，也就是如果拿到號的人不真正下訂單，可能庫存減為0，但是訂單數並沒有達到庫存閾值

1.排隊：

可以使用訊息佇列，將同步請求轉化成非同步請求，中間通過乙個訊息佇列在一端[佇列入口]承接瞬時的流量峰值，在另一端[佇列出口]平滑的將訊息推送出去

2.設定關卡：

在活動入口的地方設定關卡遊戲或者問題環節，削弱峰值

3.分層過濾：

秒殺請求先經過cdn ==> 前端系統 ==> 後端系統 過濾掉無效請求

Redis高併發問題

商品搶購秒殺等活動 使用redis列表結構實現佇列資料結構,強拆的用rpush入隊,再用lpop出隊.redis宕機或者連線不上 解決方法 配置主從複製，配置哨兵模式，一旦發現主機宕機，讓下乙個從機當做主機。最壞的情況，只能關閉redis連線，去往資料庫連線。但由於資料量大，這樣sql資料庫也會宕掉...

nodejs處理高併發問題

做了乙個nodejs併發測試，先描述一下環境 資料庫mysql,大概兩張表，讀取第一張表test的資料，拿出來 1，存到第二張testlog表記錄一下，用jmeter同事模擬50個請求，結果發現，部分資料沒有 1成功 test 表資料id num desc 1942017 02 2814 41 17...

電商系列 mysql高併發超庫存賣問題

先來就庫存超賣的問題作描述 一般電子商務 都會遇到如 秒殺 之類的活動，而這樣的活動有乙個共同的特點就是訪問量激增 上千甚至上萬人搶購乙個商品。然而，作為活動商品，庫存肯定是很有限的，如何控制庫存不讓出現超買，以防止造成不必要的損失是眾多電子商務 程式設計師頭疼的問題，這同時也是最基本的問題。從技術...