電商系統中的下單功能的mysql架構設計

簡單的訂單業務的基本模型設計用戶、商品（庫存）、訂單、付款，這裡只考慮商品和訂單，流程是下訂單-> 減庫存，這兩步必須同時完成，不能下了訂單不減庫存（超賣），或減了庫存沒有產生訂單（少賣）。超賣商家庫存不足，消費者下了單買不到東西，體驗不好；少賣商家庫存積壓或需要反覆修改商品訊息，反覆麻煩，體驗也不好。

在系統初期，承接流量小，很多創業團隊都是單庫的模型（是的，大家都在一起。。。）。這種模型帶來了極大的方便，不用跨庫，更沒有跨節點，能夠方便的利用資料庫提供的事務來實現下單和減庫存的原子操作，還能進行各種聯表和子查詢（運營MM需求再變態，我會SQL能奈我何）。但也正是這些優點，會成為流量上來後擴展系統的絆腳石。聯表、子查詢、事務都是將多張表綁定在了一起，拆庫、拆表就麻煩了。

後期系統流量逐漸升高，單庫的讀寫效能不夠，這時候會考慮將資料庫進行拆解、分錶。例如商品和訂單分為兩個集群，集群內又根據各自業務維度進行分庫和分錶，商品可以根據賣家維度來切分，訂單一般根據買家維度切分，並且根據賣家維度做冗餘。這時候出現的問題，還是經典問題－資料一致性，資料分割後商品和訂單不在一個庫裡，怎麼保證一致性；買家維度的訂單資料怎麼和賣家維度的訂單資料保證一致性。有兩個解決想法：

    （1）分散式事務，經典的有基於2PC的實作。優點是封裝得夠好後使用起來和單庫雖然有差別（主要是複雜查詢語句），但整體來說對業務的改動不會很大。缺點是效能太差，原本引進分散式資料庫主要是為了倍增的提升效能，但因為分散式交易的引進將這個效能的提升大打折扣，很多時候這個效能是難以接受的。

    （2）訊息中間件，本文主角，訊息中間件的一大職能就是負責各個系統間的交流，非常適合這裡的商品和訂單系統的同步問題。引入訊息中間件後的下單流程是：用戶A下訂單後給訊息中間件發送訊息，商品系統訂閱訂單訊息，並扣除相應的庫存。

這裡有幾個注意點：

a、訊息的傳遞是需要時間的，下單前查看有庫存，但在並發條件下，實際減庫存時可能庫存不夠，所以必須在庫存扣減成功後才能顯示訂單成功，即下單後標記已下單，但用戶對該狀態不可見，等待商品系統減庫存成功後，再通知訂單系統更新狀態（仍然是消息中間件的運用哦）；

b 、對訊息的可靠性要求很高，發送訊息時返回成功就要保證該訊息會被投遞，發送失敗需要下單業務自己做回滾；

c、訊息的可靠性高表示一定會有訊息重複，這裡需要商品系統自己做冪等，可以透過訊息id來做去重，否則會少賣；

d、下單成功失敗前端用戶都希望儘早得到通知，所以在下單成功後需要設定一個定時消息，在一段時間後如果訂單庫存還沒有扣除成功，這個時候應該通知用戶下單失敗，並且定期回補這部分多扣的庫存。

引入訊息中間件，可以很好的解決了分散式資料庫資料同步的問題，避免了分散式事務。而額外的好處是減少了減庫存時候的並發鎖爭搶，性能槓槓的。