2020-09-26 分類: 網(wǎng)站建設(shè)
編者按:本文作者湯雪華,網(wǎng)名 netfocus,2006年 畢業(yè)于浙江大學(xué),目前住在杭州。對(duì) DDD,以及 CQRS 架構(gòu)比較感興趣。目前一直致力于開發(fā)和完善 ENode、EQueue。文章首發(fā)于微信公眾號(hào)InfoQ(ID:infoqchina)。
元宵節(jié)結(jié)束,年就真的過(guò)完了。揮別故里,回到打拼的城市,理性思維是否也跟著工作狀態(tài)一起回歸了呢?每一年的春運(yùn)都是對(duì) 12306 的一次大考,拋去盲從和偏見,讓我們用工程師的思維重新打量、從業(yè)務(wù)分析的角度去探討,12306 的核心模型設(shè)計(jì)思路和架構(gòu)設(shè)計(jì)到底復(fù)雜在哪里?
為什么我要研究這個(gè)問(wèn)題?
春節(jié)期間,無(wú)意中看到一篇文章,文章中講到 12306 的業(yè)務(wù)復(fù)雜度遠(yuǎn)遠(yuǎn)比淘寶天貓這種電商網(wǎng)站要復(fù)雜。后來(lái)自己想想,也確實(shí)如此。所以,很想挑戰(zhàn)一下 12306 這個(gè)系統(tǒng)的核心領(lǐng)域模型的設(shè)計(jì)。一般的電商網(wǎng)站,購(gòu)買都是基于商品的概念,每個(gè)商品有一定量的庫(kù)存,用戶的購(gòu)買行為是針對(duì)商品的。當(dāng)用戶發(fā)起購(gòu)買行為時(shí),系統(tǒng)只需要生成訂單并對(duì)用戶要購(gòu)買的商品減庫(kù)存即可。但是,12306 就不是那么簡(jiǎn)單了,具體復(fù)雜在哪里,我下面會(huì)進(jìn)一步分析。
另外一個(gè)讓我寫這篇文章的原因,是我發(fā)現(xiàn)也許是否是因?yàn)槟壳?12306 的核心領(lǐng)域模型設(shè)計(jì)的不夠好,導(dǎo)致用戶購(gòu)票時(shí)要處理的業(yè)務(wù)邏輯異常復(fù)雜,維護(hù)數(shù)據(jù)一致性的難度也幾百倍的上升,同時(shí)面對(duì)高并發(fā)的訂票也難以支持很高的 TPS。我覺得,越是復(fù)雜的業(yè)務(wù),就越要重視業(yè)務(wù)分析,重視領(lǐng)域模型的抽象和設(shè)計(jì)。如果不假思索,憑以往經(jīng)驗(yàn)行事,則很可能會(huì)被以往的設(shè)計(jì)經(jīng)驗(yàn)先入為主,陷入死胡同。
技術(shù)人員往往更注重技術(shù)層面的解決方案,比如一上來(lái)就分析如何集群、如何負(fù)載均衡、如何排隊(duì)、如何分庫(kù)分表、如何用鎖,如何用緩存等技術(shù)問(wèn)題,而忽略了最根本的業(yè)務(wù)層面的思考,如分析業(yè)務(wù)、領(lǐng)域建模。我認(rèn)為越是復(fù)雜的業(yè)務(wù)系統(tǒng),則越要設(shè)計(jì)一個(gè)健壯的領(lǐng)域模型。如果一個(gè)系統(tǒng)的架構(gòu)我們?cè)O(shè)計(jì)錯(cuò)了,還有補(bǔ)救的余地,因?yàn)榧軜?gòu)最終沉淀的只是代碼,調(diào)整架構(gòu)即可(一個(gè)系統(tǒng)的架構(gòu)本身就是不斷演進(jìn)的);而如果領(lǐng)域模型設(shè)計(jì)錯(cuò)了,那要補(bǔ)救的代價(jià)是非常大的,因?yàn)轭I(lǐng)域模型沉淀的是數(shù)據(jù)結(jié)構(gòu)及其對(duì)應(yīng)的大量數(shù)據(jù),對(duì)任何一個(gè)大型系統(tǒng),要改核心領(lǐng)域模型都是成本非常高的。
本文的重點(diǎn)不是在如何解決高并發(fā)的問(wèn)題,而是希望從業(yè)務(wù)角度去分析,12306 的理想模型應(yīng)該是怎么樣的。網(wǎng)上目前談 12306 的文章貌似都是千篇一律的只談技術(shù),不談業(yè)務(wù)分析和如何建模的。所以我想寫一下自己的設(shè)計(jì)和大家交流學(xué)習(xí)。
1、需求概述
12306 這個(gè)系統(tǒng),核心要解決的問(wèn)題是網(wǎng)上售票。涉及到 2 個(gè)角色使用該系統(tǒng):用戶、鐵道部。用戶的核心訴求是查詢余票、購(gòu)票;鐵道部的核心訴求是售票。購(gòu)票和售票其實(shí)是一個(gè)場(chǎng)景,對(duì)用戶來(lái)說(shuō)是購(gòu)票,對(duì)鐵道部來(lái)說(shuō)是售票。因此,我們要設(shè)計(jì)一個(gè)在線的網(wǎng)站系統(tǒng),解決用戶的查詢余票、購(gòu)票,以及鐵道部的售票這 3 個(gè)核心訴求。看起來(lái),這 3 個(gè)場(chǎng)景都是圍繞火車票展開的。
查詢余票:用戶輸入出發(fā)地、目的地、出發(fā)日三個(gè)條件,查詢可能存在的車次,用戶可以看到每個(gè)車次經(jīng)過(guò)的站點(diǎn)名稱,以及每種座位的余票數(shù)量。
購(gòu)票:購(gòu)票分為訂票和付款兩個(gè)階段,本文重點(diǎn)分析訂票的模型設(shè)計(jì)和實(shí)現(xiàn)思路。
其實(shí)還有很多其他的需求,比如給不同的車次設(shè)定銷售座位數(shù)配額,以及不同的區(qū)段設(shè)置不同的限額。但相比前面兩個(gè)需求來(lái)說(shuō),我覺得這個(gè)需求相對(duì)次要一些。
2、需求分析
確實(shí),12306 也是一個(gè)電商系統(tǒng),而且看起來(lái)商品就是票了。因?yàn)槿绻岩粡埰笨闯墒且粋€(gè)商品,那購(gòu)票就類似于購(gòu)買商品,然后每張票都有庫(kù)存,商品也有庫(kù)存的概念。但是如果我們仔細(xì)想想,會(huì)發(fā)現(xiàn) 12306 要復(fù)雜很多,因?yàn)槲覀儫o(wú)法預(yù)先確定好所有的票,如果非要確定,那只能通過(guò)窮舉法了。
我們以北京西到深圳北的 G71 車次高鐵為例(這里只考慮南下的方向,不考慮深圳北到北京西的,那是另外一個(gè)車次,叫 G72),它有 17 個(gè)站(北京西是 01號(hào)站,深圳北是 17號(hào)站),3 種座位(商務(wù)、一等、二等)。表面看起來(lái),這不就是 3 個(gè)商品嗎?G71 商務(wù)座、G71 一等座、G71 二等座。大部分輕易噴 12306 的技術(shù)人員(包括某些中等規(guī)模公司的專家、CTO)就是在這里栽第一個(gè)跟頭的。實(shí)際上,G71 有 136*3=408 種商品(408 個(gè) SKU),怎么算來(lái)的?如下:
如果賣北京西始發(fā)的,有 16 種賣法(因?yàn)楹竺嬗?16 個(gè)站),北京西到:保定、石家莊、鄭州、武漢、長(zhǎng)沙、廣州、虎門、深圳。。。。都是一個(gè)獨(dú)立的商品,同理,石家莊上車的,有 15 種下車的可能,以此類推,單以上下車的站來(lái)計(jì)算,有 136 種票:16+15+14....+2+1=136。每種票都有 3 種座位,一共是 408 個(gè)商品。
為了方便后面的討論,我們先明確一下票是什么?
一張票的核心信息包括:出發(fā)時(shí)間、出發(fā)地、目的地、車次、座位號(hào)。持有票的人就擁有了一個(gè)憑證,該憑證表示持有它的人可以坐某個(gè)車次的某個(gè)座位號(hào),從某地到某地。所以,一張票,對(duì)用戶來(lái)說(shuō)是一個(gè)憑證,對(duì)鐵道部來(lái)說(shuō)是一個(gè)承諾;那對(duì)系統(tǒng)來(lái)說(shuō)是什么呢?不知道。這就是我們要分析業(yè)務(wù),領(lǐng)域建模的原因,我們?cè)倮^續(xù)思考吧。
明白了票的核心信息后,我們?cè)倏纯?G71 這個(gè)車次的高鐵,可以賣多少?gòu)埰保?/p>
討論前先說(shuō)明一下,一輛火車的物理座位數(shù)(站票也可以看成是一種座位,因?yàn)檎酒币灿袛?shù)量配額)不等于可用的大配合。所有的物理座位不可能都通過(guò) 12306 網(wǎng)站來(lái)銷售,而是只會(huì)銷售一部分,比如 40%。其余的還是會(huì)通過(guò)線下的方式銷售。不僅如此,可能有些站點(diǎn)上車的人會(huì)比較多,有些比較少,所以我們還會(huì)給不同的區(qū)間配置不同的限額。
比如 D31 北京南至上海共有 765 張,北京南有 260 張,楊柳青有 80 張,泰安有 76 張。如果楊柳青的 80 張票售完就會(huì)顯示無(wú)票,就算其他站有票也會(huì)顯示無(wú)票的。每個(gè)車次肯定會(huì)有各種座位的配額和限額的配置的,這種配置我目前無(wú)法預(yù)料,但我已經(jīng)把這些規(guī)則都封裝近車次聚合根里了,所有的配置策略都是基于座位類型、站點(diǎn)、區(qū)間配置的。關(guān)于票的配置抽象出來(lái),我覺得主要有 3 種:
當(dāng)用戶訂票時(shí),把用戶指定的區(qū)段和這 3 種配置條件進(jìn)行比較,3 個(gè)條件都滿足,則可以出票。不滿足,則認(rèn)為無(wú)票了。下面舉個(gè)例子:
ABCDEFG,這是所有站點(diǎn)。座位總配額是 100,假設(shè) B 站點(diǎn)上車,E 站下車的人比較少,那我們就可以設(shè)定 BE 這個(gè)區(qū)段最多只能出 10 張票。所以,只要是用戶的訂票是在這個(gè)區(qū)段內(nèi)的,就最多出 10 張。再比如,一列車次,總共 100 個(gè)座位配額,希望全程票最少滿足 80 張,那我們只要給 AG 這個(gè)區(qū)段設(shè)定最少 80 張。那任何訂票請(qǐng)求,如果是子區(qū)間的,就不能超過(guò) 100-80,即 20 張。這兩種條件必須同時(shí)滿足,才允許出票。
但是,不管如何做配額和限額,我們總是針對(duì)某個(gè)車次進(jìn)行配置,這些配置只是車次內(nèi)部售票時(shí)的一些額外的判斷條件(業(yè)務(wù)規(guī)則),不影響車次模型的核心地位和對(duì)外暴露的功能。所以,為了本文討論的清楚起見,我后續(xù)的討論都不涉及配額和限額的問(wèn)題,而是認(rèn)為任何區(qū)段都可以享受火車大的物理座位數(shù)。
并且,為了討論問(wèn)題方便,我們減少一些站點(diǎn)來(lái)討論。假設(shè)某個(gè)車次有 A,B,C,D 四個(gè)站點(diǎn)。那 001 這個(gè)人購(gòu)買了 A,B 這個(gè)區(qū)間,系統(tǒng)會(huì)分配給 001 一個(gè)座位 x;但是因?yàn)?001 坐到 B 站點(diǎn)后會(huì)下車,所以相當(dāng)于 x 這個(gè)座位又空出來(lái)了,也就是說(shuō),從 B 站點(diǎn)開始,系統(tǒng)又可以認(rèn)為 x 這個(gè)座位是可用的。所以,我們得出結(jié)論:同一個(gè)座位,其實(shí)可以同時(shí)出售 AB,BC 這兩張票。通過(guò)這個(gè)簡(jiǎn)單的分析,我們知道,一列火車雖然只有有限的座位數(shù),比如 1000 個(gè)座位。但可以賣出的票遠(yuǎn)遠(yuǎn)不止 1000 個(gè)。
還是以 A,B,C,D 四個(gè)站點(diǎn)為例,假如火車總共有 1000 個(gè)座位,那 AB 可以賣 1000 張,BC 也可以賣 1000 張,同樣,CD 也可以賣 1000 張。也就是說(shuō),理論上最多可以賣出 3000 張票。但是如果換一種賣法,所有人都是買 ABCD 的票,也就是說(shuō)所有的票都是經(jīng)過(guò)所有站點(diǎn)的,那就是最多只能賣出 1000 張票了。而實(shí)際的場(chǎng)景,一定是介于 1000 到 3000 之間。然后實(shí)際的 G71 這個(gè)車次,有 17 個(gè)站,那到底可以賣出多少個(gè)票,大家應(yīng)該可以算了吧。理論上這 17 個(gè)站中的任意兩個(gè)站點(diǎn)之間所形成的線段,都可以出售為一張票。我數(shù)學(xué)不好,算不太清楚,麻煩有數(shù)學(xué)好的人幫我算算,呵呵。
通過(guò)上面的分析,我們知道一張票的本質(zhì)是某個(gè)車次的某一段區(qū)間(一條線段),這個(gè)區(qū)間包含了若干個(gè)站點(diǎn)。然后我們還發(fā)現(xiàn),只要區(qū)間不重疊,那座位就不會(huì)發(fā)生競(jìng)爭(zhēng),可以被回收利用,也就是說(shuō),可以同時(shí)預(yù)先出售。
另外,經(jīng)過(guò)更深入的分析,我們還發(fā)現(xiàn)區(qū)間有 4 種關(guān)系:
不重疊的情況我們已經(jīng)討論過(guò)了,而覆蓋也是重疊的一種。所以我們發(fā)現(xiàn)如果重疊,比如有兩個(gè)區(qū)間發(fā)生重疊,那重疊部分的區(qū)間(可能夸一個(gè)或多個(gè)站點(diǎn))是在爭(zhēng)搶座位的。因?yàn)榧僭O(shè)一列火車有 100 個(gè)座位,那每個(gè)原子區(qū)間(兩個(gè)相鄰站點(diǎn)的連線),最多允許重疊 99 次。
所以,經(jīng)過(guò)上面的分析,我們知道了一個(gè)車次能夠出售一張車票的核心業(yè)務(wù)規(guī)則是什么?就是:這張車票所包含的每個(gè)原子區(qū)間的重疊次數(shù)加 1 都不能超過(guò)車次的總座位數(shù),實(shí)際上重疊次數(shù) +1 也可以理解為線段的厚度。
3、模型設(shè)計(jì)
上面我分析了一下票的本質(zhì)是什么。那接下來(lái)我們?cè)賮?lái)看看怎么設(shè)計(jì)模型,來(lái)快速實(shí)現(xiàn)購(gòu)票的需求,重點(diǎn)是怎么設(shè)計(jì)商品聚合以及減庫(kù)存的邏輯。
傳統(tǒng)電商的思路
如果按照普通電商的思路,把票(站點(diǎn)區(qū)間)設(shè)計(jì)為商品(聚合根),然后為票設(shè)計(jì)庫(kù)存數(shù)量。我個(gè)人覺得是很糟糕的。因?yàn)橐环矫孢@種聚合根非常多(上面的 G71 就有 408 個(gè));另一方面,即便枚舉出來(lái)了,一次購(gòu)票也一定會(huì)影響非常多其他聚合根的庫(kù)存數(shù)量(只要被部分或全部重疊的區(qū)間都受影響)。這樣的一次訂單處理的復(fù)雜度是難以評(píng)估的。而且這么多聚合根的更新要在一個(gè)事務(wù)里,這不是為難數(shù)據(jù)庫(kù)嗎?而且,這種設(shè)計(jì)必然帶來(lái)大量的事務(wù)的并發(fā)沖突,很可能導(dǎo)致數(shù)據(jù)庫(kù)死鎖。
總之,我認(rèn)為這種是典型的由于領(lǐng)域模型的設(shè)計(jì)錯(cuò)誤,導(dǎo)致并發(fā)沖突高、數(shù)據(jù)持久化落地困難?;蛘呷绻鉀Q并發(fā)問(wèn)題,只能排隊(duì)單線程處理,但是仍然解決不了要在一個(gè)事務(wù)里修改大量聚合根的尷尬局面。
聽說(shuō) 12306 是采用了 Pivotal Gemfire 這種高大上的內(nèi)存數(shù)據(jù)庫(kù),我對(duì)這個(gè)不太了解。我不可想象要是不使用內(nèi)存數(shù)據(jù)庫(kù),他們要怎么實(shí)現(xiàn)車次內(nèi)的票之間的數(shù)據(jù)強(qiáng)一致性(就是保證所有出售的票都是符合上面討論的業(yè)務(wù)規(guī)則的)?所以,這種設(shè)計(jì),我個(gè)人認(rèn)為是思維定勢(shì)了,把火車票看成是普通電商的商品來(lái)看待。所以,我們有時(shí)做設(shè)計(jì)又要依賴于經(jīng)驗(yàn),又要不能被以往經(jīng)驗(yàn)所束縛,真的不容易,關(guān)鍵還是要根據(jù)具體的業(yè)務(wù)場(chǎng)景多多深入分析,盡量分析抽象出問(wèn)題的本質(zhì)出來(lái),這樣才能對(duì)癥下藥。那是否有其他的設(shè)計(jì)思路呢?
我的思路
1、聚合設(shè)計(jì)
通過(guò)上面的分析我們知道,其實(shí)任何一次購(gòu)票都是針對(duì)某個(gè)車次的,我認(rèn)為車次是負(fù)責(zé)處理訂票的聚合根。我們看看一個(gè)車次包含了哪些信息?一個(gè)車次包括了:
2、怎么判斷是否能出票?
基于上面的聚合設(shè)計(jì),出票時(shí)扣減庫(kù)存的邏輯是:
根據(jù)訂單信息,拿到出發(fā)地和目的地,然后獲取這段區(qū)間里的所有的原子區(qū)間。然后嘗試將每個(gè)原子區(qū)間的可用票數(shù)減 1,如果所有的原子區(qū)間都?jí)驕p,則購(gòu)票成功;否則購(gòu)票失敗,提示用戶該票已經(jīng)賣完了。是不是很簡(jiǎn)單呢?知道了出票的邏輯,那退票的邏輯也就很簡(jiǎn)單了,就是把這個(gè)票的所有原子區(qū)間的可用票數(shù)加 1 就 OK 了。如果我們從線段的厚度的角度去考慮,那出票時(shí),每個(gè)原子區(qū)間的厚度就是 +1,退票時(shí)就是減一。就是相反的操作,但本質(zhì)是一樣的。
所以,通過(guò)這樣的思路,我們將一次訂票的處理控制在了一個(gè)聚合根里,用聚合根內(nèi)的強(qiáng)一致性的特性保證了訂票處理的強(qiáng)一致性,同時(shí)也保證了性能,免去了并發(fā)沖突的可能性。傳統(tǒng)電商那種把票單做類似商品的核心聚合根的設(shè)計(jì),我當(dāng)時(shí)第一眼看到就覺得不妥。因?yàn)檫@違背了 DDD 強(qiáng)調(diào)的強(qiáng)一致性應(yīng)該由聚合根來(lái)保證、聚合根之間的最終一致性通過(guò) Saga 來(lái)保證的原則。
還有一個(gè)很重要的概念我想說(shuō)一下我的看法,就是座位和區(qū)間的關(guān)系。因?yàn)橛行┡笥押臀抑v,考慮座位號(hào)的問(wèn)題,雖然都能減 1,座位號(hào)也必須是同一個(gè)。我覺得座位是全局共享的,和區(qū)段無(wú)關(guān)(也許我的理解完全有誤,請(qǐng)大家指正)。座位是一個(gè)物理概念,一個(gè)用戶成功購(gòu)買了一張票后,座位就會(huì)少一個(gè),一張票唯一對(duì)應(yīng)一個(gè)座位,但是一個(gè)座位有可能會(huì)對(duì)應(yīng)多張票;而區(qū)間是一個(gè)邏輯上的概念,區(qū)間的作用有兩個(gè):1)表示票的出發(fā)地和目的地;2)記錄票的可用數(shù)額。如果區(qū)間能連通(即該區(qū)間內(nèi)的每個(gè)原子區(qū)間的可用數(shù)額都大于 0),則表示允許擁有一個(gè)座位。所以,我覺得座位和票(區(qū)間)是兩個(gè)維度的概念。
3、如何為票分配座位?
我覺得車次聚合根內(nèi)部應(yīng)該維護(hù)所有該車次已經(jīng)售出的票,已經(jīng)出售的票的的本質(zhì)是區(qū)間和座位的對(duì)應(yīng)關(guān)系。系統(tǒng)處理訂票時(shí),用戶提交過(guò)來(lái)的是一段區(qū)間。所以,系統(tǒng)應(yīng)該做兩個(gè)事情:
當(dāng)?shù)玫揭粋€(gè)可用座位后,就可以生成一張票了,然后保存這個(gè)票到車次聚合根內(nèi)部即可。下面舉個(gè)例子:
假設(shè)現(xiàn)在的情況是座位有 3 個(gè),站點(diǎn)有 4 個(gè):
座位:1,2,3
站點(diǎn):abcd
票的賣法 1:
票 1:ab,1
票 2:bc,2
票 3:cd,3
票 4:ac,3
票 5:bd,1
這種選座位的方式應(yīng)該比較高效,因?yàn)榭偸莾?yōu)先從座位池里去拿座位,只有在萬(wàn)不得已的時(shí)候才會(huì)去回收可重復(fù)利用的票。
上面的 4,5 兩個(gè)票,就是考慮回收利用的結(jié)果。
票的賣法 2:
票 1:ab,1
票 2:bc,1
票 3:cd,1
票 4:ac,2
票 5:bd,3
這種選座位的方式應(yīng)該相對(duì)低效,因?yàn)榭偸莾?yōu)先會(huì)去掃描是否有可回收的座位,而掃描相對(duì)直接從座位池里去拿票總是成本相對(duì)要高的。
上面的 2,3 兩個(gè)票,就是考慮回收利用的結(jié)果。
但是,優(yōu)先從座位池里拿票的算法有缺陷,就是會(huì)出現(xiàn)雖然第一步判斷認(rèn)為有可用的座位,但是這個(gè)座位可能不是全程都是同一個(gè)座位。舉例:
假設(shè)現(xiàn)在的情況是座位有 3 個(gè),站點(diǎn)有 4 個(gè):
座位:1,2,3
站點(diǎn):abcd
票的賣法 3:
票 1:ab,1
票 2:bc,2
票 3:cd,3
現(xiàn)在如果有人要買 ad 的票,那可用的座位有 2,或者 3。但是無(wú)論是 2 還是 3,都要這個(gè)乘客中途換車位。比如賣給他座位 2,那他 ab 是坐的座位 2,但是 bc 的時(shí)候要坐座位 1 的。否則拿票 2 的那個(gè)人上車時(shí),發(fā)現(xiàn)座位 2 已經(jīng)有人了。而通過(guò)優(yōu)先回收利用的算法,是沒(méi)這個(gè)問(wèn)題的。
所以,從上面的分析我們也知道選座位的算法該怎么寫了,就是采用優(yōu)先回收利用座位的算法。我認(rèn)為不管我們這里怎么設(shè)計(jì)算法,都不影響大局,因?yàn)檫@一切都只發(fā)生在車次聚合根內(nèi)部,這就是預(yù)先設(shè)計(jì)好聚合根,明確出票職責(zé)在哪個(gè)對(duì)象上的好處。
4、模型分析總結(jié)
我認(rèn)為票不是核心聚合根,票只是一次出票的結(jié)果,一個(gè)憑證而已。
12306 真正的核心聚合根應(yīng)該是車次,車次具有出票的職責(zé),一次出票具體做的事情有:
通過(guò)這樣的模型設(shè)計(jì),我們可以確保一次出票處理只會(huì)在一個(gè)車次聚合根內(nèi)進(jìn)行。這樣的好處是:
4、架構(gòu)設(shè)計(jì)
我覺得 12306 這樣的業(yè)務(wù)場(chǎng)景,非常適合使用 CQRS 架構(gòu);因?yàn)槭紫人且粋€(gè)查多寫少、但是寫的業(yè)務(wù)邏輯非常復(fù)雜的系統(tǒng)。所以,非常適合做架構(gòu)層面的讀寫分離,即采用 CQRS 架構(gòu)。而且應(yīng)該使用數(shù)據(jù)存儲(chǔ)也分離的 CQRS。這樣 CQ 兩端才可以完全不需要顧及對(duì)方的問(wèn)題,各自優(yōu)化自己的問(wèn)題即可。我們可以在 C 端使用 DDD 領(lǐng)域模型的思路,用良好設(shè)計(jì)的領(lǐng)域模型實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)規(guī)則和業(yè)務(wù)邏輯。而 Q 端則使用分布式緩存方案,實(shí)現(xiàn)可伸縮的查詢能力。
1、訂票的實(shí)現(xiàn)思路
同時(shí)借助像 ENode 這樣的框架,我們可以實(shí)現(xiàn) in-memory + Event Sourcing 的架構(gòu)。Event Sourcing 技術(shù),可以讓領(lǐng)域模型的所有狀態(tài)修改的持久化統(tǒng)一起來(lái),本來(lái)要用 ORM 的方式保存聚合根最新狀態(tài)的,現(xiàn)在只需要簡(jiǎn)單的通用的方式保存一個(gè)事件即可(一次訂票只涉及一個(gè)車次聚合根的修改,修改只產(chǎn)生一個(gè)事件,只需要持久化一個(gè)事件(一個(gè) JSON 串)即可,保證了高性能,無(wú)須依賴事務(wù),而且通過(guò) ENode 可以解決并發(fā)問(wèn)題)。
我們只要保存了聚合根每次變化的事件(事件的結(jié)構(gòu)怎么設(shè)計(jì),本文不做多的介紹了,大家可以思考下),就相當(dāng)于保存了聚合根的最新狀態(tài)。而正是由于 Event Sourcing 技術(shù)的引入,讓我們的模型可以一直存活在內(nèi)存中,即可以使用 in-memory 技術(shù)。不要小看 in-memory 技術(shù),in-memory 技術(shù)在某些方面對(duì)提高命令的處理性能非常有幫助。
比如就以我們車次聚合根處理出票的邏輯,假設(shè)某個(gè)車次有大量的命令發(fā)送到分布式消息隊(duì)列,然后有一臺(tái)機(jī)器訂閱了這個(gè)隊(duì)列的消息,然后這臺(tái)機(jī)器處理這個(gè)車次的訂票命令時(shí),由于這個(gè)車次聚合根一直在內(nèi)存,所以就省去了每次要去數(shù)據(jù)庫(kù)取出聚合根的步驟,相當(dāng)于少了一次數(shù)據(jù)庫(kù) IO。
這樣的好處是,因?yàn)橐粋€(gè)車次能夠真正出售的票是有限的,因?yàn)樽痪湍敲磶讉€(gè),比如就 1000 個(gè)座位,估計(jì)一般正常情況也就出個(gè) 2000 個(gè)左右的票吧(具體能出多少?gòu)埰币Q于區(qū)間的相交程度,上面分析過(guò))。也就是說(shuō),這個(gè)聚合根只會(huì)產(chǎn)生 2000 個(gè)事件,也就是說(shuō)只會(huì)有 2000 個(gè)訂票命令的處理是會(huì)產(chǎn)生事件,并持久化事件;而其余的大量命令,因?yàn)檐嚧卧趦?nèi)存計(jì)算后發(fā)現(xiàn)沒(méi)有余票了,就不會(huì)做任何修改,也不會(huì)產(chǎn)生領(lǐng)域事件,這樣就可以直接處理下一個(gè)訂票命令了。這樣就可以大大提高處理訂票命令的性能。
另外一個(gè)問(wèn)題我覺得還需要提一下,因?yàn)橛脩粲喥背晒?,還需要付款。但用戶有可能不去付款或者沒(méi)有在規(guī)定的時(shí)間內(nèi)完成付款。那這種情況下,系統(tǒng)會(huì)自動(dòng)釋放該用戶之前訂購(gòu)的票。所以基于這樣的需求,我們?cè)跇I(yè)務(wù)上需要支持業(yè)務(wù)級(jí)別的 2pc。即先預(yù)扣庫(kù)存,也就是先占住這張票一定時(shí)間(比如 15 分鐘),然后付款成功后再真實(shí)給你這張票,系統(tǒng)做真正的庫(kù)存修改。
通過(guò)這樣的預(yù)扣處理,可以保證不會(huì)出現(xiàn)超賣的情況。這個(gè)思路其實(shí)和傳統(tǒng)電商比如淘寶這樣的系統(tǒng)類似,我就不多展開了,我之前寫的 Conference 案例也是這樣的思路,大家有興趣的可以去看一下我之前錄制的視頻。
2、查詢余票的實(shí)現(xiàn)思路
我覺得余票的查詢的實(shí)現(xiàn)相對(duì)簡(jiǎn)單。雖然對(duì)于 12306 來(lái)說(shuō),查詢的請(qǐng)求占了 80%,提交訂單的請(qǐng)求只占 20%。但查詢由于對(duì)數(shù)據(jù)沒(méi)有修改,所以我們完全可以使用分布式緩存來(lái)實(shí)現(xiàn)。我們只需要精心設(shè)計(jì)好緩存的 key 即可;緩存 key 的多少要看成本,如果所有可能的查詢都設(shè)計(jì)對(duì)應(yīng)的 key,那時(shí)間復(fù)雜度為 1,查詢性能自然高;但代價(jià)也大,因?yàn)?key 多了。如果想 key 少一點(diǎn),那查詢的復(fù)雜度自然要上去一點(diǎn)。所以緩存設(shè)計(jì)無(wú)非就是空間換時(shí)間的思路。然后,緩存的更新無(wú)非就是:自動(dòng)失效、定時(shí)更新、主動(dòng)通知 3 種。通過(guò) CQRS 架構(gòu),由于 CQ 兩端是事件驅(qū)動(dòng)的,當(dāng) C 端有任何狀態(tài)變化,都會(huì)產(chǎn)生對(duì)應(yīng)的事件去通知 Q 端,所以我們幾乎可以做到 Q 端的準(zhǔn)實(shí)時(shí)更新。
同時(shí)由于 CQ 兩端的完全解耦,Q 端我們可以設(shè)計(jì)多種存儲(chǔ),如數(shù)據(jù)庫(kù)和緩存(Redis 等);數(shù)據(jù)庫(kù)用于線下維護(hù)關(guān)系型數(shù)據(jù),緩存用戶實(shí)時(shí)查詢。數(shù)據(jù)庫(kù)和緩存的更新速度相互不受影響,因?yàn)槭遣⑿械?。?duì)同一個(gè)事件,可以 10 臺(tái)機(jī)器負(fù)責(zé)更新緩存,100 臺(tái)機(jī)器負(fù)責(zé)更新數(shù)據(jù)庫(kù)。即便數(shù)據(jù)庫(kù)的更新很慢,也不會(huì)影響緩存的更新進(jìn)度。這就是 CQRS 架構(gòu)的好處,CQ 的架構(gòu)完全不同,且我們隨時(shí)可以重建一種新的 Q 端存儲(chǔ)。不知道大家體會(huì)到了沒(méi)有?
關(guān)于緩存 key 的設(shè)計(jì),我覺得主要從查詢余票時(shí)傳遞的信息來(lái)考慮。12306 的關(guān)鍵查詢是:出發(fā)地、目的地、出發(fā)日期三個(gè)信息。我覺得有兩種 key 的設(shè)計(jì)思路:
總結(jié)
本文完全是憑自己對(duì) 12306 這個(gè)網(wǎng)站的核心業(yè)務(wù)的簡(jiǎn)單思考而得到的一些設(shè)計(jì)結(jié)果。如果真正的 DDD 領(lǐng)域建模,更多的是要和業(yè)務(wù)一線的工作人員、領(lǐng)域?qū)<疫M(jìn)行深入溝通,才能更深入的了解該領(lǐng)域內(nèi)的業(yè)務(wù)知識(shí),從而才能設(shè)計(jì)出更靠譜的領(lǐng)域模型和架構(gòu)設(shè)計(jì)。
非常慚愧,我沒(méi)有上 12306 買過(guò)火車票,家離的比較近,就算要買也是家人給我買:)所以,本文所分享的內(nèi)容難免是紙上談兵。但我覺得 12306 這個(gè)系統(tǒng)的業(yè)務(wù)確實(shí)比傳統(tǒng)的電商系統(tǒng)要復(fù)雜,且并發(fā)又這么高。所以,我覺得這個(gè)系統(tǒng)真的很值得大家重視模型的設(shè)計(jì),而不只是只關(guān)注技術(shù)層面的實(shí)現(xiàn)。
注:相關(guān)網(wǎng)站建設(shè)技巧閱讀請(qǐng)移步到建站教程頻道。
網(wǎng)站欄目:換個(gè)思路看12306,其核心模型設(shè)計(jì)思路到底復(fù)雜在
網(wǎng)站URL:http://m.rwnh.cn/news37/86737.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、建站公司、搜索引擎優(yōu)化、App設(shè)計(jì)、標(biāo)簽優(yōu)化、移動(dòng)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容