中國的雙11狂潮也許過去了，但是它在過去10年來，利用這個巨大的洪峰訓練自己電商系統的擴容秒殺能力，卻是舉世無雙的。從2009年每秒可以做400筆交易到2019年做54萬筆，相較於臺灣這些年來無論購票電商或疫苗系統，始終無法突破1000筆/s。我們要問的是，這衹是計算資源的差別呢，還是無論系統架構或軟體設計，都沒找到瞬間爆發人潮的瓶頸。
系統架構的問題應該不大，在網上參考阿里天貓歷年來的架構演進，再請雲服務架構師諮詢，然後進行壓測就不會差太遠了。當然阿里自行研發的X-DB和POLARDB資料庫，以及阿里雲的神龍架構，裡頭藏了多少秘密還真不敢說。
我們退而求其次，以中國過年期間上億遊子搶票的高鐵購票系統，12306，對軟體架構設計的說明，以100萬人同時搶1萬張票為例，或許可提供本地購票系統開發者參考。
系統架構其實不算特殊，由前端的OSPF負載均衡，LVS負載均衡，Nginx負載均衡組成，到後端以Golang, Node.js, 和PHP語言開發的伺服器群，和大型電商其實差不多。值得描述的，是他所謂的「秒殺搶購系統」的設計。
購票系統永遠有一個問題，就是減去庫存的時機。如果在下單完成之後就做，可能因為搶購超買後不付錢造成票賣不完；如果是在付款完成之後才做，有可能在交易大量湧進時，庫存無法及時調整造成超賣。
另外這兩個方法都是同步的，所以會需要大量的資料庫disk io運作，造成系統的阻塞。
12306解決的辦法，是使用「預扣庫存」的方式，讓前端的訂票系統先扣庫存，然後將這筆交易經由MQ或者是Kafka後送給付款系統。如果在規定時間之內(如5分鐘)客人沒有付款則庫存會自動回收，如圖一。這種做法無論是在單機或者擴容為分散系統協作的方式，都可以解決超賣或者超買的問題。另外下單和售票獨立而非同步，中間以Message Queue聯繫，所以非但省資源，而且速度會很快。
欲知詳情可參考以下資料來源 https://juejin.cn/post/6844903949632274445
在擴容方面，由於前端下單系統的壓力非常之大，所以每一臺都會預放一些庫存馬上可以扣掉，比方100台下單機器每台先放100張票。在容錯方面，由於任何一台前端下單系統都可能會當掉，所以大夥必須和一個庫存資料庫同步，不但造成資料的一致性，還可以相互支援(圖二)。
以上個人淺見，還請各位指教。
延伸閱讀
作者：陳少君
經歷：
在矽谷創業20年，後因照顧父母回國服務。
曾任長鑫存儲CIO/VP
曾任資策會數教所資深總監
曾任台灣佳能資深技術總監
曾任浩鑫資深技術總監