=====================================
網上針對“秒殺”的解決方案很多，數據拆分化解熱點，READPAST解決鎖問題，應用程序排隊限制並發等等很多方式，各有優缺點，只為證明一句名言：條條大路通羅馬。
=====================================
今天拿SQL SERVER 2014的內存表來試水“秒殺”，內存表使用“版本”解決了高並發下鎖請求和阻塞的問題，使用HASH索引來處理數據頁“熱點”的問題，解決了PAGE_LATCH等待，雖然本地編譯在本測試中效果不是那么明顯，但是聊勝於無。
由於測試代碼在別人代碼基礎上修改而來，就不拿出來共享了，具體實現思路:
1. 使用本地編譯存儲過程來封裝秒殺（實現對庫存UPDATE和對秒殺成功訂單的INSERT操作）
2. 在步驟1的基礎上封裝一層，實現重試邏輯,重試相關基礎請重擊
3. 將秒殺商品拆分到多條記錄中，避免單條記錄成為熱點
4. 將秒殺成功的訂單表設計為內存表，避免插入記錄時的PAGE_LATCH等待
=========================================
測試環境
Windows版本：Windows Server 2012 企業版
數據庫版本：SQL SERVER 2014 企業版
服務器CPU: 4個物理CPU 64個邏輯CPU
服務器內存：128GB
模擬秒殺300000商品，1200個線程模擬並發
測試結果
| 記錄數 | 耗時（毫秒） | 每秒秒殺商品數 |
| 300 | 2786 | 107681.26 |
| 100 | 3620 | 82872.93 |
| 50 | 4363 | 68760.03 |
| 20 | 5240 | 57251.91 |
| 10 | 7690 | 39011.70 |
| 5 | 12266 | 24457.85 |
| 2 | 31186 | 9619.70 |
| 1 | 69770 | 4299.84 |
以上測試結果僅供參考！
--=============================================
雖然內存表沒有鎖阻塞的情況，但是對兩個事務更新同一條數據時，只有第一個事務提交后第二個事務才能更新成功，而事務提交受日志寫入速度的影響，因此在對單條記錄或少量記錄更新的時候，磁盤單詞寫入的時間（Avg. Disk sec/Write) 至關重要，本次測試的服務器上，Avg. Disk sec/Write 平均值在0.05ms到0.09ms之間，因此理論上對單條記錄的每秒最大更新次數在1w到2w左右，這也是為什么要拆分成多條記錄的原因。
--=============================================
福利依舊是妹子
