對(duì)于未公開(kāi)的技術(shù)部分，只能結(jié)合已公開(kāi)的信息，去做大膽的猜想。

本文提到的一些解決方案，并不一定是標(biāo)準(zhǔn)的實(shí)現(xiàn)，一些觀(guān)點(diǎn)旨在引發(fā)大家的思考。

12306的成就

• 創(chuàng)下全球最大實(shí)時(shí)票務(wù)交易系統(tǒng)世界記錄，春運(yùn)一個(gè)月抵歐洲一年。
• 最高可達(dá)百萬(wàn)并發(fā)，承受了這個(gè)世界上能秒殺任何系統(tǒng)的QPS。
• 網(wǎng)站瀏覽量一天最高超1500億次，峰值是雙11的三倍。

12306系統(tǒng)特點(diǎn)

• 跟淘寶天貓等相比，業(yè)務(wù)簡(jiǎn)單（賣(mài)票）。
• 流量極大。
• 動(dòng)態(tài)庫(kù)存。

12306系統(tǒng)難點(diǎn)

目前 12306 最大的難點(diǎn)，在于庫(kù)存扣減。

它跟傳統(tǒng)的電商網(wǎng)站，可能最大的不同在于它的庫(kù)存， 它的庫(kù)存是動(dòng)態(tài)變化的，庫(kù)存之間會(huì)互相影響。

比如現(xiàn)在有一個(gè)組合品的需求，A品是由B品和C品通過(guò)不同的比例混合而成，用戶(hù)下單的時(shí)候傳過(guò)來(lái)的是A品這個(gè) SKU，但是庫(kù)存扣減的時(shí)候是把它的組合品的單品（B和C），都去扣一遍的。

我們平時(shí)各種商品 sku 庫(kù)存的話(huà)，它是表里面的一行行記錄。

圖片

某個(gè)行程是：杭州 -> 武漢 -> 成都。

杭州 -> 成都 ，武漢 -> 成都。這兩個(gè)是一個(gè)車(chē)次。那么每賣(mài)出一張 武漢 -> 成都 的票，杭州 -> 成都 的票也會(huì)少一張。

圖片

舉個(gè)極端的例子，火車(chē)上就一個(gè)座位，車(chē)次是從 A -> B -> C。

如果賣(mài)出 B -> C 的車(chē)票，不去扣減 A-> C 庫(kù)存的話(huà)，那么假設(shè)有兩個(gè)用戶(hù)分別買(mǎi)了  A-> C  和  B -> C 。那么當(dāng)車(chē)行至站點(diǎn)B的時(shí)候，車(chē)上會(huì)有兩個(gè)人，但是座位就一個(gè)。

所以不同車(chē)次之間的庫(kù)存是會(huì)互相影響的。

A -> B -> C -> D 共 4 個(gè)車(chē)站，假如乘客買(mǎi)了 B -> C 的車(chē)票，那么同時(shí)會(huì)影響到 A->C，A->D，B->C，B->D。

這里不會(huì)影響 A -> B 的行程，因?yàn)槌丝唾I(mǎi)的是 B -> C 的車(chē)票，站點(diǎn) B 才上車(chē)，不占用 A -> B 行程的座位，我下車(chē)你上車(chē)，不沖突。

計(jì)算耗費(fèi)性能

一些長(zhǎng)途，中間會(huì)經(jīng)過(guò)十幾個(gè)站點(diǎn)，而且有些城市是沒(méi)有直達(dá)的車(chē)次的，中間只能換乘。涉及了多個(gè)車(chē)站的排列組合，這里計(jì)算是比較耗費(fèi)性能的。

行鎖競(jìng)爭(zhēng)會(huì)非常激烈

圖片

購(gòu)買(mǎi)一個(gè)行程會(huì)涉及多個(gè)站點(diǎn)的扣減庫(kù)存，有可能這些多個(gè)站點(diǎn)的庫(kù)存扣減是放在一個(gè)事務(wù)中的，如果是在一個(gè)事務(wù)中，那么一次下單行為，可能要涉及到幾十次庫(kù)存扣減。

鎖范圍膨脹，事務(wù)就會(huì)被拉大，線(xiàn)程數(shù)可能迅速被占滿(mǎn)，導(dǎo)致數(shù)據(jù)庫(kù)可能成為性能瓶頸，并且接口性能也會(huì)有所下降。

圖片

熱點(diǎn)問(wèn)題

火車(chē)站不同的站之間都是一個(gè)具體庫(kù)存，中間的庫(kù)存扣了之后，那么遠(yuǎn)的這個(gè)站的庫(kù)存也要扣減。

極端情況下，一些熱門(mén)城市，中間一些站點(diǎn)可能比較火爆，那兩端的人是不是永遠(yuǎn)買(mǎi)不到票。

所以說(shuō)像 12306 這種庫(kù)存，其實(shí)涉及到非常多的一個(gè)行鎖競(jìng)爭(zhēng)，而且事務(wù)是非常大的。一列火車(chē)之間的庫(kù)存其實(shí)是互相影響的，動(dòng)態(tài)變化的。

另外還會(huì)涉及到其他維度，比如 硬座、硬臥、軟臥、無(wú)座 這種業(yè)務(wù)邏輯在里面。

業(yè)務(wù)邏輯加上庫(kù)存之間相互影響，就導(dǎo)致庫(kù)存扣減邏輯異常復(fù)雜。

解決思路

產(chǎn)品角度

• 早期的 12306 是通過(guò)整點(diǎn)去搶票，整點(diǎn)就會(huì)產(chǎn)生非常高的流量峰值，對(duì)系統(tǒng)造成非常大的壓力，后面采取了分時(shí)段售票，比如今天開(kāi)搶 15 天之后的車(chē)票，將搶票的壓力按照時(shí)間區(qū)間分散開(kāi)，大大減低了峰值。
• 候補(bǔ)車(chē)票。

在2019年5月份，12306 新增了“候補(bǔ)購(gòu)票”功能，在“候補(bǔ)購(gòu)票”功能沒(méi)出來(lái)之前，放票時(shí)間一到，千萬(wàn)人同時(shí)刷新?lián)屍?，這便是春運(yùn)火車(chē)票秒光的原因。

候補(bǔ)車(chē)票堪稱(chēng)搶了一票第三方軟件的“飯碗”。

“黃?！钡拿孛芪淦魇峭鈷?，用最快的服務(wù)器不斷地刷新和監(jiān)控12306，刷票速度往往是正常購(gòu)票的幾十倍。

實(shí)際上，市面上通行的“搶票軟件”，原理與“黃?！辈o(wú)本質(zhì)區(qū)別。

以前，合肥到上海的車(chē)票賣(mài)光了，有人退票或改簽，車(chē)票會(huì)回到票池可供購(gòu)買(mǎi)。搶票軟件實(shí)時(shí)刷新監(jiān)控，第一時(shí)間購(gòu)買(mǎi)，這便是搶票軟件比人快的原因。

現(xiàn)在，有了候補(bǔ)車(chē)票，合肥到上海的車(chē)票賣(mài)光了，乘客可以候補(bǔ)登記，有人退票或改簽，車(chē)票按順序優(yōu)先賣(mài)給候補(bǔ)登記的人，而不是回到票池公開(kāi)出售。這便是搶票軟件無(wú)效的原因。

現(xiàn)在很多搶票軟件反而沒(méi)有“候補(bǔ)購(gòu)票”功能搶票來(lái)得快。

候補(bǔ)車(chē)票在整個(gè)系統(tǒng)上相當(dāng)于是一個(gè)異步過(guò)程。先排隊(duì)，后面搶沒(méi)搶到票再通知你。只要異步了，就可以通過(guò)消息，或者定時(shí)任務(wù)慢慢去消費(fèi)，大大降低系統(tǒng)的壓力。

圖片

12306 是有非常多的灰色流量的，像是一些搶票軟件或者腳本。因?yàn)檫@里面涉及到的利益非常巨大，滋生了很多灰色流量，給12306本身帶來(lái)了很多額外的壓力。

“候補(bǔ)購(gòu)票”功能可以降低黃牛刷票行為，攔截部分灰色流量。

• 驗(yàn)證碼機(jī)制。BT的驗(yàn)證碼機(jī)制，可以過(guò)濾非常大的灰色流量。

12306 的驗(yàn)證碼，是所有驗(yàn)證碼中的一股絕對(duì)的“清流”。

2013 年起，鐵道部為了應(yīng)對(duì)黃牛搶票，以及各類(lèi)搶票軟件和插件，升級(jí)了購(gòu)票驗(yàn)證碼系統(tǒng)。

在12306官方網(wǎng)站上，從購(gòu)票到付款，都需要輸入驗(yàn)證碼。從最開(kāi)始的字母數(shù)字驗(yàn)證碼，再到后來(lái)升級(jí)后的圖形驗(yàn)證碼，成為了一道“難過(guò)”的關(guān)卡。

圖片

各類(lèi)奇葩驗(yàn)證碼出現(xiàn)在了 12306 上。

到了2015年底，根據(jù)有關(guān)網(wǎng)站統(tǒng)計(jì)，12306上的圖形驗(yàn)證碼多達(dá)接近600種。再經(jīng)過(guò)排列組合，總共有多達(dá)300000種。一次性輸入準(zhǔn)確的比例僅僅是8%，兩次輸入準(zhǔn)確比例27%，三次以上輸入準(zhǔn)確的比例才勉強(qiáng)超過(guò)60%，如果一次性輸入成功的平均用時(shí)為5秒的話(huà)，按照熱門(mén)車(chē)票“秒光”的情況計(jì)算，每輸錯(cuò)一次驗(yàn)證碼，就意味著當(dāng)次購(gòu)票成功率下降80%左右。

直到 2018 年，各類(lèi)奇葩驗(yàn)證碼才陸續(xù)開(kāi)始“下崗”。

上面的候補(bǔ)搶票和驗(yàn)證碼機(jī)制，主要是為了對(duì)抗黃牛。

道高一尺，魔高一丈。黃牛也在不斷進(jìn)步。

比如我是一個(gè)搞黑灰產(chǎn)的人，我可以雇傭一批大學(xué)生，去做圖形驗(yàn)證碼識(shí)別。簡(jiǎn)單驗(yàn)證碼還是機(jī)器去執(zhí)行。

那這樣的話(huà)其實(shí)還是沒(méi)辦法防止，但是這樣增加了灰產(chǎn)的成本，畢竟人工比機(jī)器成本高，從一定程度上還是能夠降低灰產(chǎn)的流量占比。

12306 之所以能夠使用如此變態(tài)的驗(yàn)證碼機(jī)制的大前提是：沒(méi)有把用戶(hù)體驗(yàn)放在首位。

圖片

12306 比較特殊，市面上幾乎不存在競(jìng)爭(zhēng)對(duì)手，而且火車(chē)票對(duì)于逢年過(guò)節(jié)，旅行返鄉(xiāng)的人來(lái)說(shuō)，幾乎可以等同于必需品。

在這種情況下，12306 不必將用戶(hù)體驗(yàn)放在首位，對(duì)于 12306 來(lái)說(shuō)是可以犧牲部分用戶(hù)體驗(yàn)來(lái)?yè)Q取系統(tǒng)穩(wěn)定性。

• 12306 是讀多寫(xiě)少的情況，查詢(xún)流量占大頭。

天量的火車(chē)票查詢(xún)是影響 12306 性能的重要原因之一，大概占了90%以上的訪(fǎng)問(wèn)流量。更棘手的是：峰谷的查詢(xún)有天壤之別，平時(shí)工作日跟這種節(jié)假日，春運(yùn)。流量相差是巨大的，時(shí)間區(qū)間是非常明顯的。

如果說(shuō)完全用機(jī)器去堆，可能就會(huì)造成一個(gè)資源浪費(fèi)。

還有至關(guān)重要一點(diǎn)是，假如完全用機(jī)器去堆，在實(shí)際業(yè)務(wù)峰值超出了初始評(píng)估量時(shí)，服務(wù)將面臨無(wú)法完全承載而癱瘓，因?yàn)榇笠?guī)模服務(wù)器的采購(gòu)、交付、部署到應(yīng)用上線(xiàn)所耗費(fèi)時(shí)間以月計(jì)，根本無(wú)法在業(yè)務(wù)量激增時(shí)"即插即用"。

幾乎沒(méi)有辦法在成本和并發(fā)能力之間做一個(gè)好的平衡。以往的一個(gè)做法是從幾個(gè)關(guān)鍵入口流量控制，保障系統(tǒng)可用性，但是會(huì)影響用戶(hù)體驗(yàn)。

淘寶/天貓大促的時(shí)候，也會(huì)增加服務(wù)器，但阿里的業(yè)務(wù)盤(pán)子大，這些新增的機(jī)器很快會(huì)被其他業(yè)務(wù)(包括阿里云)消化掉，可能還不夠。但是對(duì)于 12306來(lái)說(shuō)，就比較難做到這一點(diǎn)。

在 2015 年的時(shí)候，12306 跟阿里云達(dá)成合作，通過(guò)云的彈性和“按量付費(fèi)”的計(jì)量方式，來(lái)支持巨量的查詢(xún)業(yè)務(wù)，把架構(gòu)中比較“重”(高消耗、低周轉(zhuǎn))的部分放在云上，將75%的余票查詢(xún)業(yè)務(wù)切換到了阿里云上。

將余票查詢(xún)模塊和12306現(xiàn)有系統(tǒng)做分離，在云上獨(dú)立部署一套余票查詢(xún)系統(tǒng)。

通過(guò)動(dòng)態(tài)的云計(jì)算，在高峰時(shí)段動(dòng)態(tài)去擴(kuò)容，可以達(dá)到分鐘級(jí)的擴(kuò)容，這樣就避免在平時(shí)浪費(fèi)大量的機(jī)器。

合作后，提高了網(wǎng)站的負(fù)載能力。2019年的春運(yùn)，12306挺過(guò)了流量的高峰 297 億次的日訪(fǎng)問(wèn)量。

技術(shù)角度

歷史背景：12306 是在 2010 年左右上線(xiàn)的，11年到12年之間，基本上一到節(jié)假日系統(tǒng)就崩潰。當(dāng)時(shí)也是被噴的不行。12年之后在 7、8月份進(jìn)行了大規(guī)模的重構(gòu)，到了13年的春節(jié)，整個(gè)系統(tǒng)就比較穩(wěn)定了，基本沒(méi)有 down 機(jī)的情況發(fā)生。

面對(duì) 12306 這種讀多寫(xiě)少的場(chǎng)景，可能我們平時(shí)會(huì)采用 Redis 這種緩存機(jī)制，12306 具體選擇的解決方案，可能跟我們常見(jiàn)的解決方案有一些不一樣。

12306 通過(guò)充分調(diào)研，并沒(méi)有選擇 Redis，而是選擇了名叫 Pivotal GemFire 的產(chǎn)品。

沒(méi)聽(tīng)過(guò) Pivotal ，學(xué) Java 的肯定都聽(tīng)過(guò) Spring。

Spring 框架它歸屬于 Spring 團(tuán)隊(duì)。沒(méi)錯(cuò)框架名和團(tuán)隊(duì)名是一樣的，這個(gè)團(tuán)隊(duì)歸屬于 Pivotal 公司。

很多銀行、投行，實(shí)時(shí)交易方面的系統(tǒng)都采用 Pivotal GemFire 作為解決方案。

GemFire 基于開(kāi)源項(xiàng)目 Geode 進(jìn)行研發(fā)的。Redis 是在 2010 年左右才發(fā)行的第一個(gè)版本，Geode 是更早的一個(gè)開(kāi)源項(xiàng)目。

GemFire 本身是 Geode 的商用版本，可以理解為收費(fèi)的 Redis（Redis的作者現(xiàn)在就在 GemFire 打工）。就像 Oracle 和 MySQL。

為什么選擇 Pivotal GemFire 而不是 Redis？

https://redis.io/comparisons/redis-vs-gemfire/

Redis 是開(kāi)源的緩存解決方案，而 GemFire 是商用的，我們?cè)诨ヂ?lián)網(wǎng)項(xiàng)目中為什么使用 Redis 比較多呢，很大原因就是因?yàn)?Redis 是開(kāi)源的，不要錢(qián)。

開(kāi)源對(duì)應(yīng)的也就是穩(wěn)定性不是那么的強(qiáng)，并且開(kāi)源社區(qū)也不會(huì)給你提供解決方案，畢竟你是白嫖的。

而在銀行以及 12306 這些系統(tǒng)中，它們對(duì)可靠性要求非常的高，因此會(huì)選擇商用的 GemFire，不僅性能強(qiáng)、高可用，而且 GemFire 還會(huì)提供一系列的解決方案。

12306 本身不缺錢(qián)，在資金預(yù)算充足的情況下，追求系統(tǒng)的穩(wěn)定性和交易的絕對(duì)可靠，追求的是最好的解決方案。

而 GemFire 類(lèi)似 Oracle 是一套完整的解決方案，不只是給你一套工具，讓你私有化部署就不管了，而是需要后面持續(xù)去維護(hù)的。

據(jù)說(shuō) GemFire 同時(shí)做到了分布式系統(tǒng)里的CAP，違背了架構(gòu)的一個(gè)常識(shí)。

圖片

當(dāng)時(shí) 12306 也嘗試了許多其他的解決方案，都扛不住查詢(xún)的流量，而使用 GemFire 之后扛住了流量，因此就使用了 GemFire。

Redis 主要用作緩存存儲(chǔ)，而當(dāng)時(shí) （12年左右） 12306 最大的瓶頸主要是在 IO 上面。

為什么 12306 最大的瓶頸會(huì)在 IO 上面呢？這跟 12306 使用讀擴(kuò)散有關(guān)。

讀擴(kuò)散和寫(xiě)擴(kuò)散常見(jiàn)于 訂閱/聊天/群聊 系統(tǒng)。

讀擴(kuò)散，一般指犧牲了讀的性能，去提升寫(xiě)的性能。

寫(xiě)擴(kuò)散，一般指犧牲了寫(xiě)的性能，去提升讀的性能。

對(duì)應(yīng) 12306 來(lái)說(shuō)：

• 讀擴(kuò)散：扣減只需要關(guān)注列車(chē)站點(diǎn)之間的扣減，關(guān)注車(chē)次，查詢(xún)的時(shí)候再去動(dòng)態(tài)計(jì)算。

優(yōu)點(diǎn)：扣減簡(jiǎn)單；缺點(diǎn)：計(jì)算余票復(fù)雜。

• 寫(xiě)擴(kuò)散：扣減直接把各個(gè)站點(diǎn)之間票都扣減，關(guān)注站點(diǎn)。

優(yōu)點(diǎn)：扣減復(fù)雜；缺點(diǎn)：查詢(xún)余票簡(jiǎn)單。

個(gè)人猜測(cè) 12306 使用讀擴(kuò)散的原因是對(duì)數(shù)據(jù)實(shí)時(shí)性有要求，當(dāng)擴(kuò)散隊(duì)列很長(zhǎng)的時(shí)候，寫(xiě)入時(shí)間存在延時(shí)，可能導(dǎo)致不同行程的余票對(duì)不齊。

而且涉及排列組合過(guò)多，使用寫(xiě)擴(kuò)散，數(shù)據(jù)冗余會(huì)比較嚴(yán)重，浪費(fèi)存儲(chǔ)成本。

計(jì)算余票是一個(gè)數(shù)據(jù)密集型的運(yùn)算，要關(guān)聯(lián)很多的數(shù)據(jù)進(jìn)行計(jì)算。一方面需要數(shù)據(jù)，一方面又要頻繁的計(jì)算。計(jì)算跟數(shù)據(jù)本身是分開(kāi)的（計(jì)算在CPU，數(shù)據(jù)存儲(chǔ)在內(nèi)存）。

GemFire 的定位是實(shí)時(shí)存儲(chǔ)網(wǎng)格。

一般分布式緩存，比如Redis，查詢(xún)數(shù)據(jù)就算再快，還是要從緩存里取出數(shù)據(jù)，再CPU進(jìn)行計(jì)算。

GemFire  最大的特點(diǎn)是將存儲(chǔ)和計(jì)算放在了一起，它的存儲(chǔ)和實(shí)時(shí)計(jì)算的性能目前還沒(méi)有其他中間件可以取代。

圖片

扣減庫(kù)存數(shù)據(jù)庫(kù)選用的是 Sybase（收費(fèi)，關(guān)系型數(shù)據(jù)庫(kù)），相比查詢(xún)的流量，扣減庫(kù)存的流量是完全可以承載的。

db-engines.com 這個(gè)網(wǎng)站可以對(duì)比主流數(shù)據(jù)庫(kù)之間的差異

扣減庫(kù)存之后再同步至 GemFire，然后在 GemFire 里進(jìn)行動(dòng)態(tài)計(jì)算，整個(gè) GemFire 承載的是查詢(xún)的流量。引入 GemFire 之后，整個(gè)系統(tǒng)的查詢(xún)擴(kuò)散瓶頸基本上就解決了。

GemFire 將很多機(jī)器內(nèi)存匯總成一個(gè)大的節(jié)點(diǎn)，作為整體去管理，盡量保證業(yè)務(wù)運(yùn)算和業(yè)務(wù)數(shù)據(jù)是在同一個(gè)節(jié)點(diǎn)，盡量避免多節(jié)點(diǎn)的網(wǎng)絡(luò)通信。

圖片

但是 GemFire 也存在不足的地方，對(duì)于擴(kuò)容的支持不太友好。在 12306 中，也有過(guò)測(cè)試，需要幾十個(gè)T的內(nèi)存就可以將業(yè)務(wù)數(shù)據(jù)全部放到內(nèi)存中來(lái)，因此直接將內(nèi)存給加夠，也就不需要很頻繁的擴(kuò)容。

余票庫(kù)存的表如何設(shè)計(jì)？

這里的設(shè)計(jì)思路都是猜測(cè)的，并不一定是 12306 真實(shí)的設(shè)計(jì)方案。

12306 余票庫(kù)存的表的設(shè)計(jì)是非常特色并且重要的

首先說(shuō)一下需要哪幾個(gè)表來(lái)表示余票的庫(kù)存信息：

1、基礎(chǔ)的車(chē)次表：表示車(chē)次的編號(hào)以及發(fā)車(chē)時(shí)間等具體的車(chē)次信息，屬于比較穩(wěn)定的數(shù)據(jù)。

2、車(chē)的座位表：表示每個(gè)座位的具體信息，包括在幾車(chē)廂、幾行、幾列，以及 該座位的售賣(mài)情況。

3、車(chē)的余票表：通過(guò)座位表可以計(jì)算出每個(gè)車(chē)位在各個(gè)車(chē)站區(qū)間還有多少余票，但是動(dòng)態(tài)計(jì)算比較浪費(fèi)性能，因此再添加余票表，通過(guò)定時(shí)計(jì)算余票信息放入到余票表中，提高查詢(xún)的性能。

（其實(shí)還應(yīng)該有站點(diǎn)表和車(chē)廂表，不過(guò)不太重要，這里直接就省略了）

這里說(shuō)一下這 3 個(gè)表的對(duì)應(yīng)關(guān)系：

比如車(chē)次為 K123，該車(chē)上有很多的座位，每個(gè)座位對(duì)應(yīng)座位表中的一條數(shù)據(jù)。

而余票表指的是 K123 車(chē)次上，硬座、硬臥、軟臥、無(wú)座各有多少?gòu)堄嗥?，余票表的信息可以由座位表?lái)計(jì)算得到。

接下來(lái)說(shuō)一下如何通過(guò)座位表來(lái)表示用戶(hù)購(gòu)買(mǎi)的車(chē)票：

12306 中的車(chē)票信息其實(shí)是比較復(fù)雜的，因?yàn)楦鱾€(gè)車(chē)站之間是有依賴(lài)關(guān)系的，比如 4 個(gè)車(chē)站 A->B->C->D

如果乘客購(gòu)買(mǎi) B->C 的車(chē)票的話(huà)，不僅 B->C 的庫(kù)存要減一，B->D 的庫(kù)存也要減一，這是排列組合的情況，可以考慮通過(guò)二進(jìn)制去簡(jiǎn)化車(chē)票的表示。

在座位表中，我們?cè)O(shè)置一個(gè)字段 sell varchar(50) 表示該座位的售賣(mài)情況，如果該車(chē)次有 4 個(gè)站 A->B->C->D，那么 sell 字段的長(zhǎng)度就為 3，sell 字段的第一位表示該座位 A->B 的票是否已經(jīng)被買(mǎi)了，第二位表示 B->C 的票是否已經(jīng)被買(mǎi)了...

如果乘客購(gòu)買(mǎi) B->C 的車(chē)票，則 sell 字段的值為：010。

如果乘客購(gòu)買(mǎi) B->D 的車(chē)票，此時(shí)發(fā)現(xiàn)該座位在 B->C 已經(jīng)被賣(mài)出去了，因此不能將該座位出售給這位乘客。

如果乘客購(gòu)買(mǎi) C->D 的車(chē)票，則 sell 字段的值為：011 ，表示 B->C，C->D 都已經(jīng)有人了。

通過(guò)座位表來(lái)計(jì)算出余票，得到余票表。

通過(guò)余票表提升查詢(xún)性能

這里余票表就相當(dāng)于是數(shù)據(jù)庫(kù)中的視圖。

如果要去查詢(xún)一個(gè)車(chē)次中某一個(gè)類(lèi)型的余票還有多少，還需要去對(duì)座位表進(jìn)行計(jì)算，這個(gè)消耗是比較大的 ，因此通過(guò)余票表來(lái)加快對(duì)于余票的查詢(xún)。

可以定時(shí)去計(jì)算座位表中的數(shù)據(jù)，將每種類(lèi)型的座位的余票給統(tǒng)計(jì)出來(lái)，比如：

硬臥：xx張

硬座：xx張

軟臥：xx張

...

再將余票表的信息給放入到緩存中，大大提高查詢(xún)的性能。

我們?cè)谑褂?12306 的時(shí)候，也會(huì)發(fā)現(xiàn)，有時(shí)候顯示的有票，但是真正去買(mǎi)的時(shí)候發(fā)現(xiàn)已經(jīng)沒(méi)有余票了，這就說(shuō)明 12306 沒(méi)有保證實(shí)時(shí)的一致性，只要保證了最終一致性即可，也就是用戶(hù)真正去買(mǎi)的時(shí)候，保證對(duì)于余票數(shù)量的查詢(xún)是準(zhǔn)確的就可以了。

個(gè)人推測(cè) 12306 使用的是緩存+動(dòng)態(tài)計(jì)算結(jié)合的方式，查詢(xún)的時(shí)候使用的是緩存（最終一致性），等到真正下單的時(shí)候會(huì)再去動(dòng)態(tài)計(jì)算一遍（實(shí)時(shí)一致性）。這樣利用緩存就能隔絕掉很大的查詢(xún)的流量，并且也能保證最終下單的準(zhǔn)確性。

對(duì)于電商，如果商品銷(xiāo)售小份額的超出庫(kù)存，部分場(chǎng)景下可以通過(guò)補(bǔ)充庫(kù)存進(jìn)行彌補(bǔ)，僅要求弱一致性。而 12306 屬于實(shí)時(shí)的交易型系統(tǒng)，庫(kù)存資源的數(shù)量固定，對(duì)分布式事務(wù)要求強(qiáng)一致性。

中間的站點(diǎn)如果太過(guò)火爆，導(dǎo)致兩邊的站點(diǎn)買(mǎi)不到票怎么辦？

比如 A->B->C->D，對(duì)于一個(gè)車(chē)次中的座位來(lái)說(shuō)，如果 B->C 的乘客非常多，那么是不是就會(huì)導(dǎo)致 A->D 買(mǎi)不到票了？

這個(gè)是通過(guò)運(yùn)營(yíng)部來(lái)進(jìn)行設(shè)計(jì)，首先考慮的肯定是要盈利，遠(yuǎn)途票價(jià)比較貴，因此比較傾向于遠(yuǎn)途的旅客，營(yíng)業(yè)部根據(jù)具體的實(shí)際情況以及盈利情況來(lái)定一下各個(gè)區(qū)間預(yù)留多少票，給每個(gè)車(chē)站區(qū)間都留有一些余票，那么就不會(huì)因?yàn)槟骋粋€(gè)區(qū)間非常火爆，而導(dǎo)致其他乘客買(mǎi)不到長(zhǎng)途的票了。