南飛雁1999

只是用支付寶和12306比較，其實是不恰當的。12306的邏輯複雜程度遠遠高於支付寶，所以我們先換一個思維吧，用雙11的天貓和12306做比較吧。

2017年的雙11，天貓交易量達到了1682億元，並且也沒有出現問題。但是，12306沒到春運，就連接不通暢，是什麼原因呢？

這就需要從兩個系統賣的東西開始說起了。

我們都知道，天貓賣的是實體的商品，這些商品（SKU）都是有庫存量的，也就是下圖所示的這個內容。

用戶每買一個商品，這個庫存就相應的減少1，到減少到0的時候，庫存就沒了，後面的人也就買不到了。

這個是一個非常簡單的邏輯，其中的核心，就是SKU（最小庫存單元），對於天貓來說，SKU也就是一件商品。

天貓2016年的時候，統計自己擁有940萬商家，超10億件商品，數量是非常龐大的。但是每一件這樣的商品的庫存都是可以統計出來的，而且任何一個商品銷售的時候，並不會影響到其他的商品。

商品量大，我就多增加硬件來存儲這些商品就行了，所以技術上的難度並不是特別大。

但是12306不一樣，我去查了一下中國的鐵路運行情況。

根據2017年初的數據，中國列車車次一共有3500餘對，鐵路站點2000多個。

也就是說，每天，會有7000餘次的列車在中國的鐵路上行為，途經這2000多個點。

對於任何電商網站來說，SKU都是核心，那12306也算是電商網站，他的商品是什麼呢？就是火車票，火車票對應的是什麼呢？火車上的座位或者站位。

那SKU就是座位了。

對於天貓來說，商品賣一個少一個。

對12306來說，一列火車上的座位，賣一個他不一定少一個。因為我一列火車可能途經20個站點，一個人可能始發站上車，第三站下車，那這個SKU在1-3站之間被賣掉了，但是第4站的時候，它又回來了。我還可以繼續賣。

但是也可能一個人直接買了始發站到終點站，我這個SKU就完全賣掉了，回不來了。

用戶買的行為，決定著我SKU的剩餘情況，而用戶買的行為是一個不可控的行為。

如果在沒有控制策略的情況下，就意味著，SKU是隨時發生著變化的。

我們來簡單算一筆賬。

一列火車途經20個點，車上有5000個座位，那他理論最小庫存就是5000（一個座位1張票，始發—終點），最大庫存是95000（所有人都只坐1站）

但是對於用戶來說，他只是關心他那一站作為起點的時候，剩餘的票的數量，這樣的話，我們就必須計算，火車行進到他所在站的時候，車票的剩餘情況（包括未購買的和要下車的），這樣，每有一張火車票銷售出去，計算機就需要執行復雜的運算，來重新的定義SKU和庫存量。

中國有超過10億人在春運的時候會去12306搶票，7000餘次的列車，這個運算的複雜程度是非比尋常的。

可以說，現在中國的互聯網中，暫時還沒有能夠比12306還複雜的運算場景了。

我們假設，買一張票需要運算1秒鐘，有100臺服務器同時工作，也就是1秒可以買100張票。一天可以處理多少張票呢？8,640,000（864萬張票），我相信，春運開始的第一天，中國至少有1億人回去12306搶票吧，如果我們真的使用這種算法，那就意味著有9000多萬人，可能連搶票頁面張什麼都看不到。

但實際上是這樣麼？

並不是的，12306是設置了放票的節點，每個節點進行放票，也就是說，12306會按照以往的數據經驗，對車票進行預演算，在不同的線路之間按照一定比例，先將票的庫存計算出來。然後進行販賣。

在下一個節點的時候，會再次按照這個規則，對車票的餘量進行統計和計算，保證在每個節點時，各個站點的票都是有的，而且票與票之間的銷售不會相互干擾，這樣就可以減少在銷售期間的運算次數的減少，提高效率。

如此說來，在節點的間隔時間內，12306的下單複雜度和天貓是一樣的了，為什麼春運時候，它還是要會打不開頁面，沒有響應呢？

我們就可以看到12306和天貓另一個不同的地方了。

12306是實名制的，一人一票，但是天貓可以隨便買，所以，12306在下單前後有比較多的身份驗證，但是天貓並不需要，所以，12306的單個訂單的處理複雜度還是高於天貓的。

而且，全世界沒有任何一個系統，在一個時間節點的時候，會湧進來好幾億人。12306能安安全全的票賣出去，我覺得已經很強大了。

會技術的葛大爺

因為12306的商品庫存和品類是不斷動態調整的，而淘寶天貓上的SKU是相對固定的。

對於支付寶來說，只要是固定品類，其實都容易處理，不過是數據庫裡面一行或幾行代碼。唯一要處理的就是商品的庫存和價格。

但是對於12306來說不一樣啊。我們就以京九線、京廣線來說，每個乘車區間都能賣票，如果賣掉了天津到蚌埠的一張票，那麼北京到廣州的票、天津到廣州的票、北京到蚌埠的票都少了一張。那數據庫就接著算吧。

那麼如果同時出現10萬筆交易，數據庫的處理數量絕不是十萬這個量級，保守估算乘以二十（誠意每條線路的站點數量）也不過分吧？

如果加上退票、改簽、同一人跨區間買票、同一時段重複購票、防止黃牛炒票等問題……難度能跟淘寶上那種商品賣一件少一件的東西一樣麼？

系統壓力

根據來自官方的數據，12306網站PV(頁面瀏覽量)目前每天都超過400億次。

我們這些做企業管理系統的，如果使用的人多了，比如為一家大公司部署OA系統，按一個省公司1000人計算，全公司30萬人估算，已經需要考慮十幾臺負載均衡、分佈式緩存、數據庫優化、工作流優化等技術，因為要避免工作流的死循環或者寫入數據出錯，某個狀態位錯誤。

這種壓力下，我們的OA系統的PV也不會超過2000萬每天，跟12306每天400億次，還相差了99.95%。我反正是沒有勇氣去批評12306。

容錯程度

我們做企業管理系統，就算偶爾因為系統架構調整、數據庫升級、黑客入侵、版本更新乃至軟件錯誤導致某一個公文、某一筆報銷弄錯了，在當事人提出問題後，我們改回來也就算了。

在12306上，你好容易搶到一張春節回家鄉的票，然後過20分鐘有個工程師打電話給你說抱歉先生，因為我們數據庫故障，您購買的票無效，請您重新購票的時候，你會不會用盡所有力氣問候12306的服務人員、工程師、鐵總？肯定會啊。

所以12306的容錯程度是零。不允許犯錯。

防止刷票

現在有多少軟件是在雲端每隔6秒跑著輪詢？目前的測算是每秒查詢數據庫40萬次-50萬次；而對數據庫的每次查詢過程中，數據庫還必須給出實時數據，以便於我們買票。

這個難度，你就看小米每次在搶購的時候，一開始是實時顯示所有餘量，後來壓力實在扛不住，只有在最後1000臺的時候才顯示餘量。小米是認慫了。

我們早就認慫了，我一般都是專門提供一臺查詢服務器，提供非實時的數據，供查詢的數據每天更新兩次。

每秒50萬次查詢，還要返回真實數據，反正讓我做，我就認慫。

問我多少錢能做，我覺得20個億以下，我想都不敢想。

跟支付寶的難度差得太多了，不是一個數量級。

任易

因為確實不是一個量級的。

專業技術層面，前面有很多朋友已經講得比較透徹了。

但是一些不懂技術的同學，讀起來或許會有點費勁。

我來用通俗一點的方法解釋一下。

支付寶的運算，相當於加減法，數額有大有小，頻次極高，但是終究是加減法，計算機運算能力跟得上的話，不易出錯。

至於12306麼……

大家在高中時候，大概都學過概率論吧？對！就是那個一個盒子裡9個紅球8個白球，問連續五次摸到白球的概率是多少？要是給球加上標籤，算摸到特定球的概率會更難點。

12306就是結合了加減法與概率算法的運算級別。這個運算量可以說是幾何級提升的。

除了算法層面，還有服務器層面。

不是說，12306的服務器壓力一定就比支付寶的要大，而是不穩定。

在一些出行高峰期時候，人民都會做一件事：搶票。

大家沒事就不停的刷票，出票一瞬間十秒鐘之內，票就沒了（真實經歷，切膚之痛，就沒怎麼搶到過票）。除了乘客在搶票，還有黃牛，這兩年還有機器！各種五花八門的搶票軟件，對於漂泊在外的同學們應該不陌生吧？反正我春節回家，全靠這些軟件。

可以看看雙十一時候，各大電商通宵達旦，全副武裝的樣子。我的一些京東淘寶的朋友說，雙十一時候，大家吃住都是在公司，隨時準備戰鬥。

12306能做到這個份上，真的也是不容易了。

姑婆那些事兒

看到很多答案都在強調12306的購票系統是多麼複雜和高難度，似乎12306的網站建設讓人不滿意的關鍵是問題本身太複雜導致的。

其次，支付寶的網絡和系統也是會出問題，只不過得益於阿里巴巴的技術能力，解決問題的速度會比較快，給大家帶來的困擾會比較小。畢竟大家的要求不是完美，而是體驗不能太差罷了。阿里巴巴的技術難度不僅僅在支付寶這個系統，而在於淘寶等網站的海量數據處理，阿里巴巴不僅要保證支付環節不能崩潰或者出錯，在購物環節也不能崩潰，而且在雙十一等流量峰值時段，會有各種抵扣券，滿減活動導致系統負擔增加。短暫崩潰的情況也是時有出現的。

因此，首先要排除的一個情況就是，支付寶系統容易做，12306難度大，因此支付寶不崩潰，12306崩潰這個說法。雖然火車票訂票系統跟支付寶和淘寶的技術難度不一樣，但是，真正導致12306使用不順暢的原因還是在於兩個方面：錢和技術。

大家需要搞清楚的一點是，買不到票不能怪12306，因為網站不可能讓車票變多，買不到票是因為座位不夠。12306的職責是要正常運行，不崩潰。查詢，購票，退票等服務能夠儘可能高效。在早些年，12306的網站很容易崩潰，正是大家說12306系統不行的原因。淘寶網跟支付寶雖然也會有崩潰的情況發生，但是修復速度快，影響面小，給大家的印象就好很多。為什麼會這樣呢？因為阿里巴巴的網站技術，實力是世界級的，不是鐵路局可以比的。與此同時，阿里巴巴投入網站建設的資金也比鐵道部多很多。

鐵路系統雖然也很強大，但是訂票網站不是其核心競爭力，鐵道部不可能把太多的資源投入到網站建設。鐵道部的錢主要是用來建設鐵路系統的，網站只是附加的一個項目而已。阿里巴巴的網站是安身立命的根本，重視程度不可同日而語。阿里巴巴最大的技術挑戰就包括如何解決數據爆炸帶來的系統負擔，他們不斷砸錢去解決這個問題，才有能力應對今天這種規模的交易量。而鐵道部的網站建設，是在互聯網時代為了滿足市場需求做出的適應性行為。因此，阿里巴巴不管是在技術積累，人力投入還是資金投入方面，比起12306都有碾壓性的優勢。網站更好用一些也是理所應當的。

事實上，在12306訂票系統難用備受指責之後，鐵道部找了國內外的技術團隊幫忙建設，其中就包含了阿里巴巴的團隊。在重新梳理系統結構，完善網站建設之後，12306網站比以前已經有了很大的進步，整體的穩定性和可靠性還是可以接受的。由此也可以看出，當初的12306那麼難用，主要的原因不在於技術難度，而在於投入程度。

鎂客網

因為12306的商品庫存和品類是不斷動態調整的，而淘寶天貓上的SKU是相對固定的，但是對於12306來說不一樣啊。我們就以京九線、京廣線來說，每個乘車區間都能賣票，如果賣掉了天津到蚌埠的一張票，那麼北京到廣州的票、天津到廣州的票、北京到蚌埠的票都少了一張。如果加上退票、改簽、同一人跨區間買票、同一時段重複購票、防止黃牛炒票等問題

只要是固定品類，不過是數據庫裡面一行或幾行代碼。唯一要處理的就是商品的庫存和價格。 支付寶體系是非常分散的，而12306卻是集中的。不管你在網上買什麼商品還是在線下付款，實際上它們都是分散支付的，即便是雙十一這樣的大型活動時期它還是分散購買。簡單點說，無論你購買吃的還是穿的不可以所有的人一起購買一個品類的產品，他們選擇的範圍太廣，

所以12306的容錯程度是零。不允許犯錯。

12306是實名制的，一人一票，但是天貓可以隨便買，所以，12306在下單前後有比較多的身份驗證，但是天貓並不需要，所以，12306的單個訂單的處理複雜度還是高於天貓的。 而且，全世界沒有任何一個系統，在一個時間節點的時候，會湧進來好幾億人。12306能安安全全的票賣出去，我覺得已經很強大了。

所以，一個是面對千萬併發順暢運行的淘寶，一個是可能需要時時刻刻去面對億級併發保證數據一致性並不保證性能的12306，各有上下，因為業務不一樣，量級也不一樣。

牛科技

簡單來說一下：

你在淘寶相中一件衣服，S碼，比如庫存10000件，這10000件S碼的衣服是一摸一樣的，我作為消費者下了訂單買了這款S碼的衣服，數據庫裡對這件商品的庫存量減1，這就結束了。

你想在12306買一張票，比如說你想買K590這趟車的坐票，起始地北京西，終點站重慶，但是你只是想買北京西到邯鄲這部分段的票。這個能僅僅是對數據庫的一條操作就可以完成了嘛？

不是。

你需要查詢K590這趟車有沒有票，而且還需要查詢在北京西到邯鄲這個區間裡是不是有票，如果有票，那麼我讓你買了數據庫裡又該怎麼去操作，每一張票都是這樣的問題，每一行票都有自己獨立的一個票號，都有很多個區間，在數據庫層面，這就不是一張表可以實現的，在CRUD上，根本不可能想淘寶買衣服那樣對數據庫操作那麼簡單，所以他是多張表的關聯操作。

淘寶很多時候都做秒殺活動，很多人去買1件或者2件的商品，比如說雙十一一開始的時候，很多人去搶一些物品，這時候大量的請求蜂擁而至，你必須保證的是，這幾件商品是需要被人買走的，同時其他人沒有搶到商品，也就是搶購失敗。

也就是說，你必須實現的是，這個系統時時刻刻要和數據庫保持同步狀態，這樣才能保證數據的一致性。

而12306， 他是一個時時刻刻要出於秒殺狀態的同步系統，而且，業務層面也是及其複雜。

並且，淘寶這種電商平臺，都是維持一個28定則，百分之20的增刪改，百分之80的查詢。所以在數據庫層可以加各種中間件，比如說redis緩存啊，數據庫做主從複製，讀寫分離啊，等等來提高系統的性能。但是12306，他是出於一個高查詢高修改的系統，很難去實現一個數據庫層面的高可用。電商那一套應對高併發的思想在這裡完全不適應。

而且，12306第一個要保證的並不是性能，而是數據的一致性，就是無論這個系統有多慢，性能有多差，也不能出現兩個人同時買到一張票這樣的重大bug，所以在技術上，他只能去用一些非常成熟非常熟悉的技術，因為必須保證不能出bug，一旦在這樣的業務上出了bug，那代價和後果是及其嚴重的，一旦出現這樣的bug，影響的可是成千上萬人的出行。

而且，論併發，淘寶雙十一那一天的併發量可能是每年裡最高的，我認為他也並沒有12306在春運時期要高。而淘寶，在平時的併發量，也遠遠不如12306

所以，12306的系統，無論你說他的ui界面做的有多垃圾，性能有多慢，但是，後臺業務層，還是很厲害的！

至於所謂的阿里雲免費為12306提供技術支持，好像是阿里雲免費為12306提供了服務器和雲數據庫，最難的還是業務，像12306這樣複雜的業務，像12306這樣需要面對春運時期那樣的併發，整個世界，我覺得都沒有。

所以，一個是面對千萬併發順暢運行的淘寶，一個是可能需要時時刻刻去面對億級併發保證數據一致性並不保證性能的12306，各有上下，因為業務不一樣，量級也不一樣。

木劍溫不勝

做為一名資深的架構師想告訴你淘寶與12306有本質的區間。如果你能設計出他的方案給你100萬都值得，前提是你的方案是可行的。

1、世界上最大的同時在線網站：先不要說購票，他能支持上億人同時登錄這個方案都很值錢了。大部分網站可以採用鏡像方式在全國不同地點部署多套服務器提供服務，但你能忍受你在12306上查詢出車票，但無法定票的結果嗎？上億人在線需要消耗多少內存，多少帶寬？

2、世界上最高的併發操作：淘寶不同的商家分佈在不同的服務器上，甚至不同的商品可以可以分佈在不同的服務器上，所以淘寶在線用戶不少，但在每臺服務器上並不多。但12306呢？最算將一列火車放在一臺服務器上，有多少人要這一列火車的票？票不能多買，在無數用戶要購買同一張票狀態下，如果鎖定只讓一個用戶購買就很不容易。

3、多種類型的購買方式：淘寶就在淘寶上購買，但火車票呢？窗口、電話、團體、網站多在售出一列火車的，如何分配票都是一個很重要的問題。

4、分段購買方式：你在淘寶上見過分段購買東西的嗎？目前只有火車票是這樣做的，光你將如果分段做出來，你的工資過萬是沒有問題的。

總的來講，12306在全世界都屬於最等級的系統，你如果真有能力設計出來，你到任何一個IT公司都能做個技術總監的職位是沒有問題的。

至於那些說幾個學生做的，那說明他們不是做IT的。

lihhsd

華哥雜談

簡單來說一下：

你想在12306買一張票，比如說你想買K590這趟車的坐票，起始地北京西，終點站重慶，但是你只是想買北京西到邯鄲這部分段的票。這個能僅僅是對數據庫的一條操作就可以完成了嘛？

不是。

你需要查詢K590這趟車有沒有票，而且還需要查詢在北京西到邯鄲這個區間裡是不是有票，如果有票，那麼我讓你買了數據庫裡又該怎麼去操作，每一張票都是這樣的問題，每一行票都有自己獨立的一個票號，都有很多個區間，在數據庫層面，這就不是一張表可以實現的，在CRUD上，根本不可能想淘寶買衣服那樣對數據庫操作那麼簡單，所以他是多張表的關聯操作。

淘寶很多時候都做秒殺活動，很多人去買1件或者2件的商品，比如說雙十一一開始的時候，很多人去搶一些物品，這時候大量的請求蜂擁而至，你必須保證的是，這幾件商品是需要被人買走的，同時其他人沒有搶到商品，也就是搶購失敗。

也就是說，你必須實現的是，這個系統時時刻刻要和數據庫保持同步狀態，這樣才能保證數據的一致性。

而12306， 他是一個時時刻刻要出於秒殺狀態的同步系統，而且，業務層面也是及其複雜。

並且，淘寶這種電商平臺，都是維持一個28定則，百分之20的增刪改，百分之80的查詢。所以在數據庫層可以加各種中間件，比如說redis緩存啊，數據庫做主從複製，讀寫分離啊，等等來提高系統的性能。但是12306，他是出於一個高查詢高修改的系統，很難去實現一個數據庫層面的高可用。電商那一套應對高併發的思想在這裡完全不適應。

而且，12306第一個要保證的並不是性能，而是數據的一致性，就是無論這個系統有多慢，性能有多差，也不能出現兩個人同時買到一張票這樣的重大bug，所以在技術上，他只能去用一些非常成熟非常熟悉的技術，因為必須保證不能出bug，一旦在這樣的業務上出了bug，那代價和後果是及其嚴重的，一旦出現這樣的bug，影響的可是成千上萬人的出行。

而且，論併發，淘寶雙十一那一天的併發量可能是每年裡最高的，我認為他也並沒有12306在春運時期要高。而淘寶，在平時的併發量，也遠遠不如12306

所以，12306的系統，無論你說他的ui界面做的有多垃圾，性能有多慢，但是，後臺業務層，還是很厲害的！

至於所謂的阿里雲免費為12306提供技術支持，好像是阿里雲免費為12306提供了服務器和雲數據庫，最難的還是業務，像12306這樣複雜的業務，像12306這樣需要面對春運時期那樣的併發，整個世界，我覺得都沒有。

所以，一個是面對千萬併發順暢運行的淘寶，一個是可能需要時時刻刻去面對億級併發保證數據一致性並不保證性能的12306，各有上下，因為業務不一樣，量級也不一樣。

歐密切

另一方面，阿里的業務廣泛，服務器運算和存儲資源調度也很容易。一個小公司出1000萬很難，但是10個子公司的集團，每個公司出 100萬就可以集齊這麼多錢。阿里自己也是這樣做。像雙十一會需要很多服務器來支撐，雙十一一過基本上一大半的資源都用不上了，他這些資源就會被租用給阿里雲的用戶。等第二年雙十一他再從各個單位把一些可以收集起來的空閒西苑拿過來用以支撐淘寶和支付寶等業務。但是資源太龐大，每個被收集資源的地方也不太容易感覺出來。就像集團需要80塊，某子公司有80塊流動資金，集團就可以把其中的70抽走，而對這個子公司沒有什麼大影響。

再來說說12306，這個網站剛建起來的時候好像是自己的服務器，那時候資源也不是很足，另一方面網站也不是跟完善。有漏洞，以及資源在高峰時緊缺，所以會出現流量擁堵情況。這幾年好像12306也開始用阿里的雲資源了，總體來說現在比前幾年穩定了不少。像12306這種業務，用雲資源是比較好的。可以很靈活的調整資源佔用。像平時站點弄一點資源根本不會有什麼壓力，春節的時候就業務量大，需要大量的資源來處理網絡請求。

從網絡需求來講，像淘寶支付寶用阿里雲資源，他們的請求大部分都可以在一個區域內完成。而春節訂票的時候我們搶到一張票網站會提示你正在排隊。這個過程是什麼呢？像深圳和北京，兩個地方的人不可能買到同一區間和座位的票，因為我們搶到票之後排隊的這個時間實際上就是後臺服務器在跟全國範圍內其他12306數據中心做比對。而這個過程就會是很繁瑣的一個程序，工作量也是很大的。你要想，每個座位都要在全部的數據中心比對一次，當然，並不會傻到每次只比對一個座位。但是這個工作量也已經跟龐大。所以我們排隊的這個過程要等蠻久。同時，如果12306數據中心設置越多，這個比對過程花費時間就越長。但是數據中心越少，用戶訪問請求的壓力就回越大，所以這個數據中心在數量和位置上也是需要多加考慮權衡的。反正肯定不能做的像阿里那麼多。（關於12306數據中心的事可以在一些搶票軟件上看到，搶票前會比對每個數據中心的用時，並讓你選擇一個，實際上就是讓你選擇一個用戶壓力小，網絡情況好的數據中心，這樣有利於更快的搶到票）

但是總體來講，12306的資源相對於阿里的資源還是有差別的，就像一個小型集團跟跨國大型集團一樣，所以對於網絡請求變化應對能力還是有所差別。

關鍵字: 天貓 一千億 科技