換個思路看12306，其核心模型設計思路到底復雜在

編者按：本文作者湯雪華，網(wǎng)名 netfocus，2006年 畢業(yè)于浙江大學，目前住在杭州。對 DDD，以及 CQRS 架構比較感興趣。目前一直致力于開發(fā)和完善 ENode、EQueue。文章首發(fā)于微信公眾號InfoQ（ID：infoqchina）。

元宵節(jié)結束，年就真的過完了。揮別故里，回到打拼的城市，理性思維是否也跟著工作狀態(tài)一起回歸了呢？每一年的春運都是對 12306 的一次大考，拋去盲從和偏見，讓我們用工程師的思維重新打量、從業(yè)務分析的角度去探討，12306 的核心模型設計思路和架構設計到底復雜在哪里？

為什么我要研究這個問題？

春節(jié)期間，無意中看到一篇文章，文章中講到 12306 的業(yè)務復雜度遠遠比淘寶天貓這種電商網(wǎng)站要復雜。后來自己想想，也確實如此。所以，很想挑戰(zhàn)一下 12306 這個系統(tǒng)的核心領域模型的設計。一般的電商網(wǎng)站，購買都是基于商品的概念，每個商品有一定量的庫存，用戶的購買行為是針對商品的。當用戶發(fā)起購買行為時，系統(tǒng)只需要生成訂單并對用戶要購買的商品減庫存即可。但是，12306 就不是那么簡單了，具體復雜在哪里，我下面會進一步分析。

另外一個讓我寫這篇文章的原因，是我發(fā)現(xiàn)也許是否是因為目前 12306 的核心領域模型設計的不夠好，導致用戶購票時要處理的業(yè)務邏輯異常復雜，維護數(shù)據(jù)一致性的難度也幾百倍的上升，同時面對高并發(fā)的訂票也難以支持很高的 TPS。我覺得，越是復雜的業(yè)務，就越要重視業(yè)務分析，重視領域模型的抽象和設計。如果不假思索，憑以往經(jīng)驗行事，則很可能會被以往的設計經(jīng)驗先入為主，陷入死胡同。

技術人員往往更注重技術層面的解決方案，比如一上來就分析如何集群、如何負載均衡、如何排隊、如何分庫分表、如何用鎖，如何用緩存等技術問題，而忽略了最根本的業(yè)務層面的思考，如分析業(yè)務、領域建模。我認為越是復雜的業(yè)務系統(tǒng)，則越要設計一個健壯的領域模型。如果一個系統(tǒng)的架構我們設計錯了，還有補救的余地，因為架構最終沉淀的只是代碼，調整架構即可（一個系統(tǒng)的架構本身就是不斷演進的）；而如果領域模型設計錯了，那要補救的代價是非常大的，因為領域模型沉淀的是數(shù)據(jù)結構及其對應的大量數(shù)據(jù)，對任何一個大型系統(tǒng)，要改核心領域模型都是成本非常高的。

本文的重點不是在如何解決高并發(fā)的問題，而是希望從業(yè)務角度去分析，12306 的理想模型應該是怎么樣的。網(wǎng)上目前談 12306 的文章貌似都是千篇一律的只談技術，不談業(yè)務分析和如何建模的。所以我想寫一下自己的設計和大家交流學習。

1、需求概述

12306 這個系統(tǒng)，核心要解決的問題是網(wǎng)上售票。涉及到 2 個角色使用該系統(tǒng)：用戶、鐵道部。用戶的核心訴求是查詢余票、購票；鐵道部的核心訴求是售票。購票和售票其實是一個場景，對用戶來說是購票，對鐵道部來說是售票。因此，我們要設計一個在線的網(wǎng)站系統(tǒng)，解決用戶的查詢余票、購票，以及鐵道部的售票這 3 個核心訴求?？雌饋恚@ 3 個場景都是圍繞火車票展開的。

查詢余票：用戶輸入出發(fā)地、目的地、出發(fā)日三個條件，查詢可能存在的車次，用戶可以看到每個車次經(jīng)過的站點名稱，以及每種座位的余票數(shù)量。

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

其實還有很多其他的需求，比如給不同的車次設定銷售座位數(shù)配額，以及不同的區(qū)段設置不同的限額。但相比前面兩個需求來說，我覺得這個需求相對次要一些。

2、需求分析

確實，12306 也是一個電商系統(tǒng)，而且看起來商品就是票了。因為如果把一張票看成是一個商品，那購票就類似于購買商品，然后每張票都有庫存，商品也有庫存的概念。但是如果我們仔細想想，會發(fā)現(xiàn) 12306 要復雜很多，因為我們無法預先確定好所有的票，如果非要確定，那只能通過窮舉法了。

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

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

為了方便后面的討論，我們先明確一下票是什么？

一張票的核心信息包括：出發(fā)時間、出發(fā)地、目的地、車次、座位號。持有票的人就擁有了一個憑證，該憑證表示持有它的人可以坐某個車次的某個座位號，從某地到某地。所以，一張票，對用戶來說是一個憑證，對鐵道部來說是一個承諾；那對系統(tǒng)來說是什么呢？不知道。這就是我們要分析業(yè)務，領域建模的原因，我們再繼續(xù)思考吧。

明白了票的核心信息后，我們再看看 G71 這個車次的高鐵，可以賣多少張票？

討論前先說明一下，一輛火車的物理座位數(shù)（站票也可以看成是一種座位，因為站票也有數(shù)量配額）不等于可用的大配合。所有的物理座位不可能都通過 12306 網(wǎng)站來銷售，而是只會銷售一部分，比如 40%。其余的還是會通過線下的方式銷售。不僅如此，可能有些站點上車的人會比較多，有些比較少，所以我們還會給不同的區(qū)間配置不同的限額。

比如 D31 北京南至上海共有 765 張，北京南有 260 張，楊柳青有 80 張，泰安有 76 張。如果楊柳青的 80 張票售完就會顯示無票，就算其他站有票也會顯示無票的。每個車次肯定會有各種座位的配額和限額的配置的，這種配置我目前無法預料，但我已經(jīng)把這些規(guī)則都封裝近車次聚合根里了，所有的配置策略都是基于座位類型、站點、區(qū)間配置的。關于票的配置抽象出來，我覺得主要有 3 種：

1. 某個區(qū)段最多允許出多少張；
2. 某個區(qū)段最少允許出多少張；
3. 某個站點上車的最多多少張。

當用戶訂票時，把用戶指定的區(qū)段和這 3 種配置條件進行比較，3 個條件都滿足，則可以出票。不滿足，則認為無票了。下面舉個例子：

ABCDEFG，這是所有站點。座位總配額是 100，假設 B 站點上車，E 站下車的人比較少，那我們就可以設定 BE 這個區(qū)段最多只能出 10 張票。所以，只要是用戶的訂票是在這個區(qū)段內(nèi)的，就最多出 10 張。再比如，一列車次，總共 100 個座位配額，希望全程票最少滿足 80 張，那我們只要給 AG 這個區(qū)段設定最少 80 張。那任何訂票請求，如果是子區(qū)間的，就不能超過 100-80，即 20 張。這兩種條件必須同時滿足，才允許出票。

但是，不管如何做配額和限額，我們總是針對某個車次進行配置，這些配置只是車次內(nèi)部售票時的一些額外的判斷條件（業(yè)務規(guī)則），不影響車次模型的核心地位和對外暴露的功能。所以，為了本文討論的清楚起見，我后續(xù)的討論都不涉及配額和限額的問題，而是認為任何區(qū)段都可以享受火車大的物理座位數(shù)。

并且，為了討論問題方便，我們減少一些站點來討論。假設某個車次有 A,B,C,D 四個站點。那 001 這個人購買了 A,B 這個區(qū)間，系統(tǒng)會分配給 001 一個座位 x；但是因為 001 坐到 B 站點后會下車，所以相當于 x 這個座位又空出來了，也就是說，從 B 站點開始，系統(tǒng)又可以認為 x 這個座位是可用的。所以，我們得出結論：同一個座位，其實可以同時出售 AB,BC 這兩張票。通過這個簡單的分析，我們知道，一列火車雖然只有有限的座位數(shù)，比如 1000 個座位。但可以賣出的票遠遠不止 1000 個。

還是以 A,B,C,D 四個站點為例，假如火車總共有 1000 個座位，那 AB 可以賣 1000 張，BC 也可以賣 1000 張，同樣，CD 也可以賣 1000 張。也就是說，理論上最多可以賣出 3000 張票。但是如果換一種賣法，所有人都是買 ABCD 的票，也就是說所有的票都是經(jīng)過所有站點的，那就是最多只能賣出 1000 張票了。而實際的場景，一定是介于 1000 到 3000 之間。然后實際的 G71 這個車次，有 17 個站，那到底可以賣出多少個票，大家應該可以算了吧。理論上這 17 個站中的任意兩個站點之間所形成的線段，都可以出售為一張票。我數(shù)學不好，算不太清楚，麻煩有數(shù)學好的人幫我算算，呵呵。

通過上面的分析，我們知道一張票的本質是某個車次的某一段區(qū)間（一條線段），這個區(qū)間包含了若干個站點。然后我們還發(fā)現(xiàn)，只要區(qū)間不重疊，那座位就不會發(fā)生競爭，可以被回收利用，也就是說，可以同時預先出售。

另外，經(jīng)過更深入的分析，我們還發(fā)現(xiàn)區(qū)間有 4 種關系：

• 不重疊；
• 部分重疊；
• 完全重疊；
• 覆蓋。

不重疊的情況我們已經(jīng)討論過了，而覆蓋也是重疊的一種。所以我們發(fā)現(xiàn)如果重疊，比如有兩個區(qū)間發(fā)生重疊，那重疊部分的區(qū)間（可能夸一個或多個站點）是在爭搶座位的。因為假設一列火車有 100 個座位，那每個原子區(qū)間（兩個相鄰站點的連線），最多允許重疊 99 次。

所以，經(jīng)過上面的分析，我們知道了一個車次能夠出售一張車票的核心業(yè)務規(guī)則是什么？就是：這張車票所包含的每個原子區(qū)間的重疊次數(shù)加 1 都不能超過車次的總座位數(shù)，實際上重疊次數(shù) +1 也可以理解為線段的厚度。

3、模型設計

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

傳統(tǒng)電商的思路

如果按照普通電商的思路，把票（站點區(qū)間）設計為商品（聚合根），然后為票設計庫存數(shù)量。我個人覺得是很糟糕的。因為一方面這種聚合根非常多（上面的 G71 就有 408 個）；另一方面，即便枚舉出來了，一次購票也一定會影響非常多其他聚合根的庫存數(shù)量（只要被部分或全部重疊的區(qū)間都受影響）。這樣的一次訂單處理的復雜度是難以評估的。而且這么多聚合根的更新要在一個事務里，這不是為難數(shù)據(jù)庫嗎？而且，這種設計必然帶來大量的事務的并發(fā)沖突，很可能導致數(shù)據(jù)庫死鎖。

總之，我認為這種是典型的由于領域模型的設計錯誤，導致并發(fā)沖突高、數(shù)據(jù)持久化落地困難?；蛘呷绻鉀Q并發(fā)問題，只能排隊單線程處理，但是仍然解決不了要在一個事務里修改大量聚合根的尷尬局面。

聽說 12306 是采用了 Pivotal Gemfire 這種高大上的內(nèi)存數(shù)據(jù)庫，我對這個不太了解。我不可想象要是不使用內(nèi)存數(shù)據(jù)庫，他們要怎么實現(xiàn)車次內(nèi)的票之間的數(shù)據(jù)強一致性（就是保證所有出售的票都是符合上面討論的業(yè)務規(guī)則的）？所以，這種設計，我個人認為是思維定勢了，把火車票看成是普通電商的商品來看待。所以，我們有時做設計又要依賴于經(jīng)驗，又要不能被以往經(jīng)驗所束縛，真的不容易，關鍵還是要根據(jù)具體的業(yè)務場景多多深入分析，盡量分析抽象出問題的本質出來，這樣才能對癥下藥。那是否有其他的設計思路呢？

我的思路

1、聚合設計

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

1. 車次名稱，如 G71；
2. 座位數(shù)，實際座位數(shù)會分類型，比如商務座 20 個，一等座 200 個；二等座 500 個；我們這里為了簡化問題，可以暫時忽略類型，我認為這個類型不影響核心的模型的設計決策。需要格外注意的是：這里的座位數(shù)不要理解為真實的物理座位數(shù)，很有可能比真實的座位數(shù)要少。因為我們不可能把一個車次的所有座位都在網(wǎng)上通過 12306 來出售，而是只出售一部分，具體出售多少，要由工作人員人工指定。
3. 經(jīng)過的站點信息（包括站點的 ID、站點名稱等），注意：車次還會記錄這些站點之間的順序關系；
4. 出發(fā)時間；看過 GRASP 九大模式中的信息專家模式的同學應該知道，將職責分配給擁有執(zhí)行該職責所需信息的類。我們這個場景，車次具有一次出票的所有信息，所以我們應該把出票的職責交給車次。另外學過 DDD 的同學應該知道，聚合設計有一個原則，就是：聚合內(nèi)強一致性，聚合之間最終一致性。經(jīng)過上面的分析，我們知道要產(chǎn)生一張票，其實要影響很多和這個票對應的線段相交的其他票的可用數(shù)量。因為所有的站點信息都在車次聚合內(nèi)部，所以車次聚合內(nèi)部自然可以維護所有的原子區(qū)間，以及每個原子區(qū)間的可用票數(shù)（相當于是庫存數(shù)）。當一個原子區(qū)間的可用票數(shù)為 0 的時候，意味著火車針對這個區(qū)間的票已經(jīng)賣完了。所以，我們完全可以讓車次這個聚合根來保證出票時對所有原子區(qū)間的可用票數(shù)的更新的強一致性。對于車次聚合根來說，這很簡單，因為只是幾次簡單的內(nèi)存操作而已，耗時可以忽略。一列火車假如有 ABCD 四個站點，那原子區(qū)間就是 3 個。對于 G71，則是 16 個。

2、怎么判斷是否能出票？

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

根據(jù)訂單信息，拿到出發(fā)地和目的地，然后獲取這段區(qū)間里的所有的原子區(qū)間。然后嘗試將每個原子區(qū)間的可用票數(shù)減 1，如果所有的原子區(qū)間都夠減，則購票成功；否則購票失敗，提示用戶該票已經(jīng)賣完了。是不是很簡單呢？知道了出票的邏輯，那退票的邏輯也就很簡單了，就是把這個票的所有原子區(qū)間的可用票數(shù)加 1 就 OK 了。如果我們從線段的厚度的角度去考慮，那出票時，每個原子區(qū)間的厚度就是 +1，退票時就是減一。就是相反的操作，但本質是一樣的。

所以，通過這樣的思路，我們將一次訂票的處理控制在了一個聚合根里，用聚合根內(nèi)的強一致性的特性保證了訂票處理的強一致性，同時也保證了性能，免去了并發(fā)沖突的可能性。傳統(tǒng)電商那種把票單做類似商品的核心聚合根的設計，我當時第一眼看到就覺得不妥。因為這違背了 DDD 強調的強一致性應該由聚合根來保證、聚合根之間的最終一致性通過 Saga 來保證的原則。

還有一個很重要的概念我想說一下我的看法，就是座位和區(qū)間的關系。因為有些朋友和我講，考慮座位號的問題，雖然都能減 1，座位號也必須是同一個。我覺得座位是全局共享的，和區(qū)段無關（也許我的理解完全有誤，請大家指正）。座位是一個物理概念，一個用戶成功購買了一張票后，座位就會少一個，一張票唯一對應一個座位，但是一個座位有可能會對應多張票；而區(qū)間是一個邏輯上的概念，區(qū)間的作用有兩個：1）表示票的出發(fā)地和目的地；2）記錄票的可用數(shù)額。如果區(qū)間能連通（即該區(qū)間內(nèi)的每個原子區(qū)間的可用數(shù)額都大于 0），則表示允許擁有一個座位。所以，我覺得座位和票（區(qū)間）是兩個維度的概念。

3、如何為票分配座位？

我覺得車次聚合根內(nèi)部應該維護所有該車次已經(jīng)售出的票，已經(jīng)出售的票的的本質是區(qū)間和座位的對應關系。系統(tǒng)處理訂票時，用戶提交過來的是一段區(qū)間。所以，系統(tǒng)應該做兩個事情：

1. 先根據(jù)區(qū)間去判斷是否有可用的座位；
2. 如果有可用座位，則再通過算法去選擇一個可用的座位；

當?shù)玫揭粋€可用座位后，就可以生成一張票了，然后保存這個票到車次聚合根內(nèi)部即可。下面舉個例子：

假設現(xiàn)在的情況是座位有 3 個，站點有 4 個：

座位：1,2,3

站點：abcd

票的賣法 1：

票 1：ab,1

票 2：bc,2

票 3：cd,3

票 4：ac,3

票 5：bd,1

這種選座位的方式應該比較高效，因為總是優(yōu)先從座位池里去拿座位，只有在萬不得已的時候才會去回收可重復利用的票。

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

票的賣法 2：

票 1：ab,1

票 2：bc,1

票 3：cd,1

票 4：ac,2

票 5：bd,3

這種選座位的方式應該相對低效，因為總是優(yōu)先會去掃描是否有可回收的座位，而掃描相對直接從座位池里去拿票總是成本相對要高的。

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

但是，優(yōu)先從座位池里拿票的算法有缺陷，就是會出現(xiàn)雖然第一步判斷認為有可用的座位，但是這個座位可能不是全程都是同一個座位。舉例：

假設現(xiàn)在的情況是座位有 3 個，站點有 4 個：

座位：1,2,3

站點：abcd

票的賣法 3：

票 1：ab,1

票 2：bc,2

票 3：cd,3

現(xiàn)在如果有人要買 ad 的票，那可用的座位有 2，或者 3。但是無論是 2 還是 3，都要這個乘客中途換車位。比如賣給他座位 2，那他 ab 是坐的座位 2，但是 bc 的時候要坐座位 1 的。否則拿票 2 的那個人上車時，發(fā)現(xiàn)座位 2 已經(jīng)有人了。而通過優(yōu)先回收利用的算法，是沒這個問題的。

所以，從上面的分析我們也知道選座位的算法該怎么寫了，就是采用優(yōu)先回收利用座位的算法。我認為不管我們這里怎么設計算法，都不影響大局，因為這一切都只發(fā)生在車次聚合根內(nèi)部，這就是預先設計好聚合根，明確出票職責在哪個對象上的好處。

4、模型分析總結

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

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

• 判斷是否可出票；
• 選擇可用的座位；
• 更新一次出票時所有原子區(qū)間的可用票數(shù)，用于判斷下次是否能出票；
• 維護所有已售出的票，用于為選擇可用座位提供依據(jù)。

通過這樣的模型設計，我們可以確保一次出票處理只會在一個車次聚合根內(nèi)進行。這樣的好處是：

1. 不需要依賴數(shù)據(jù)庫事務就能實現(xiàn)數(shù)據(jù)修改的強一致性，因為所有修改只在一個聚合根內(nèi)發(fā)生；
2. 在保證數(shù)據(jù)強一致性的同時還能提供很高的并發(fā)處理能力，具體設計見下面的架構設計。

4、架構設計

我覺得 12306 這樣的業(yè)務場景，非常適合使用 CQRS 架構；因為首先它是一個查多寫少、但是寫的業(yè)務邏輯非常復雜的系統(tǒng)。所以，非常適合做架構層面的讀寫分離，即采用 CQRS 架構。而且應該使用數(shù)據(jù)存儲也分離的 CQRS。這樣 CQ 兩端才可以完全不需要顧及對方的問題，各自優(yōu)化自己的問題即可。我們可以在 C 端使用 DDD 領域模型的思路，用良好設計的領域模型實現(xiàn)復雜的業(yè)務規(guī)則和業(yè)務邏輯。而 Q 端則使用分布式緩存方案，實現(xiàn)可伸縮的查詢能力。

1、訂票的實現(xiàn)思路

同時借助像 ENode 這樣的框架，我們可以實現(xiàn) in-memory + Event Sourcing 的架構。Event Sourcing 技術，可以讓領域模型的所有狀態(tài)修改的持久化統(tǒng)一起來，本來要用 ORM 的方式保存聚合根最新狀態(tài)的，現(xiàn)在只需要簡單的通用的方式保存一個事件即可（一次訂票只涉及一個車次聚合根的修改，修改只產(chǎn)生一個事件，只需要持久化一個事件（一個 JSON 串）即可，保證了高性能，無須依賴事務，而且通過 ENode 可以解決并發(fā)問題）。

我們只要保存了聚合根每次變化的事件（事件的結構怎么設計，本文不做多的介紹了，大家可以思考下），就相當于保存了聚合根的最新狀態(tài)。而正是由于 Event Sourcing 技術的引入，讓我們的模型可以一直存活在內(nèi)存中，即可以使用 in-memory 技術。不要小看 in-memory 技術，in-memory 技術在某些方面對提高命令的處理性能非常有幫助。

比如就以我們車次聚合根處理出票的邏輯，假設某個車次有大量的命令發(fā)送到分布式消息隊列，然后有一臺機器訂閱了這個隊列的消息，然后這臺機器處理這個車次的訂票命令時，由于這個車次聚合根一直在內(nèi)存，所以就省去了每次要去數(shù)據(jù)庫取出聚合根的步驟，相當于少了一次數(shù)據(jù)庫 IO。

這樣的好處是，因為一個車次能夠真正出售的票是有限的，因為座位就那么幾個，比如就 1000 個座位，估計一般正常情況也就出個 2000 個左右的票吧（具體能出多少張票要取決于區(qū)間的相交程度，上面分析過）。也就是說，這個聚合根只會產(chǎn)生 2000 個事件，也就是說只會有 2000 個訂票命令的處理是會產(chǎn)生事件，并持久化事件；而其余的大量命令，因為車次在內(nèi)存計算后發(fā)現(xiàn)沒有余票了，就不會做任何修改，也不會產(chǎn)生領域事件，這樣就可以直接處理下一個訂票命令了。這樣就可以大大提高處理訂票命令的性能。

另外一個問題我覺得還需要提一下，因為用戶訂票成功后，還需要付款。但用戶有可能不去付款或者沒有在規(guī)定的時間內(nèi)完成付款。那這種情況下，系統(tǒng)會自動釋放該用戶之前訂購的票。所以基于這樣的需求，我們在業(yè)務上需要支持業(yè)務級別的 2pc。即先預扣庫存，也就是先占住這張票一定時間（比如 15 分鐘），然后付款成功后再真實給你這張票，系統(tǒng)做真正的庫存修改。

通過這樣的預扣處理，可以保證不會出現(xiàn)超賣的情況。這個思路其實和傳統(tǒng)電商比如淘寶這樣的系統(tǒng)類似，我就不多展開了，我之前寫的 Conference 案例也是這樣的思路，大家有興趣的可以去看一下我之前錄制的視頻。

2、查詢余票的實現(xiàn)思路

我覺得余票的查詢的實現(xiàn)相對簡單。雖然對于 12306 來說，查詢的請求占了 80%，提交訂單的請求只占 20%。但查詢由于對數(shù)據(jù)沒有修改，所以我們完全可以使用分布式緩存來實現(xiàn)。我們只需要精心設計好緩存的 key 即可；緩存 key 的多少要看成本，如果所有可能的查詢都設計對應的 key，那時間復雜度為 1，查詢性能自然高；但代價也大，因為 key 多了。如果想 key 少一點，那查詢的復雜度自然要上去一點。所以緩存設計無非就是空間換時間的思路。然后，緩存的更新無非就是：自動失效、定時更新、主動通知 3 種。通過 CQRS 架構，由于 CQ 兩端是事件驅動的，當 C 端有任何狀態(tài)變化，都會產(chǎn)生對應的事件去通知 Q 端，所以我們幾乎可以做到 Q 端的準實時更新。

同時由于 CQ 兩端的完全解耦，Q 端我們可以設計多種存儲，如數(shù)據(jù)庫和緩存（Redis 等）；數(shù)據(jù)庫用于線下維護關系型數(shù)據(jù)，緩存用戶實時查詢。數(shù)據(jù)庫和緩存的更新速度相互不受影響，因為是并行的。對同一個事件，可以 10 臺機器負責更新緩存，100 臺機器負責更新數(shù)據(jù)庫。即便數(shù)據(jù)庫的更新很慢，也不會影響緩存的更新進度。這就是 CQRS 架構的好處，CQ 的架構完全不同，且我們隨時可以重建一種新的 Q 端存儲。不知道大家體會到了沒有？

關于緩存 key 的設計，我覺得主要從查詢余票時傳遞的信息來考慮。12306 的關鍵查詢是：出發(fā)地、目的地、出發(fā)日期三個信息。我覺得有兩種 key 的設計思路：

1. 直接設計了該查詢條件的 key，然后快速拿到車次信息，直接返回；這種方式就是要求我們系統(tǒng)已經(jīng)枚舉了所有車次的所有可能出現(xiàn)的票（區(qū)間）的緩存 key，相信你一定知道這樣的 key 是非常多的。
2. 不是枚舉所有區(qū)間，而是把每個車次的每個原子區(qū)間（相鄰的兩個站點所連成的直線）的可用票數(shù)作為 key。這樣，key 就非常少了，因為車次假如有 10000 個，然后每個車次平均 15 個區(qū)間，那也就 15W 個 key 而已。當我們要查詢時，只需要把用戶輸入的出發(fā)地和目的地之間的所有原子區(qū)間的可用票數(shù)都查出來，然后比較出最小可用票數(shù)的那個原子區(qū)間。則這個原子區(qū)間的可用票數(shù)就是用戶輸入的區(qū)間的可用票數(shù)了。當然，到這里我提到考慮出發(fā)日期。我認為出發(fā)日期是用來決定具體是哪個車次聚合根的。同一個車次，不同的日期，對應的聚合根實例是不同的，即便是同一天，也可能有多個車次聚合根，因為有些車次一天有幾班的，比如上午 9 點發(fā)車的一班，下午 3 點發(fā)車的一般。所以，我們也只要把日期也作為緩存 key 的一部分即可。

總結

本文完全是憑自己對 12306 這個網(wǎng)站的核心業(yè)務的簡單思考而得到的一些設計結果。如果真正的 DDD 領域建模，更多的是要和業(yè)務一線的工作人員、領域專家進行深入溝通，才能更深入的了解該領域內(nèi)的業(yè)務知識，從而才能設計出更靠譜的領域模型和架構設計。

非常慚愧，我沒有上 12306 買過火車票，家離的比較近，就算要買也是家人給我買:）所以，本文所分享的內(nèi)容難免是紙上談兵。但我覺得 12306 這個系統(tǒng)的業(yè)務確實比傳統(tǒng)的電商系統(tǒng)要復雜，且并發(fā)又這么高。所以，我覺得這個系統(tǒng)真的很值得大家重視模型的設計，而不只是只關注技術層面的實現(xiàn)。

注：相關網(wǎng)站建設技巧閱讀請移步到建站教程頻道。

網(wǎng)站欄目：換個思路看12306，其核心模型設計思路到底復雜在
網(wǎng)站URL：http://www.bm7419.com/news37/86737.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、建站公司、搜索引擎優(yōu)化、App設計、標簽優(yōu)化、移動網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)