只是用支付寶和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也沒問題啊。

據說最開始開始12306是研究生導師帶著幾個學生做的，後來雖然最佳化還是不行。

直到後來阿里提供了技術支援，12306就再也沒崩潰過。

懂一點技術的人會覺得這個好厲害，這個好牛批。

懂的比較多的人會覺得，12306也就那樣嘛，其實和天貓淘寶差不多。

大牛會覺得，12306還能執行真tm不容易。

最後，完全不懂技術的人。這麼垃圾的系統，一看就是ZF拿錢不辦實事。畢竟國企的東西云云。

我覺得是有必要將程式設計納入九年義務教育體系了。

根本不是技術問題，我從制度層面分析下。淘寶等私有企業運營的網站是有收益的，基本可以認定網站的執行效率與財務收益成正比，所以他們有動力不斷地去最佳化。但12306並不是。政府沒有研發能力，肯定需要成立公司或者招標請其他公司來做，新成立的公司經驗不充分，肯定做不出非常成熟的產品。中標的公司因為資金池子大小已經決定了（這意味著你越仔細做，就越費錢，也就賺得越少），所以很多中標的專案都是剛剛夠用就行，而且網站後期的收益也與他們沒有任何關係。

以上都是檯面上的情況，還有檯面下的許許多多。所以只要是政府來做，12306就很難或者需要很長時間才能達到相對滿意的狀態。說到底是制度的問題，不僅是政治制度，也包括他各種制度。

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

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

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

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

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

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

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

簡單來說一下：

你在淘寶相中一件衣服，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的商品庫存和品類是不斷動態調整的，而淘寶天貓上的SKU是相對固定的。

對於支付Bora說，只要是固定品類，其實都容易處理，不過是資料庫裡面一行或幾行程式碼。唯一要處理的就是商品的庫存和價格。

但是對於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個億以下，我想都不敢想。

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

其實僅從表面上對比，支付寶雙十一當天處理了 1 億零 580 萬條交易請求量，而12306一天的出票量僅僅 166 萬條。單從這兩者相差605倍的資料來看，12306真的是弱爆了了，但這兩者背後是有很明顯的區別的。

首先，一套鐵路訂票系統不僅要有自己的票務邏輯，要實現分段處理，還要根據實際人流量對各站車牌進行合理化分配。而以天貓舉例，看似上億條處理量，但其可以在 Jsp 上快取商品資訊和數量，這相對於火車票每次操作都必須反饋到後臺查詢，而且其座位號和數量都要求做到100% 準確同步相比，淘寶天貓訂單數的可變範圍真的太廣了。

此外這兩者還存在很明顯的差距，則是12306的使用者的目的性極強，特別是在節假日和春運期間很容易出現高峰期，並且是處於全天候24高併發業務處理，面對著高達十億使用者再加上各種刷票軟體的壓力，12306所面對的壓力是支付寶說不能相比的。此外，支付寶作為一家網際網路公司，憑藉著深厚的技術積累可以實現系統更新，而12306涉及的部門和軟體極其廣泛，其出現卡頓奔潰，很多時候並不是因為超負載執行導致的，而是因為老系統相容問題。

這是我的一家之言，當年看到這個網站招標的訊息，最後中標的單位中標款，我曾經在感嘆為什麼這麼的好事情，為什麼不落到我的頭上呢？中國不是缺乏人才，而是你有能力好事也輪不到你。

12306的系統架構，對分流的處理，遠遠沒有支付寶那樣靈活。

支付寶是點對點的分堆處理，也就是兩點之間的支付，不會對其他人造成影響。所以可以根據不同的支付方和收款方，放在不同的伺服器上處理。就像去菜市場買東西，每個攤位的客人都可以獨立結算。每個攤位之間互不影響，所以可以並行處理。即使某一個攤位掛掉了，也不會對其他攤位產生影響。因此支付寶可以容納更多的流量。

而12306，是集中式的處理。任何一筆交易，都會影響其他使用者的交易。因為票務資料要在全國範圍內，實現資料的及時一致性。也就是說12306不是菜市場。而是專賣店客流量再大，你的支付櫃檯，就那麼多，所以大家要排隊。如果櫃檯掛掉了，那麼排隊的人都無法支付了。