雖然難用，但12306面臨的業務場景複雜度多是世界之最

爲何我要研究這個問題？

此前無心中看到一篇文章，文章中講到 12306 的業務複雜度遠遠比淘寶天貓這種電商網站要複雜。後來本身想一想，也確實如此。因此，很想挑戰一下 12306 這個系統的核心領域模型的設計。通常的電商網站，購買都是基於商品的概念，每一個商品有必定量的庫存，用戶的購買行爲是針對商品的。當用戶發起購買行爲時，系統只須要生成訂單並對用戶要購買的商品減庫存便可。可是，12306 就不是那麼簡單了，具體複雜在哪裏，我下面會進一步分析。

另一個讓我寫這篇文章的緣由，是我發現也許是不是由於目前 12306 的核心領域模型設計的不夠好，致使用戶購票時要處理的業務邏輯異常複雜，維護數據一致性的難度也幾百倍的上升，同時面對高併發的訂票也難以支持很高的 TPS。我以爲，越是複雜的業務，就越要重視業務分析，重視領域模型的抽象和設計。若是不假思索，憑以往經驗行事，則極可能會被以往的設計經驗先入爲主，陷入死衚衕。

技術人員每每更注重技術層面的解決方案，好比一上來就分析如何集羣、如何負載均衡、如何排隊、如何分庫分表、如何用鎖，如何用緩存等技術問題，而忽略了最根本的業務層面的思考，如分析業務、領域建模。我認爲越是複雜的業務系統，則越要設計一個健壯的領域模型。若是一個系統的架構咱們設計錯了，還有補救的餘地，由於架構最終沉澱的只是代碼，調整架構便可（一個系統的架構自己就是不斷演進的）；而若是領域模型設計錯了，那要補救的代價是很是大的，由於領域模型沉澱的是數據結構及其對應的大量數據，對任何一個大型系統，要改核心領域模型都是成本很是高的。

本文的重點不是在如何解決高併發的問題，而是但願從業務角度去分析，12306 的理想模型應該是怎麼樣的。網上談 12306 的文章貌似都是千篇一概的只談技術，不談業務分析和如何建模的。因此我想寫一下本身的設計和你們交流學習。

需求概述

12306 這個系統，核心要解決的問題是網上售票。涉及到 2 個角色使用該系統：用戶、鐵道部。用戶的核心訴求是查詢餘票、購票；鐵道部的核心訴求是售票。購票和售票實際上是一個場景，對用戶來講是購票，對鐵道部來講是售票。所以，咱們要設計一個在線的網站系統，解決用戶的查詢餘票、購票，以及鐵道部的售票這 3 個核心訴求。看起來，這 3 個場景都是圍繞火車票展開的。

查詢餘票：用戶輸入出發地、目的地、出發日三個條件，查詢可能存在的車次，用戶能夠看到每一個車次通過的站點名稱，以及每種座位的餘票數量。

購票：購票分爲訂票和付款兩個階段，本文重點分析訂票的模型設計和實現思路。

其實還有不少其餘的需求，好比給不一樣的車次設定銷售座位數配額，以及不一樣的區段設置不一樣的限額。但相比前面兩個需求來講，我以爲這個需求相對次要一些。

需求分析

確實，12306 也是一個電商系統，並且看起來商品就是票了。由於若是把一張票當作是一個商品，那購票就相似於購買商品，而後每張票都有庫存，商品也有庫存的概念。可是若是咱們仔細想一想，會發現 12306 要複雜不少，由於咱們沒法預先肯定好全部的票，若是非要肯定，那隻能經過窮舉法了。

咱們以北京西到深圳北的 G71 車次高鐵爲例（這裏只考慮南下的方向，不考慮深圳北到北京西的，那是另一個車次，叫 G72），它有 17 個站（北京西是 01 號站，深圳北是 17 號站），3 種座位（商務、一等、二等）。表面看起來，這不就是 3 個商品嗎？G71 商務座、G71 一等座、G71 二等座。大部分輕易噴 12306 的技術人員（包括某些中等規模公司的專家、CTO）就是在這裏栽第一個跟頭的。實際上，G71 有 136*3=408 種商品（408 個 SKU），怎麼算來的？以下：

若是賣北京西始發的，有 16 種賣法（由於後面有 16 個站），北京西到：保定、石家莊、鄭州、武漢、長沙、廣州、虎門、深圳。。。。都是一個獨立的商品，同理，石家莊上車的，有 15 種下車的可能，以此類推，單以上下車的站來計算，有 136 種票：16+15+14....+2+1=136。每種票都有 3 種座位，一共是 408 個商品。

爲了方便後面的討論，咱們先明確一下票是什麼？

一張票的核心信息包括：出發時間、出發地、目的地、車次、座位號。持有票的人就擁有了一個憑證，該憑證表示持有它的人能夠坐某個車次的某個座位號，從某地到某地。因此，一張票，對用戶來講是一個憑證，對鐵道部來講是一個承諾；那對系統來講是什麼呢？不知道。這就是咱們要分析業務，領域建模的緣由，咱們再繼續思考吧。

明白了票的核心信息後，咱們再看看 G71 這個車次的高鐵，能夠賣多少張票？

討論前先說明一下，一輛火車的物理座位數（站票也能夠當作是一種座位，由於站票也有數量配額）不等於可用的最大配合。全部的物理座位不可能都經過 12306 網站來銷售，而是隻會銷售一部分，好比 40%。其他的仍是會經過線下的方式銷售。不只如此，可能有些站點上車的人會比較多，有些比較少，因此咱們還會給不一樣的區間配置不一樣的限額。

好比 D31 北京南至上海共有 765 張，北京南有 260 張，楊柳青有 80 張，泰安有 76 張。若是楊柳青的 80 張票售完就會顯示無票，就算其餘站有票也會顯示無票的。每一個車次確定會有各類座位的配額和限額的配置的，這種配置我目前沒法預料，但我已經把這些規則都封裝近車次聚合根裏了，全部的配置策略都是基於座位類型、站點、區間配置的。關於票的配置抽象出來，我以爲主要有 3 種：

1. 某個區段最多容許出多少張；

2. 某個區段最少容許出多少張；

3. 某個站點上車的最多多少張。

當用戶訂票時，把用戶指定的區段和這 3 種配置條件進行比較，3 個條件都知足，則能夠出票。不知足，則認爲無票了。下面舉個例子：

ABCDEFG，這是全部站點。座位總配額是 100，假設 B 站點上車，E 站下車的人比較少，那咱們就能夠設定 BE 這個區段最多隻能出 10 張票。因此，只要是用戶的訂票是在這個區段內的，就最多出 10 張。再好比，一列車次，總共 100 個座位配額，但願全程票最少知足 80 張，那咱們只要給 AG 這個區段設定最少 80 張。那任何訂票請求，若是是子區間的，就不能超過 100-80，即 20 張。這兩種條件必須同時知足，才容許出票。

可是，無論如何作配額和限額，咱們老是針對某個車次進行配置，這些配置只是車次內部售票時的一些額外的判斷條件（業務規則），不影響車次模型的核心地位和對外暴露的功能。因此，爲了本文討論的清楚起見，我後續的討論都不涉及配額和限額的問題，而是認爲任何區段均可以享受火車最大的物理座位數。

而且，爲了討論問題方便，咱們減小一些站點來討論。假設某個車次有 A,B,C,D 四個站點。那 001 這我的購買了 A,B 這個區間，系統會分配給 001 一個座位 x；可是由於 001 坐到 B 站點後會下車，因此至關於 x 這個座位又空出來了，也就是說，從 B 站點開始，系統又能夠認爲 x 這個座位是可用的。因此，咱們得出結論：同一個座位，其實能夠同時出售 AB,BC 這兩張票。經過這個簡單的分析，咱們知道，一列火車雖然只有有限的座位數，好比 1000 個座位。但能夠賣出的票遠遠不止 1000 個。

仍是以 A,B,C,D 四個站點爲例，假如火車總共有 1000 個座位，那 AB 能夠賣 1000 張，BC 也能夠賣 1000 張，一樣，CD 也能夠賣 1000 張。也就是說，理論上最多能夠賣出 3000 張票。可是若是換一種賣法，全部人都是買 ABCD 的票，也就是說全部的票都是通過全部站點的，那就是最多隻能賣出 1000 張票了。而實際的場景，必定是介於 1000 到 3000 之間。而後實際的 G71 這個車次，有 17 個站，那到底能夠賣出多少個票，你們應該能夠算了吧。理論上這 17 個站中的任意兩個站點之間所造成的線段，均可以出售爲一張票。我數學很差，算不太清楚，麻煩有數學好的人幫我算算，呵呵。

經過上面的分析，咱們知道一張票的本質是某個車次的某一段區間（一條線段），這個區間包含了若干個站點。而後咱們還發現，只要區間不重疊，那座位就不會發生競爭，能夠被回收利用，也就是說，能夠同時預先出售。

另外，通過更深刻的分析，咱們還發現區間有 4 種關係：

• 不重疊；

• 部分重疊；

• 徹底重疊；

• 覆蓋。

不重疊的狀況咱們已經討論過了，而覆蓋也是重疊的一種。因此咱們發現若是重疊，好比有兩個區間發生重疊，那重疊部分的區間（可能誇一個或多個站點）是在爭搶座位的。由於假設一列火車有 100 個座位，那每一個原子區間（兩個相鄰站點的連線），最多容許重疊 99 次。

因此，通過上面的分析，咱們知道了一個車次可以出售一張車票的核心業務規則是什麼？就是：這張車票所包含的每一個原子區間的重疊次數加 1 都不能超過車次的總座位數，實際上重疊次數 +1 也能夠理解爲線段的厚度。

模型設計

上面我分析了一下票的本質是什麼。那接下來咱們再來看看怎麼設計模型，來快速實現購票的需求，重點是怎麼設計商品聚合以及減庫存的邏輯。

傳統電商的思路

若是按照普通電商的思路，把票（站點區間）設計爲商品（聚合根），而後爲票設計庫存數量。我我的以爲是很糟糕的。由於一方面這種聚合根很是多（上面的 G71 就有 408 個）；另外一方面，即使枚舉出來了，一次購票也必定會影響很是多其餘聚合根的庫存數量（只要被部分或所有重疊的區間都受影響）。這樣的一次訂單處理的複雜度是難以評估的。並且這麼多聚合根的更新要在一個事務裏，這不是爲難數據庫嗎？並且，這種設計必然帶來大量的事務的併發衝突，極可能致使數據庫死鎖。

總之，我認爲這種是典型的因爲領域模型的設計錯誤，致使併發衝突高、數據持久化落地困難。或者若是要解決併發問題，只能排隊單線程處理，可是仍然解決不了要在一個事務裏修改大量聚合根的尷尬局面。

據說 12306 是採用了 Pivotal Gemfire 這種高大上的內存數據庫，我對這個不太瞭解。我不可想象要是不使用內存數據庫，他們要怎麼實現車次內的票之間的數據強一致性（就是保證全部出售的票都是符合上面討論的業務規則的）？因此，這種設計，我我的認爲是思惟定勢了，把火車票當作是普通電商的商品來看待。因此，咱們有時作設計又要依賴於經驗，又要不能被以往經驗所束縛，真的不容易，關鍵仍是要根據具體的業務場景多多深刻分析，儘可能分析抽象出問題的本質出來，這樣才能對症下藥。那是否有其餘的設計思路呢？

個人思路 一、聚合設計

經過上面的分析咱們知道，其實任何一次購票都是針對某個車次的，我認爲車次是負責處理訂票的聚合根。咱們看看一個車次包含了哪些信息？一個車次包括了：

1. 車次名稱，如 G71；

2. 座位數，實際座位數會分類型，好比商務座 20 個，一等座 200 個；二等座 500 個；咱們這裏爲了簡化問題，能夠暫時忽略類型，我認爲這個類型不影響核心的模型的設計決策。須要格外注意的是：這裏的座位數不要理解爲真實的物理座位數，頗有可能比真實的座位數要少。由於咱們不可能把一個車次的全部座位都在網上經過 12306 來出售，而是隻出售一部分，具體出售多少，要由工做人員人工指定。

3. 通過的站點信息（包括站點的 ID、站點名稱等），注意：車次還會記錄這些站點之間的順序關係；

4. 出發時間；看過 GRASP 九大模式中的信息專家模式的同窗應該知道，將職責分配給擁有執行該職責所需信息的類。

咱們這個場景，車次具備一次出票的全部信息，因此咱們應該把出票的職責交給車次。另外學過 DDD 的同窗應該知道，聚合設計有一個原則，就是：聚合內強一致性，聚合之間最終一致性。通過上面的分析，咱們知道要產生一張票，其實要影響不少和這個票對應的線段相交的其餘票的可用數量。由於全部的站點信息都在車次聚合內部，因此車次聚合內部天然能夠維護全部的原子區間，以及每一個原子區間的可用票數（至關因而庫存數）。當一個原子區間的可用票數爲 0 的時候，意味着火車針對這個區間的票已經賣完了。因此，咱們徹底可讓車次這個聚合根來保證出票時對全部原子區間的可用票數的更新的強一致性。對於車次聚合根來講，這很簡單，由於只是幾回簡單的內存操做而已，耗時能夠忽略。一列火車假若有 ABCD 四個站點，那原子區間就是 3 個。對於 G71，則是 16 個。

 二、怎麼判斷是否能出票？

基於上面的聚合設計，出票時扣減庫存的邏輯是：

根據訂單信息，拿到出發地和目的地，而後獲取這段區間裏的全部的原子區間。而後嘗試將每一個原子區間的可用票數減 1，若是全部的原子區間都夠減，則購票成功；不然購票失敗，提示用戶該票已經賣完了。是否是很簡單呢？知道了出票的邏輯，那退票的邏輯也就很簡單了，就是把這個票的全部原子區間的可用票數加 1 就 OK 了。若是咱們從線段的厚度的角度去考慮，那出票時，每一個原子區間的厚度就是 +1，退票時就是減一。就是相反的操做，但本質是同樣的。

因此，經過這樣的思路，咱們將一次訂票的處理控制在了一個聚合根裏，用聚合根內的強一致性的特性保證了訂票處理的強一致性，同時也保證了性能，免去了併發衝突的可能性。傳統電商那種把票單作相似商品的核心聚合根的設計，我當時第一眼看到就以爲不妥。由於這違背了 DDD 強調的強一致性應該由聚合根來保證、聚合根之間的最終一致性經過 Saga 來保證的原則。

還有一個很重要的概念我想說一下個人見解，就是座位和區間的關係。由於有些朋友和我講，考慮座位號的問題，雖然都能減 1，座位號也必須是同一個。我以爲座位是全局共享的，和區段無關（也許個人理解徹底有誤，請你們指正）。座位是一個物理概念，一個用戶成功購買了一張票後，座位就會少一個，一張票惟一對應一個座位，可是一個座位有可能會對應多張票；而區間是一個邏輯上的概念，區間的做用有兩個：1）表示票的出發地和目的地；2）記錄票的可用數額。若是區間能連通（即該區間內的每一個原子區間的可用數額都大於 0），則表示容許擁有一個座位。因此，我以爲座位和票（區間）是兩個維度的概念。

 三、如何爲票分配座位？

我以爲車次聚合根內部應該維護全部該車次已經售出的票，已經出售的票的的本質是區間和座位的對應關係。系統處理訂票時，用戶提交過來的是一段區間。因此，系統應該作兩個事情：

1. 先根據區間去判斷是否有可用的座位；

2. 若是有可用座位，則再經過算法去選擇一個可用的座位；

當獲得一個可用座位後，就能夠生成一張票了，而後保存這個票到車次聚合根內部便可。下面舉個例子：

假設如今的狀況是座位有 3 個，站點有 4 個：

• 座位：1,2,3

• 站點：abcd

票的賣法 1：

• 票 1：ab,1

• 票 2：bc,2

• 票 3：cd,3

• 票 4：ac,3

• 票 5：bd,1

這種選座位的方式應該比較高效，由於老是優先從座位池裏去拿座位，只有在萬不得已的時候纔會去回收可重複利用的票。

上面的 4，5 兩個票，就是考慮回收利用的結果。

票的賣法 2：

• 票 1：ab,1

• 票 2：bc,1

• 票 3：cd,1

• 票 4：ac,2

• 票 5：bd,3

這種選座位的方式應該相對低效，由於老是優先會去掃描是否有可回收的座位，而掃描相對直接從座位池裏去拿票老是成本相對要高的。

上面的 2，3 兩個票，就是考慮回收利用的結果。

可是，優先從座位池裏拿票的算法有缺陷，就是會出現雖然第一步判斷認爲有可用的座位，可是這個座位可能不是全程都是同一個座位。舉例：

假設如今的狀況是座位有 3 個，站點有 4 個：

• 座位：1,2,3

• 站點：abcd

票的賣法 3：

• 票 1：ab,1

• 票 2：bc,2

• 票 3：cd,3

如今若是有人要買 ad 的票，那可用的座位有 2，或者 3。可是不管是 2 仍是 3，都要這個乘客中途換車位。好比賣給他座位 2，那他 ab 是坐的座位 2，可是 bc 的時候要坐座位 1 的。不然拿票 2 的那我的上車時，發現座位 2 已經有人了。而經過優先回收利用的算法，是沒這個問題的。

因此，從上面的分析咱們也知道選座位的算法該怎麼寫了，就是採用優先回收利用座位的算法。我認爲無論咱們這裏怎麼設計算法，都不影響大局，由於這一切都只發生在車次聚合根內部，這就是預先設計好聚合根，明確出票職責在哪一個對象上的好處。

 四、模型分析總結

我認爲票不是核心聚合根，票只是一次出票的結果，一個憑證而已。

12306 真正的核心聚合根應該是車次，車次具備出票的職責，一次出票具體作的事情有：

• 判斷是否可出票；

• 選擇可用的座位；

• 更新一次出票時全部原子區間的可用票數，用於判斷下次是否能出票；

• 維護全部已售出的票，用於爲選擇可用座位提供依據。

經過這樣的模型設計，咱們能夠確保一次出票處理只會在一個車次聚合根內進行。這樣的好處是：

1. 不須要依賴數據庫事務就能實現數據修改的強一致性，由於全部修改只在一個聚合根內發生；

2. 在保證數據強一致性的同時還能提供很高的併發處理能力，具體設計見下面的架構設計。

架構設計

我以爲 12306 這樣的業務場景，很是適合使用 CQRS 架構；由於首先它是一個查多寫少、可是寫的業務邏輯很是複雜的系統。因此，很是適合作架構層面的讀寫分離，即採用 CQRS 架構。並且應該使用數據存儲也分離的 CQRS。這樣 CQ 兩端才能夠徹底不須要顧及對方的問題，各自優化本身的問題便可。咱們能夠在 C 端使用 DDD 領域模型的思路，用良好設計的領域模型實現複雜的業務規則和業務邏輯。而 Q 端則使用分佈式緩存方案，實現可伸縮的查詢能力。

訂票的實現思路

同時藉助像 ENode 這樣的框架，咱們能夠實現 in-memory + Event Sourcing 的架構。Event Sourcing 技術，可讓領域模型的全部狀態修改的持久化統一塊兒來，原本要用 ORM 的方式保存聚合根最新狀態的，如今只須要簡單的通用的方式保存一個事件便可（一次訂票只涉及一個車次聚合根的修改，修改只產生一個事件，只須要持久化一個事件（一個 JSON 串）便可，保證了高性能，無須依賴事務，並且經過 ENode 能夠解決併發問題）。

咱們只要保存了聚合根每次變化的事件（事件的結構怎麼設計，本文不作多的介紹了，你們能夠思考下），就至關於保存了聚合根的最新狀態。而正是因爲 Event Sourcing 技術的引入，讓咱們的模型能夠一直存活在內存中，便可以使用 in-memory 技術。不要小看 in-memory 技術，in-memory 技術在某些方面對提升命令的處理性能很是有幫助。

好比就以咱們車次聚合根處理出票的邏輯，假設某個車次有大量的命令發送到分佈式消息隊列，而後有一臺機器訂閱了這個隊列的消息，而後這臺機器處理這個車次的訂票命令時，因爲這個車次聚合根一直在內存，因此就省去了每次要去數據庫取出聚合根的步驟，至關於少了一次數據庫 IO。

這樣的好處是，由於一個車次可以真正出售的票是有限的，由於座位就那麼幾個，好比就 1000 個座位，估計通常正常狀況也就出個 2000 個左右的票吧（具體能出多少張票要取決於區間的相交程度，上面分析過）。也就是說，這個聚合根只會產生 2000 個事件，也就是說只會有 2000 個訂票命令的處理是會產生事件，並持久化事件；而其他的大量命令，由於車次在內存計算後發現沒有餘票了，就不會作任何修改，也不會產生領域事件，這樣就能夠直接處理下一個訂票命令了。這樣就能夠大大提升處理訂票命令的性能。

另一個問題我以爲還須要提一下，由於用戶訂票成功後，還須要付款。但用戶有可能不去付款或者沒有在規定的時間內完成付款。那這種狀況下，系統會自動釋放該用戶以前訂購的票。因此基於這樣的需求，咱們在業務上須要支持業務級別的 2pc。即先預扣庫存，也就是先佔住這張票必定時間（好比 15 分鐘），而後付款成功後再真實給你這張票，系統作真正的庫存修改。

經過這樣的預扣處理，能夠保證不會出現超賣的狀況。這個思路其實和傳統電商好比淘寶這樣的系統相似，我就很少展開了，我以前寫的 Conference 案例也是這樣的思路，你們有興趣的能夠去看一下我以前錄製的視頻。

查詢餘票的實現思路

我以爲餘票的查詢的實現相對簡單。雖然對於 12306 來講，查詢的請求佔了 80%，提交訂單的請求只佔 20%。但查詢因爲對數據沒有修改，因此咱們徹底可使用分佈式緩存來實現。咱們只須要精心設計好緩存的 key 便可；緩存 key 的多少要當作本，若是全部可能的查詢都設計對應的 key，那時間複雜度爲 1，查詢性能天然高；但代價也大，由於 key 多了。若是想 key 少一點，那查詢的複雜度天然要上去一點。因此緩存設計無非就是空間換時間的思路。而後，緩存的更新無非就是：自動失效、定時更新、主動通知 3 種。經過 CQRS 架構，因爲 CQ 兩端是事件驅動的，當 C 端有任何狀態變化，都會產生對應的事件去通知 Q 端，因此咱們幾乎能夠作到 Q 端的準實時更新。

同時因爲 CQ 兩端的徹底解耦，Q 端咱們能夠設計多種存儲，如數據庫和緩存（Redis 等）；數據庫用於線下維護關係型數據，緩存用戶實時查詢。數據庫和緩存的更新速度相互不受影響，由於是並行的。對同一個事件，能夠 10 臺機器負責更新緩存，100 臺機器負責更新數據庫。即使數據庫的更新很慢，也不會影響緩存的更新進度。這就是 CQRS 架構的好處，CQ 的架構徹底不一樣，且咱們隨時能夠重建一種新的 Q 端存儲。不知道你們體會到了沒有？

關於緩存 key 的設計，我以爲主要從查詢餘票時傳遞的信息來考慮。12306 的關鍵查詢是：出發地、目的地、出發日期三個信息。我以爲有兩種 key 的設計思路：

1. 直接設計了該查詢條件的 key，而後快速拿到車次信息，直接返回；這種方式就是要求咱們系統已經枚舉了全部車次的全部可能出現的票（區間）的緩存 key，相信你必定知道這樣的 key 是很是多的。

2. 不是枚舉全部區間，而是把每一個車次的每一個原子區間（相鄰的兩個站點所連成的直線）的可用票數做爲 key。這樣，key 就很是少了，由於車次假若有 10000 個，而後每一個車次平均 15 個區間，那也就 15W 個 key 而已。當咱們要查詢時，只須要把用戶輸入的出發地和目的地之間的全部原子區間的可用票數都查出來，而後比較出最小可用票數的那個原子區間。則這個原子區間的可用票數就是用戶輸入的區間的可用票數了。固然，到這裏我提到考慮出發日期。我認爲出發日期是用來決定具體是哪一個車次聚合根的。同一個車次，不一樣的日期，對應的聚合根實例是不一樣的，即使是同一天，也可能有多個車次聚合根，由於有些車次一天有幾班的，好比上午 9 點發車的一班，下午 3 點發車的通常。因此，咱們也只要把日期也做爲緩存 key 的一部分便可。

寫在最後

本文徹底是憑本身對 12306 這個網站的核心業務的簡單思考而獲得的一些設計結果。若是真正的 DDD 領域建模，更多的是要和業務一線的工做人員、領域專家進行深刻溝通，才能更深刻的瞭解該領域內的業務知識，從而才能設計出更靠譜的領域模型和架構設計。

很是慚愧，我沒有上 12306 買過火車票，家離的比較近，就算要買也是家人給我買:）因此，本文所分享的內容不免是紙上談兵。但我以爲 12306 這個系統的業務確實比傳統的電商系統要複雜，且併發又這麼高。因此，我以爲這個系統真的很值得你們重視模型的設計，而不僅是隻關注技術層面的實現。