網際網路大潮下，電商洶湧，交易中的秒殺/超賣成了技術人員經常碰到技術問題。
秒殺/超賣首先可以從業務上來解決。比如，先**事後再開獎。如果業務不能避免，那麼只能通過技術手段了。
針對核心的庫存部分，有這麼幾種方法。
第乙個方式是利用資料庫的事務序列和行級鎖，輔以正確的sql語句。比如update resource_tbl set num=num-1 where id=1 and num>0
這種方式可以通過應用層的分組佇列等，減輕資料層的壓力，以便提高效能。參考**丁奇的"秒殺場景下mysql的低效原因和改進"。**有自己定製版的mysql資料庫，還可以做到合併提交。可以看看這裡(他對丁奇的ppt做了一些解釋以及可能的方案。
第二個方式是利用先進先出的佇列。所有的請求都進入佇列，在資料庫層面請求是依次處理，先到的能秒成。
第三個方式，考慮到把所有的購買相關步驟(檢視 下單 確認購買)移出資料庫，只在cache中進行，最後才會更新到資料。這樣就需要保證cache如果down了能恢復（比如記日誌，不過這種涉及到io的也會影響效能了）。**有tair，可以做試試。(參考
除了庫存部分外，對這個問題有綜合論述，可以參考"如何解決秒殺的效能問題和超賣的討論"( 【記憶體】+【排隊】，還考慮前端的一些減壓措施。比如【擴容】【靜態化】【限流】【有損服務】
安全起見，秒殺的伺服器最好和其他的常規服務分開。
秒殺超賣問題
秒殺問題其實就是併發讀寫的問題，需要解決超賣，效率等問題。可以使用redis將秒殺的資料進行快取，通過啟用定時任務，當redis中的庫存為0時將，快取持久化到資料庫中，並且將redis中的快取清除掉。service slf4j public class orderserviceimpl extend...
2 秒殺專案架構分析
架構 構思 認清形勢 使用者 超大量 正常 壞人 地域 全國各地 解釋 因為網路的請求來自各個地方 為了降低網路傳輸的延時 我們都用cdn網路 提前將我們的服務傳送到離使用者最近的那個伺服器上 由此大大減少不同地域網路訪問的差距 也相當於起到了乙個分流的作用 業務流程 前台 商品展示 登記 後台 資...
Redis 秒殺系統分析需求
如圖所示，第一層是前端攔截層 第二層是閘道器處理層 第三層是業務邏輯層 第四層是db入庫。在第三層中我們會用到redis，這篇部落格是秒殺系統中的redis的應用場景，所以這篇部落格主要講解業務邏輯層。簡單講一件閘道器處理層的實現，閘道器處理層主要處理後端流量資料的攔截，比如說我們有幾十萬的使用者同...