feed系統和火車票售賣系統是2個高訪問高併發情況下具體很大挑戰的系統。
在低訪問，低併發的情況下feed系統會變的非常簡單，資料模型和業務功能都比較容易設計和實現，主要的挑戰就剩如何面對層出不窮的敏感詞和花樣百出的廣告語。相比之下，火車票售賣系統在低併發時也很有趣，假設我是12306的架構師，我會如何設計12306那。
先將系統進行拆分，獨立成使用者，車票，下單3個系統，每個系統內部封閉成多個服務，執行在獨立的集群上面。這裡只對車票系統進行資料模型設計。
先上er圖
資料分成動靜2部分，車次，站點，座位的資料都是靜態的基本不會變，可以通過運營系統提前進行錄入生成；車票則根據以上三張表每天動態生成，每條車票記錄乙個車次上的乙個座位號，初始化的始發站，終點站為該車次的始發站和終點站，資料在下單時進行更新。確定了資料模型後進行資料庫的垂直和水平拆分，首先按照車次進行分庫，將不同的車次hash到幾個資料庫中，減少每個資料庫的負載；然後車票表按天拆分，提前生成3個月的車票表，每張車票表只儲存當天發車的車票。
系統的抗壓能力和是吞吐量成正比的，這也就是為什麼靜態頁面可以支援超高的qps，查詢的效能優化也比較容易，事務處理的效能提公升最困難，系統處理時會保持tcp鏈結，占用系統資源，最終導致系統的崩潰，響應時間越快，資源的占用時間越短，吞吐能力也就越強，系統的可用性也就越高。
在某寶某貓做話費充值系統的思路完全可以用來做火車售票系統，將下單請求持久化，系統間通過訊息解耦，通過多執行緒佇列非同步處理請求。具體的實現可以在收到下單購票請求後持久化，返回給使用者乙個排隊中的提示(1-x分鐘處理完成)，按照車次放到不同的佇列中進行排隊(期間可以做過濾/去重/合併處理），系統從佇列中取資料進行處理。最終一致性就可以滿足業務需求的地方，服務儘量減少事務和鎖的使用，提高併發處理能力。
為啥要把降級單獨拉出來說，我覺得本質上講降級並不是由於架構設計上的充分考慮帶來的可用性和伸縮性的提高，而是犧牲一部分的使用者體驗換來的系統的可用性，是對峰值事件的應對策略。基本實現就是在系統埋好各種開關，可以由人工控制也可以由系統觸發，保證最基本的核心功能可用，其他的非核心功能和部分使用者體驗可以暫時捨棄。
資料模型和業務功能就是這樣，不論實現的多扭曲基本上大家都可以做出來，功能實現之後無bug是乙個挑戰，能夠滿足未來變化是乙個挑戰，在某個量級之後依然可用又是乙個挑戰。
12306模型設計
傳統電商的思路 如果按照普通電商的思路，把票 站點區間 設計為商品 聚合根 然後為票設計庫存數量。我個人覺得是很糟糕的。因為一方面這種聚合根非常多，另一方面，即便列舉出來了，一次購票也一定會影響非常多其他聚合根的庫存數量 只要被部分或全部重疊的區間都受影響 這樣的一次訂單處理的複雜度是難以評估的。而...
對於12306，我的完整技術方案
12306主要就是賣票比較複雜，註冊登入之類的功能就不說了。有說，12306賣票系統比航空複雜，因為要分段賣，航空只有起點和終點，火車中間還有好多站。不過好訊息是，這些站在售票時是連續的，不會出現1張票跳著站買的情況，這樣就可以把一張票拆成n張只有起點和終點的票，和航空售票一樣了。我不了解航空售票，...
如果我是12306架構師
12306，因為系統問題，成了it業界內大家茶餘飯後經常談論的話題。先分享乙個真實故事，我同事看了12306這個 他說，這個 做下來只要5萬，我反駁，被他嘲笑。笑話終歸笑話，沒有諷刺鐵道部，以及12306研發方的意思，我同事是實習生，他不懂12306。近日，我們在乙個技術群裡討論了乙個開放式話題 如...