秒殺或搶購活動一般會經過【預約】【搶訂單】【支付】這3個大環節，而其中【搶訂單】這個環節是最考驗業務提供方的抗壓能力的。
搶訂單環節一般會帶來2個問題：
1、高併發
2、超賣
任何商品都會有數量上限，如何避免成功下訂單買到商品的人數不超過商品數量的上限，這是每個搶購活動都要面臨的難題。
擴容：加機器，這是最簡單的方法，通過增加前端池的整體承載量來扛峰值。
限流：一般都會採用ip級別的限流，即針對某乙個ip限制單位時間內發起的請求數量，或者活動入口的時候增加遊戲或者
問題環節進行銷峰操作。
靜態化：將活動頁面中所有的可靜態化元素全部靜態化，並儘量減少動態元素，通過cnn（加速伺服器）來扛峰值。
2）後端：
記憶體：將庫存從mysql前移到redis中，所有的讀寫操作放到記憶體中，由於redis中沒有鎖，所以不會存在相互等待，並且
redis的讀寫效能都遠高於mysql，這就解決了效能問題。
排隊：引入佇列，然後將所有寫db操作在單佇列中排隊，完全序列處理。當達到庫存閥值的時候就不在消費佇列，並關閉購買功能。這就解決了超賣問題。
如何解決高併發，秒殺問題
相信不少人會被這個問題困擾，分享大家一篇這樣的文章，希望能夠幫到你！一 秒殺業務為什麼難做？1 im系統，例如qq或者微博，每個人都讀自己的資料 好友列表 群列表 個人資訊 2 微博系統，每個人讀你關注的人的資料，乙個人讀多個人的資料 3 秒殺系統，庫存只有乙份，所有人會在集中的時間讀和寫這些資料，...
如何解決秒殺的效能問題和超賣的討論
最近業務試水電商，接了乙個秒殺的活。之前經常看到 的同行們討論秒殺，討論電商，這次終於輪到我們自己理論結合實際一次了。ps 進入正文前先說一點個人感受，之前看 的ppt感覺都懂了，等到自己出解決方案的時候發現還是有很多想不到的地方其實都沒懂，再次驗證了 細節是魔鬼 的理論。並且乙個人的能力有限，只有...
如何解決秒殺的效能問題和超賣的討論
最近業務試水電商，接了乙個秒殺的活。之前經常看到 的同行們討論秒殺，討論電商，這次終於輪到我們自己理論結合實際一次了。ps 進入正文前先說一點個人感受，之前看 的ppt感覺都懂了，等到自己出解決方案的時候發現還是有很多想不到的地方其實都沒懂，再次驗證了 細節是魔鬼 的理論。並且乙個人的能力有限，只有...