互聯網大潮下，電商洶涌，交易中的秒殺/超賣成了技術人員經常碰到技術問題。
秒殺/超賣首先可以從業務上來解決。比如，先抽獎事後再開獎。如果業務不能避免，那麼只能通過技術手段了。
針對核心的庫存部分，有這麼幾種方法。
第一個方式是利用數據庫的事務串行和行級鎖，輔以正確的sql語句。比如update resource_tbl set num=num-1 where id=1 AND num>0
這種方式可以通過應用層的分組隊列等，減輕數據層的壓力，以便提高性能。參考淘寶丁奇的"秒殺場景下mysql的低效原因和改進"。淘寶有自己定製版的mysql數據庫，還可以做到合併提交。可以看看這裏(http://blog.csdn.net/jiao_fuyou/article/details/15504777)，他對丁奇的ppt做了一些解釋以及可能的方案。
第二個方式是利用先進先出的隊列。所有的請求都進入隊列，在數據庫層面請求是依次處理，先到的能秒成。
第三個方式，考慮到把所有的購買相關步驟(查看 下單 確認購買)移出數據庫，只在cache中進行，最後纔會更新到數據。這樣就需要保證cache如果down了能恢復（比如記日誌，不過這種涉及到IO的也會影響性能了）。淘寶有tair，可以做試試。(參考http://wenku.baidu.com/view/fc92f6bdfd0a79563c1e7252.html)
除了庫存部分外，對這個問題有綜合論述，可以參考"如何解決秒殺的性能問題和超賣的討論"(http://www.cnblogs.com/billyxp/p/3701124.html)，
【內存】+【排隊】，還考慮前端的一些減壓措施。比如【擴容】【靜態化】【限流】【有損服務】
這個"淘寶秒殺服務器架構猜想"(http://blog.jimeji.com/?p=691)也是不錯的參考，他的基本思路是在java後端分層過濾減壓。web服務器有多個，每個的servlet裏或是業務處理模塊，都做一個各自獨立的計數（無耦合），超過總數即被過濾；第二層是利用共享的memcache(其有原子操作)的計數，超過總數即被過濾；最後纔是app層，實際會如上述的庫存管理。
安全起見，秒殺的服務器最好和其他的常規服務分開。
其他可以參考的秒殺文章鏈接
http://www.chepoo.com/seckill-system-design-and-implementation.html