由之前的文章，我們可以看到資料庫為保證資料持久化，需要落盤，而該操作將會成為秒殺系統的瓶頸所在。那在資料庫層面如何進行優化呢，可以分為以下幾點來考慮：
庫存拆分
將同乙個商品的庫存記錄拆分為多行甚至多個表，降低併發衝突。舉乙個簡單的例子：對業務請求中的userid計算hash取模後確定查詢哪個庫那張表的哪行記錄，然後在做庫存更新操作。這樣能夠在業務層極大的降低併發衝突，不需要資料庫做相關優化，是成本較低收效較大的一種方案。但是該方案也有乙個缺點：由於同乙個商品的庫存記錄分散到了不同庫表中，那這些商品的庫存扣減速度不均衡(熱點商品在短時間內被秒光，這個問題並不嚴重)，給總庫餘額計數帶來的複雜度。同時這個優化又要求業務提前感知到哪些商品是熱點商品，並制定有針對性的拆分庫存操作。
批處理修改資料庫核心**，將相互衝突的事務，合併為乙個事務或者優化為組提交，達到批處理的效果，alisql的做法是在mysql server層識別這類update語句，將它們解析後合併成為一條sql再執行。比如10個扣減庫存語句，合併為乙個扣減庫存的語句一次性扣減數量為10，這樣相當於提高了資料庫10倍的吞吐量。
這個做法的優勢是對資料庫核心**修改不多、複雜度可控，劣勢是只能在特定語句的基礎上進行優化，沒有比較好的普適性。
請求排隊
在資料庫核心層面引入上述「批處理」的優化後，對熱點資料的併發扣減庫存業務仍然會面臨多個事務併發進入臨界區的情況，併發等鎖的事務會佔據寶貴的連線和執行緒資源。為避免併發事務因搶占鎖而造成的資源浪費，可以在資料庫核心層面將衝突事務排到乙個佇列處理，這樣就可以解決併發衝突，降低系統負載。
儲存過程或類似命令
業務複雜的場景裡，乙個事務往往可能包含多個語句，這樣就會擴大臨界區，嚴重影響併發度。乙個最有效的方案是資料庫層面支援儲存過程，多個語句放在儲存過程裡一次性提交給資料庫；但是mysql並不支援儲存過程，因此可以針對具體場景引入一些類似儲存過程的優化，當然核心仍然是將乙個事務中的多條語句合併，實現與資料庫在一次互動中完成。比如alisql的commit on success，可以用在扣減庫存+生成訂單的場景中，即開啟事務後先執行幾乎沒有併發衝突的insert語句生成訂單，然後帶上commit on success標記執行扣減庫存命令，庫存扣減成功後就立即提交事務，不需要等待客戶端再發commit，這樣一來熱點行衝突的臨界區仍然與單行事務一樣了。
秒殺系統 mysql 秒殺系統之資料庫
秒殺系統的資料庫中的庫存加減操作是最為關鍵的點。12年天貓雙十一的超賣事件，對平台的負面影響是非常巨大的。資料庫裡做庫存扣減，簡單的可以用以下sql來說明 update stock table set inventory inventory 1 where item id xx and invent...
秒殺 秒殺系統 優化之路
1 im系統，例如qq或者微博，每個人都讀自己的資料 好友列表 群列表 個人資訊 2 微博系統，每個人讀你關注的人的資料，乙個人讀多個人的資料 3 秒殺系統，庫存只有乙份，所有人會在集中的時間讀和寫這些資料，多個人讀乙個資料。例如 小公尺手機每週二的秒殺，可能手機只有1萬部，但瞬時進入的流量可能是幾...
秒殺系統思路
隨著電商的發展，秒殺系統已經發展成為電商必不可少的組成部分，如小公尺手機的秒殺，12306的搶票，這些系統的共同特點都是 庫存只有乙份，瞬時流量非常大，所有人會在集中的時間讀和寫這些資料，多個人讀乙個資料 讀寫衝突，鎖非常嚴重，這是秒殺業務難的地方。那我們怎麼構建秒殺業務的架構呢？構建架構需要總體做...