cuiyi's blog（崔毅 crazycy）

12306首秀被罵的狗血噴頭后，鐵道部找來IBM、阿里巴巴等大企業要解決方案，給出的條件是資金管夠但是問題得解決。幾大企業最后都拒絕了。12306開始自己嘗試解決問題。他們發現市面上可以買到的成套解決方案都不足以應付春運購票負載，所以只能自己改進已有的數據庫（注：其實是改用VMware SQLFire/GemFire，這里我之前理解錯誤）。以前12306用的是小型機，發現性能嚴重不足，遂改用x86系統+linux平臺（原平臺為HP Superdome小型機，UNIX系統，Sybase ASE數據庫）。最后他們的核心系統用了十幾個節點（現在應該是17節點）的多路Xeon E7（具體幾路待考），每個節點配1TB內存，數據庫全部在內存中運行。2013年春運，12306系統峰值負載11萬tps，與2012年淘寶雙11活動峰值負載相當，新的系統基本經受住了考驗。

補充：以上內容是我在2013年7月得知的信息，彼時沒有任何公開來源提到過12306新系統的技術細節。甚至，當時局外人沒人知道12306已經在2012年開始做了技術改造。直到數日之前，鐵總首次向媒體公開了技術改造的詳情：分布式集群內存數據技術引領12306技術革命。這篇文章給出的細節，與我之前看到的內容完全一致。由此我可以確信信息來源是此次技術升級的核心人士。

另外，關于第三方合作對方給出的信息是IBM、Oracle、Sybase全部不能滿足要求，主要是這些廠商的方案部署以后，要升級時不能做到不停機靈活擴展。也就是說，IBM沒有做到是他們技術不足“搞不定”。阿里巴巴參與了改造，負責了排隊系統。此外，雖然后端經受住了壓力，前端卻如大家所看到的那樣還是頻頻卡死。到底卡死的原因是前端水平太低還是訪問壓力太大，暫時沒有可靠的信息供判斷。

淘寶的問題是其系統架構是分散度較高的，各個訂單之間關聯度不大；而12306每出一張票都要對全線路做數據更新（因為一條線路存在多個站點），因此系統負載相較淘寶來說集中很多，直接搬淘寶的方案也無法解決問題。淘寶的應用類型決定了阿里巴巴可以通過部署大量的服務器來分散壓力，但12306就不行。其實他們的核心系統的硬件成本不過數百萬，不是他們不想采購更多服務器，而是買更多的服務器也沒什么用途。最后，在經過軟件層面的優化之后，12306的瓶頸其實是核心節點的CPU、內存性能。但是這個性能的提升不是朝夕的事情，而是受限于摩爾定律，基本上每兩年才能翻一倍多些。（這段話是我自己的分析，不過現在12306的后端數據庫系統應付現有需求已經夠用了）

補充：關于座位實時復用，我看到的信息明確表明12306出票時，每出一張區間票都要實時調整該線路其他受影響區間段的余票數量，且這是很大的壓力來源；另外，對方表示所使用的GemFire數據庫與簡單的memcache/redis數據緩沖不同，有著本質區別。

==========================

然后我說點對鐵路系統購票困難現象的看法：

一種商品只要出現供不應求現象，那么結果只有兩種：大家排隊購買；出現黑市，變相提高商品的流通價格并抑制需求。

12306這個事情，就是標準的限價商品供不應求之后出現排隊與黑市現象的例子。因為供不應求，所以有了黃牛、搶票軟件與秒殺。如果供應充足，一個車次直到發車前都有一兩張余票，那么黃牛、搶票就毫無存在價值，旅客也用不著守在電腦前和其他人比拼手速和網速以及電腦性能網絡性能了。

現在供應不足的前提下，12306就算把系統做的性能再高，也只是會加快熱門車次票務秒殺的速度而已——而這更會刺激搶票軟件，大家為了在更短的時間里成功搶到隊列名額就會不斷提升自己的搶票性能。打個比方說就是一個店門前排隊，消費者為了增加買到商品的概率去雇人代排，每個消費者都雇了好多人，造成店門口的通道擁擠不堪。為了減緩擁堵，商家不斷拓寬通道，但每次一拓寬消費者們就會增加雇傭的排隊勞力把新增的通道空間占滿，形成惡性循環。這樣下去，只要還存在供不應求的現象，這種循環就不會有終止的時候。也就是說，12306的問題主要不是出在網站本身。

那么怎樣解決供應不足的問題？這么多年來鐵路不斷升級運力修建新線，已經建成全球最龐大的鐵路運輸系統，可是到了春運還是只能勉強應付。從這個角度來說鐵路部門在供應不足的問題上也不該承擔太大責任，他們已經做得很不錯了。

那么問題的根源就出在不斷增加的需求上了。為什么我國鐵路系統需要承擔如此龐大的客運流量需求？很顯然，是因為全國范圍的人口流動。大量務工上學人員過節要返鄉，節后回駐地，這個剛性需求是合理的。可是為什么他們必須要到外地去打工上學？為什么數以億計的人員要遠離家鄉去謀生求學？

最后我們會發現，區域發展不平衡才是罪魁禍首。正因為多少人在家鄉無法得到足夠的機會與資源，他們必須到發達地區奮斗和實現自己的價值。只要這種不平衡現象還在繼續，每年春節前后就不可避免地出現大批人員全國范圍流動的情況，就不可避免地出現運輸能力不足的尷尬。改進12306也好，增加鐵路網投資也好，最終都只是治標不治本。如果這個社會不去直面根本問題，那么這些表象的癥結永無解開的時候。

說起來，有幾個人愿意背井離鄉呢？

=============================================

然后這個問題爭了幾天，我實在忍不住要吐槽一下了：

12306這個事情，網上有多少網友從一開始就獻計獻策了，也有不少網友提供了很不錯的建議。但不得不說，很多網友在提建議時完全就是一種居高臨下、自以為是的態度，上來就先認定需求簡單可以輕松應付，隨便有點經驗的工程師就能搞定，12306出問題全怪體制太爛，國企效率低下，一幫人光拿錢不做事，技術水平太低……

淘寶2013年雙11活動，峰值流量是一秒鐘完成1.3萬筆訂單。12306在2014年1月6日全天網絡出票400萬張。看起來雙11流量完爆12306是吧？等等！別忘了12306這400萬張票可不是全天悠悠閑閑平均地賣出去的，而是分成10個時段集中被搶走的。每個時段開始放票后數分鐘之內大部分票就已經被搶光了。以每個時段40萬票，峰值持續三分鐘估算，高峰期一分鐘出票在10萬張以上毫不夸張。誠然，一分鐘10萬訂單還比不上淘寶2013雙11，但別忘了一年以前阿里巴巴也只是達到了一分鐘15萬訂單的水平而已（并且在高峰期一樣卡爆）。而且一分鐘10萬出票還滿足不了需求的，以旅客購票的熱情來看，達到一分鐘50萬票都不一定能讓所有旅客滿意。

淘寶在2012年雙11時已經是業界頂尖水平了，其軟硬件技術皆為自主研發，既便如此面對一分鐘十幾萬的訂單量都會卡死。請問，覺得12306“需求簡單，問題可以輕松解決”的，是不是水平已經高到了阿里巴巴都要請你們去領導整個技術團隊的級別呢？是不是你們的方案可以輕松應付每分鐘數十萬筆訂單，達到全球一流水平了？

淘寶面臨的需求是業界從未有過的，所以淘寶的路很艱難。12306面臨的需求是其他人遇到過的么？全世界哪個國家、哪種客運票務系統敢說自己的負載達到12306三分之一的水平？面對空前龐大的壓力，諸位“技術高手”只是憑著自己一點程序員的經驗，在電腦前一個人思考上一會兒就給出個“簡單、實用、省錢、輕松應付”的解決方案——你們知不知道“自大”這兩個字怎么寫啊？

作為局外人，本來就難以了解鐵路售票系統內部的業務邏輯。想出建議可以，那么是不是先收集些信息，了解下背景？是不是先拉出一份需求清單來，把客戶的想法搞明白搞清楚了，然后再考慮技術實現？能不能不要上來就想著技術上怎么方便怎么做，把客戶需求隨意地簡化？好多人提的方案在票務供應不足的情況下直接就超售了，難道你要讓旅客前一分鐘還為訂到票高興，下一分鐘對著“您的票被取消”的提示破口大罵么？或者訂票延遲確認——知不知道旅客看到選擇的車次沒能買到票后會做什么？馬上去看其他車次有沒有票啊！你延遲確認幾分鐘，然后對排隊的賬戶做抽簽，多少旅客會覺得自己被耽誤了啊！旅客的要求就是速度越快越好，最好是下訂單后一秒鐘出結果才安心哩。這還僅僅是簡單想一下就能知道的問題，局外人不了解或不能輕易想到的問題又有多少？諸位高談闊論時，有沒有虛心地去找找內部人士了解或者搜索類似的票務系統的研究論文？真覺得自己的頭腦聰明絕頂，連背景調查都不做就可以輕松把握所有細節？還有，你們想出來的方案做沒做過實驗啊？考慮沒考慮過硬件適配性啊？你們了解現在市面上能買到的硬件系統，什么樣級別的能滿足可靠性、性能和可擴展性、可維護性的需求么？你們在多路服務器平臺上驗證過你們的分布式數據庫構想么？哦原來你們什么都沒做過，怕是連多節點集群互聯該用什么連接方式都不知道，你們拍下腦瓜，一句“那些問題都好解決”就完事兒了？就算你們自己沒做過，找找類似的案例會累死么？研究下別人做過的經驗就不夠高貴冷艷么？就貶低自己技術水平了么？連類似的案例研究都沒有，隨口就是別人做得到我做得到，真覺得自己寫過幾行代碼就多么偉大了么？

還有一些人，看說IBM沒做就一口認定是12306故意排擠IBM，認定IBM解決這問題肯定沒壓力。好嘛，IBM什么時候做過如此規模的票務系統了？你細節什么都不知就預設結論了？為啥淘寶當年沒選擇IBM作為方案提供商而是自主研發？IBM的大數據業務主要集中在金融領域，這不代表它在其他領域就樣樣精通好不好？它能拿出的方案無非是Power7小型機平臺，Power7在數據庫性能上又比Xeon E7強多點？然后Power7系統賣多少錢了解么？后續維護難度多大了解么？把適合銀行金融行業的平臺放到12306來真的合適么？說起來，不就是因為“12306”和“IBM”這倆名字放一起，諸位內心里首先就給前者打了負分對后者仰視么？要是把“12306”換成“nasdaq”，那結論就又是一回事兒了——哦正好nasdaq沒用IBM方案，可見nasdaq是排擠IBM內部人賺黑心錢是吧？不過2013年工商銀行系統升級故障，應該是和方案提供商IBM無關的，肯定是國企的體制問題無誤！

評價一個事物，首先不是了解背景、研究問題產生的原因，首先是看被評價者處于什么立場，打著什么標簽。如果是“敵對陣營”那就毫不猶豫地踩上一腳再說話，接下來就算研究也只研究“它的錯誤在哪兒”，不考慮“它也有對的可能性”。在12306這個問題上就是：12306是國企，是鐵總下屬機構，所以它出了問題一定是自身原因。票務系統做不好一定是鐵路方面不懂技術，把該用來請大企業做方案的錢自己貪掉了，一定不可能是大企業都沒信心解決這問題。旅客普遍使用搶票軟件也是12306的責任，不是供應不足的原因……

最后呢？12306還是做到了全球最強的客運票務系統。一貫被認為是因循守舊的國企，在選擇技術方案時放棄沿用多年的小型機/UNIX平臺去擁抱業界還是新鮮事物的基于x86/linux的大規模分布內存數據庫系統，承受住了堪比2012年淘寶雙11的壓力。在這個領域，12306可以自豪地說自己是做的最好的案例。它還在卡，還是偶爾崩潰，頁面還是難看，可是這些遲早會改進。這個過程中也還是會有冷嘲熱諷，還是會有所謂的大牛指點江山，但最終解決春運高峰期一天數百萬張秒殺售票的，還是12306自己。

所以，走自己的路，讓別人去說吧。

看到有同學轉發了知乎上的討論12306的碼農沒有你想的那么弱，爭論的非常激烈，各種觀點都有，老牌技術專家馮大輝fengg，也在自己的微信上發表了文章——別給12306洗地了。反駁了這些帖子，個人覺得很有見地。以下是摘錄的原文：

看到各種給 12306 跪舔的洗地貼讓我有些看不過去了。雖然已經說過不再為這垃圾話題寫東西，再次破例說一下，盡管覺得挺惡心的。

在這篇文章開寫之前，我先說一下我的幾個觀點，如果你你不認同這幾點，就沒必要浪費時間繼續往下看了。

1.公眾服務，做得好是應該的，做不好活該挨罵，花了人民的錢不把事情做好，罵你，一點都不冤枉。只有你做到超出用戶期望才有資格受到贊揚。

2.人多，票少，肯定會有人買不到票，這是客觀前提，這的的確確是 12306 解決不了的問題。作為鐵路 12306 系統的用戶，我(或是大多數人)的期待只是購票服務要可靠、穩定還要好用，還有，不要亂浪費錢。

3.有一種很愚蠢的評論叫「你行你上」「你牛你去做」「就你牛? 裝什么大尾巴狼」，為什么說這種評論愚蠢? 因為你讓批評者去做也沒問題，可你到時候能給發工資么? 給顧問費么? 你做得了主么?

4.為什么要質疑? 要批評? 吃飽了沒事兒干么? 當然不是，簡單的說，這是我們每個人權利的一種。你不行使你的權利是你的自由，有人質疑，是質疑者的自由。無論是質疑還是批評，都是想讓這個系統變得更好。 

5.讓一些借機揩油的商業公司滾一邊去，我建議最好警惕這些商業公司，包括 IBM 這樣的公司，還有一些所謂的體制內專家，也要警惕他們，為什么? 沒有利害關系這些人能站出來么? 另外，如果你發現我跟 12306 有利害關系，讓我也滾一邊去。

6.12306 內部業務對我們還是黑盒子，既然是黑盒子，那就沒辦法也沒必要討論細節，否則的話，你絞盡腦汁累折褲衩帶兒之后給出再詳盡的方案，最后還是會被說你的方案不行，不能用。

7.12306 只有更加開放，充分引入技術服務商的競爭，才有可能做得更好。

這些算是前提。

我們首先說說知乎上那個洗地貼。我之所以說這個貼是洗地貼，并不是說那個排名最高的回答者就是洗地黨，而是這個貼著實起到了洗地作用。

排名最高的那個回答開頭說「12306首秀被罵的狗血噴頭后鐵道部找來IBM、阿里巴巴等大企業要解決方案，給出的條件是資金管夠但是問題得解決。幾大企業最后都拒絕了…」 這篇回答最開始的版本不是這么寫的，最初的帖子開頭是一句「聽我的同學說」或是類似的一句話，我記不清了，但知乎應該有記錄。簡而言之，開始的版本就是路邊社一類的消息。去掉了這句話，不少傻瓜還以為真是這么回事了。

我們先想一下：12306 有可能給出「資金管夠」這種條件么? 不可能的事情。之前花費的巨額資金已經被罵出了翔，誰有膽子敢喊出來「資金管夠」? 請問哪位敢負責? 不是意淫是什么? 另外，12306 的態度是很明確的，早在 2012 年九月就有媒體報道 12036 對外的態度「我們12306網站是非營利性質的，不會和商業企業合作，而且我們對自己的技術有信心。」

再說說「幾大企業拒絕了」，這個又是胡扯。客觀上說一句，IBM 這種公司根本就搞不定 12306，因為 IBM 連蘇寧易購都做的不怎么樣，能搞定 12306 么? 我覺得難度很大。對于 IBM 這種公司來說，只要有錢賺，不可能會拒絕。有人說你這是臆斷，請問有誰聽說過 IBM 會主動拒絕用戶大單的么?

再說說阿里巴巴，前面已經說了，12306 不可能跟你們這些公司搞商業合作。我了解的情況是，不搞商業合作，但是可以搞搞其他方面的「合作」，比如，技術支持。阿里巴巴的確派出了一只專家團隊進場了，這是事實。阿里技術團隊幫助他們解決了一些關鍵問題，也肯定提供了一些寶貴的思路和經驗。但同時，我認識的一位參與者也承認，業務的確復雜，牽扯到很多東西，短時間內不好解決。

寫到這里，我想諸位基本上就看明白了。知乎上那個回答基本就是在那里瞎掰。

再說說知乎回答里面提到的「分布式集群內存數據技術引領12306技術革命」這個事兒。其實最近 12306 的底氣有一大部分是來自這篇公關稿。找到這篇稿件看一下，會發現這就是某商業公司在宣傳他們的產品。而且，分布式內存數據技術產品并不只是這一家。如果換用其他同類型產品也能起到同樣效果，我不知道是否有人同意這一點?

這篇稿件的亮點在什么地方呢? 亮點在于「技術改造之后，在只采用 10 幾臺 x86 服務器實現了以前數十臺小型機的余票計算和查詢能力」，看到沒? 這恰恰說明以前的解決方案蠢到家，并不能證明現在的方案屌到爆。12306 也不應該因為做到了及格就出來厚著臉皮邀功請賞。

同時這個事實也打了很多專家的臉，因為當時有不少所謂的專家站出來說「你看電信系統每年都是投入多少錢，12306 投入這么一點怎么能夠呢?」蠢貨，蠢話。

知乎那個帖子下面又寫了一大堆東西，包括提到「全球最強的客運票務系統…12306可以自豪地說自己是做的最好的案例」，說實話，我看不出浪費那么多錢之后做出來這個樣子有什么可以「自豪」的，換了別人恐怕找地縫鉆進去也差不多。

客觀的事實是 12306 的確有進步。這當然值得肯定。這個進步是多少時間多少代價換來的? 別有點進步之后就說「全球最強」好不好? 真的好意思么? 洗地洗到這個份兒上也的確賣力。

對于帖子中一大堆技術性的描述，我建議直接忽略好了。為什么? 前面提到，對于一個黑盒子，你描述太多也無法精準，最后別人稍微揭開一點蓋頭，就會說「你看，你錯了吧?」

作為對這個帖子的陳述，我最后再說一個客觀事實：12306 這個項目開始就已經是外包的了。只是外包給所謂「有資質」的單位而已。網上公開新聞寫著呢「中國鐵路客戶服務中心、也是火車票唯一網購網站12306的設計招投標，申報方案僅有中國鐵道科學研究院電子計算技術研究所和易程科技股份有限公司兩家。最終，在業界眼里實力雄厚的易程科技未能中選。作為鐵道部下屬機構，招標變得更像走形式，鐵科院的中標猶如從左手到右手…」 我只是引用媒體內容啊，請勿跨省。

回到開頭，我說這個帖子客觀上起到洗地的作用。不知道諸位是否認同?

再說第二篇洗地文章。這篇文章來自「西西河」社區。作者號稱是「前淘寶工程師，后來在一家電商公司做技術副總」，洋洋灑灑寫了一大堆。此人在西西河上從2011 年注冊至今只發了一貼，并且當初是他提出做開源訂票系統的人，我了解的是，當初牽頭做 12306 開源系統的人是京東副總裁李大學先生。請問這位作者能公開一下自己的身份么?

此篇文章的一個重點是說：你看百度淘寶每年也投入那么多錢，每家都幾千個工程師，百度一年的研發費用 10 億什么的，還有攜程之類的公司技術還比不上 12306 呢。我估計很多人一想，「好像也對啊，百度淘寶每年花那么多錢，12306 花雖說花了不少，可也做到了，12306 挺了不起啊」。這種說法混淆了一個事實：百度淘寶都不是單一服務應用，而是由多個應用服務組成，比如淘寶，簡單的不那么科學的劃分一下起碼要有：Web 系統(你訪問淘寶看到的那一堆東西)、搜索系統(你要搜索產品)、交易系統(下訂單購買的過程)、后臺支撐系統(物流風控安全)…如果要比較的話，那也是比較整個中國鐵路的 IT 系統成本才行，或者應該只比較交易系統成本才好吧?

除此之外，除去外包成本之外，我們也不知道 12306 的人力成本和維護成本到底是怎樣的，因為什么都不透明，甚至我們也不知道采購商業公司「分布式集群內存數據技術系統」到底又花了多少錢。

別跟我們偷換概念。

另外，我有個建議: 既然說到了百度的研發投入能公開查到，那不妨不涉及機密的情況下呼吁 12306 也把研發費用具體是怎么花掉的公開一下好了。這樣，群眾也放心一些。當然，這實際上是不可能的。別著急，淘寶目前還不是上市公司，等到上市了，淘寶乃至阿里的研發成本大家自然也會知曉。

洗地貼一般到了中后部分，又會加上一堆技術細節或是偽技術細節的討論，這些內容也最唬人，看不懂的一下子就被鎮住了，我也在想要不要我也加上一堆，不過這個文章已經夠長了… 我前面說過，對于一個「黑盒子」，無論你怎么去反駁，最后還會陷入困境。這跟江湖把戲「紅藍鉛筆三張牌」差不多，會被稍微知道黑盒子里面構造的人說你「Too Simple . Sometimes Naive」，我的一位好友就是這么中招的，很早他就說幾十臺服務器如果設計好的話，應該就夠了，這是他那篇文章的核心觀點。結果被無數馬后炮指出各種細節缺陷，問題是，能沒缺陷嗎? 不少做技術的人，腦子真是秀逗了。

對于本文中提到的兩篇文章的原作者，我不知道你們是出于什么目的寫這兩篇文章，或許你自己并不是洗地黨，我也無意冒犯你們。我很好奇你們的自豪感來自哪里，另外，這兩篇文章客觀造成了洗地效果，讓人非常遺憾。

最后，我想說的是，能看到我這篇文章的人，應該大部分都是這個國家的年輕人吧，別因為一張車票而搞得心煩意亂，更長遠的解決之道是：努力工作，努力賺錢，爭取以后買機票回家。盡管這句話聽起來挺無厘頭的。

1月11日起，12306網站開始銷售除夕當日火車票。每到此時，鐵路系統唯一的官方購票網站12306就會成為眾矢之的。今年也不例外，12306再次被淹沒在一片埋怨聲中。

    1月5日，觀察者網刊登了問答網站“知乎”上的用戶王強的解答，回答“如果把12306外包給IBM或者阿里巴巴來做的話，能不能比現在做得好？”這一問題。

1月10日，一位ID名為“代碼狗”的前淘寶工程師，后來在一家電商公司做技術副總的IT業內人士也在著名論壇“西西河”上發文，表達了他自己對12306系統的看法。

值得注意的是，“代碼狗”在12306系統剛上線時也有過不少微詞為了證明12306系統很容易搭建，“代碼狗”甚至曾經發起過一個名為“替12306設計系統”的開源項目。通過工作中的實踐，“代碼狗”對于12306系統也有了新的認識。

觀察者網轉載此文，供讀者參考。

全文如下：

官方訂票網站12306崩潰時的頁面（資料圖）

本人淘寶技術專家，2012年在一家百強民企做電商副總，當時在極為艱苦的條件下帶隊開發了一個B2C（企業針對個人開展的電子商務活動——觀察者網注）網站，走支付寶和銀聯支付通道，年營業額千萬級（作者注：當然實在太少了，我只是說這個網站投入了實際的運營）。

也就在那個時候，我對12306嗤之以鼻，覺得他們做得太爛了，認為自己能帶隊花幾百萬半年時間做個好的出來。于是我狂妄地想做一個開源的訂票系統給他們。我花了一個星期時間思考建立數據模型，思考到庫存這一步的時候，我才發現，12306的庫存復雜性比淘寶、京東高很多倍，運算量也大很多倍。傳統的分布式數據庫、緩存、負載均衡技術并不能恰好滿足12306的需求。

在平時，12306也就是個正常的電商網站。但一到黃金周，12306就是一個全站所有商品都秒殺，所有SKU都是動態庫存的變態。

即使不考慮線下既有的電話、代售點等渠道，要實現一個12306，最少最少也是千萬級別的硬件投入（作者注：這是當時的估算，沒有精算，可能與實際相差較大，總之，我說得不一定對，12306的業務也許沒我說的那么復雜，但也絕不是某些人噴的那么簡單），軟件和人力另算。那些叫囂只要40臺服務器、只要2個架構師4個程序員、大談分庫分表和前端CDN的人們，只是紙上談兵罷了。所謂初生牛犢不怕虎，做了三年CMS和BBS，就以這個經驗來噴12306，未免太天真了。

媒體人噴12306，是他們不懂技術，沒有能力和耐心來分析背后的難度。技術人員噴，則是因為大部分的技術人員在短時間思考時，容易陷入過于樂觀的誤區，經典的例子就是估算工作量，程序員們往往容易估算出一個超短的工期，把寫程序的工作樂觀地想象成了打字員照稿敲鍵盤的工作。

知乎那篇文章，我覺得不是洗地。排名第一和第二的答案都說得很客觀。淘寶技術是比12306強大很多倍，淘寶現在的系統也是花了10倍于12306的錢、時間和人才做起來的。根本原因還是鐵路運力不能滿足春運需求，淘寶也解決不了這個問題。

12306這一年來進步非常大。從前段動畫驗證碼、分時段搶票，到后端去小型機、虛擬化、內存數據庫的運用。可以說，12306是中國政府機關做的最強大的網站（電商系統），能在短短一兩年內做出這樣的改變，幾乎是個奇跡，就連一些市場化的民企都望塵莫及，甚至一些上市公司都比不上它！（比如51job和ctrip）。

事非經過不知難，在網上批判12306的人，大部分還是形成了【國企=壟斷+腐敗+低效】的思維定勢。小部分是真的輕視了它的難度。

至于12306一期工程3個億（含硬件）貴不貴我不評價，我只提供一個數字供參考，百度一年的研發費用（不含硬件）是10億，這個數字來自百度財報。網上能查到。3億看起來好大一個數字，真用到超大型的電商系統、搜索引擎系統里面，其實也不算什么天文數字了。
（黑一下： 百度研發的產品單一嗎?
                          除了搜索, 知道,貼吧,文庫,云... 等等不要研發嗎?
                          單就一個搜索不比12306復雜?
                          百度投在搜索一期的研發費用能趕上12306?
           所以拿一個12306系統跟整個百度有可比性么？）

再解釋一下，為什么秒殺壓力大，以及為什么12306的動態庫存很復雜。

先說秒殺。

2013年12月25日前后，天貓搞了一個圣誕季積分兌換活動，持續幾天。25號上午10點12分，放出了15000個天貓魔盒（淘寶集市有人賣，大概190-230塊），從成交記錄上看，是19秒內全部搶完。

實際上，我也參加秒殺了，那天的題目特別簡單（請輸入xxx漢字的拼音首字母），我應該是5秒內答題完成并提交訂單，結果告訴我排隊的人太多，擠不進去，并提示14秒以后重試。人太多就是因為題目太簡單了，門檻越低，5秒內擠進去的人也越多嘛，如果題目換成【2克濃度為3%的U235在大亞灣核電站能發多少KW的電】，5分鐘之內也不會有1萬5千人跟我競爭。

我想，14秒以后哪還有我的事情呀，于是重新答題秒殺，結果出現了服務器錯誤的頁面。反復刷新幾次，就告訴秒殺結束了。

在群里問了一下同事，有不到10個人回答我，都說沒秒到（也可能秒到的人悶聲發大財，不回復我）。

淘寶是什么技術水平呢，淘寶有至少4000技術人員，至少4萬臺服務器（這都是兩年前的公開數據了，按規定可以談論），2013年11月11日成交額351億，2012年全年成交額超過1萬億。

淘寶擁有各種自主研發團隊：服務器、交換機（網上可以搜索到淘寶公開的綠色服務器開放標準）；操作系統（LinuxKerneltaobao版，yunos手機操作系統是阿里云的，暫時不計入）、Web服務器（Tengine）、Java語言虛擬機（JVMtaobao版）、數據庫（MySQL內核taobao版，google和facebook也有自己的版本，HBase淘寶版、還有自己全部從頭開發的OceanBase）、負載均衡器（LVS，LVS始創人就在淘寶，擔任研究員）、Java運行容器（Jboss，其創始人之一，王文彬，也在淘寶，擔任副總裁）。

淘寶還有數不清的開源項目和中間件，如高性能Java通信中間件HSF、分布式數據庫中間件TDDL、異步消息系統notify等等等等。

以淘寶這樣的技術水平，也不能做到秒殺時讓每個用戶都沒有擁擠感，為什么呢？

一是要尊重物理原理，一臺服務器一秒鐘能承受的計算量是有極限的，任你怎么優化，采用多高效的算法和編程語言，都突破不了某個極限，比方說汽車發動機驅動的F1賽車至今也不能突破400公里的時速（超音速推進號那個1千多公里的時速不能算，那是飛機引擎驅動的）。再往深了說，就不容易懂了。感興趣的可以從著名的C10K問題開始看起。

二是要考慮經濟效益，十一黃金周的時候，北京主城區到八達嶺長城的路堵得嚴嚴實實，但不能因為黃金周的高峰，就把這段路修成長安街那樣10車道的高速公路。否則的話，花費天文數字（真的是天文數字，12306那3個億大概只夠修1-3公里）。修了一段路，黃金周是可以飆到80公里/小時了，可平時呢，拿來給兩邊的居民曬谷子？

淘寶目前的硬件和帶寬數量，已經超出日常運營的需求了，就是留了相當大的余量給大促銷（眾所周知的是雙十一，雙十二，其實基本每個季度都有大促銷，每個月都有促銷，甚至天天都在促銷——聚劃算）。amazon當年就是為了應對黑色星期五的大促銷購置了大量的服務器，平時訂單量沒那么大了，amazon就把富余的服務器拿來搞云計算了。順便說一下，阿里云是當今中國第一世界數一數二的云計算服務商，和amazon走的路也有點像。

再說動態庫存。

翻頁繼續看

淘寶秒殺天貓魔盒的時候，只有一個商品（行話叫做SKU），它的庫存是15000個。有一個人秒殺到了，庫存就減1，19秒賣完的，一秒要成功產生789個訂單（下訂單的請求可能是8萬個，只是可能啊，非實際數字，也可能是1萬個，用于說明一下壯觀程度）。想象一下，你在廣場上賣火車票，一秒鐘有8萬人舉著錢對你喊：賣給我！

上過大學的人都知道，比秒小的時間單位還有毫秒、皮秒、飛秒。但交易系統登記一個交易可不像原子繞著原子核跑一圈那么簡單，它要做這些事：檢查是否惡意訪問、取到系統時間、取到顧客默認收貨地址、核對顧客秒殺資格（當時的規定是天貓T2.T3達人）、生成訂單號、把顧客ID系統時間訂單號收貨地址寫入訂單系統、扣除顧客天貓積分、商品庫存減一、給顧客打標記（每人只能秒一個，下次不能秒了）等等，這每一件事都要花費毫秒級別的時間，這些操作加起來的時間可能是接近1秒級別的，但由于淘寶的服務器比較強悍，而且采用了分布式和集群技術，結果比1秒理想一點。但即使有1萬臺服務器，也不能把這個時間稀釋成萬分之一秒，因為，商品只有一種，它有15000個庫存，對應的數據庫記錄只有一行，所有的交易請求都要到這里來處理。

能不能把這15000個拆分成5000個商品并分配到5000臺服務器上呢？那樣不就可以5000臺服務器同時處理了嗎？答案是不能，首先，5000個商品，意味著有5000個商品詳情頁，5000個購買按鈕，這對前期的營銷、引流是個災難。基本上就沒法做引流入口了，顯然這違背了商業管理原則，人為增加了信息混亂程度。其次，天貓魔盒秒殺也不是啥大事，即使按官方標價399元來計算，也就6百萬的交易。如果6百萬的交易要花費那么大的配套成本，那就太不劃算了。再次，淘寶有十幾億商品，這十幾億商品的展示交易和管理，本來就是分布到上萬臺服務器上去了。沒有必要再把每個商品按庫存拆成多個商品了。

這789人搶到了，還不一定會付款（99積分換天貓魔盒還好一點，不需要去網銀，成本也極低，大部分是會付款的，3999秒殺iPhone5S就不一定，有人可能網銀有問題，有人可能改變主意不想要了），所以就又帶來訂單取消重新恢復庫存的問題。還有想要的消費者們，會認為還有機會，繼續在前臺刷一會兒，最終這個秒殺會被熱情的消費者們猛刷30秒到1分鐘。

一分鐘過去了，服務器終于可以喘口氣了吧？等等，還有超賣，原來，某兩臺服務器在同一毫秒都拿到了鎖，都去減了庫存，15000個庫存，被下了15500個訂單，又得取消一部分訂單。。。如果采用單線程獨占鎖，是可以做到同時只有一個服務器線程減庫存的，但那樣就對并發高峰的能力就差了好多了。8萬人舉著錢，可能只有8個人能下單成功，這個擁擠狂熱的搶購就要持續10分鐘以上。平時秒個天貓魔盒，10分鐘也就10分鐘吧，雙十一就慘了，收銀臺一下子減少了90%，還想做到350億，要么做夢，要么再加10倍服務器和帶寬。所以，商業是不完美的，要在絕對正確和絕對的快速之間做個取舍，保證相對快速又極為正確，允許一定的庫存錯誤和超賣（具體允許多少我也不知道）。

好了，講了這半天淘寶，可以說12306了吧？

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

實際上，G71有136*3=408種商品（408個SKU），怎么算來的？請看：

如果賣北京西始發的，有16種賣法（因為后面有16個站），北京西到：保定、石家莊、鄭州、武漢、長沙、廣州、虎門、深圳。。。。都是一個獨立的商品，

同理，石家莊上車的，有15種下車的可能，以此類推，單以上下車的站來計算，有136種票：16+15+14....+2+1=136。每種票都有3種座位，一共是408個商品。

好了，再看出票時怎么減庫存，由于商務、一等、二等三種座位數是獨立的，庫存操作也是一樣的，下文我就不再提座位的差別的，只討論出發與到達站。另外，下文說的是理論世界的模型，不是說12306的數據庫就是這么設計的。

旅客A買了一張北京西（01號站）到保定東（02號站）的，那【北京西到保定東】這個商品的庫存就要減一，同時，北京西到石家莊、鄭州、武漢、長沙、廣州、虎門、深圳等15個站臺的商品庫存也要減一，也就是說，出一張北京到保定東的票，實際上要減16個商品的庫存！

這還不是最復雜的，如果旅客B買了一張北京西（01號站）到深圳北（17號站）的票，除了【北京西到深圳北】這個商品的庫存要減一，北京西到保定東、石家莊、鄭州、武漢、長沙、廣州、虎門等15個站臺的商品庫存也要減1，保定東到石家莊、鄭州、武漢、長沙、廣州、虎門、深圳北等15個站臺的商品庫存要減1。。。總計要減庫存的商品數是16+15+14+……+1=120個。

當然，也不是每一張票都的庫存都完全這樣實時計算，可以根據往年的運營情況，在黃金周這樣的高峰時段，預先對票做一些分配，比如北京到武漢的長途多一點，保定到石家莊的短途少一點。我沒有證據證實鐵道部這樣做了，但我相信，在還沒有12306網站的時候，鐵道部就有這種人工預分配的策略了。
（問： 賣票的規則確實如此？）
（網友理解：
如：福州 開往 福鼎  （福州->連江->寧德->霞浦->福鼎）

分站編號: 福州->連江 1->2
分站編號: 福州->寧德 1->3
分站編號: 福州->霞浦 1->4
分站編號: 福州->福鼎 1->5
分站編號: 連江->寧德 2->3
分站編號: 連江->霞浦 2->4
分站編號: 連江->福鼎 2->5
分站編號: 寧德->霞浦 3->4
分站編號: 寧德->福鼎 3->5
分站編號: 霞浦->福鼎 4->5

分站總數: 10
如：購買 福州->霞浦 1->4
根據下標過濾，將定義好的序列載入緩存操作，將日志推送數據庫。
）

（作者果然只是個工程師，
12306如果只存在妙殺問題，也就不會讓人異議了，就像沒人異議淘寶的秒殺一樣。
12306真正的問題是處理請求慢，響應慢，無論怎么狡辯都是技術問題。

技術問題分析：
全國一共有幾條主干火車線，也就20條左右，最多50條，我這是按照20年前的地理課本估算的，因為從我記事起中國就沒新增什么鐵路，很多路都是建國前修的，非常非常悲哀的事。
一條干線一天也就500次列車，一次列車也就2000來個坐位。一次列車的數據都弄到內存里，也沒多少，2000個數據在內存里處理起來也不復雜。一天全線數據也就20*500*2000=20,000,000這個2000萬數據在這個云計算時代怎么也算不上大數據吧。

再說壓力問題：
就算全國有12億*30%=3.6億人回家。就算他們要在5天內回家，每天為0.6億，平均分配到20個干線，每干線為0.03億人，分配到500次列車，每次列車為0.00006億人，也就是6000人。也就是最多只有6000人要坐同一車次。三個人搶一個坐位。這個數量的競爭也算高并發嗎，可笑之至。

就算12306處理不了，這些所謂的高難問題，那么已暴露的那些低級可笑的幼稚問題，還少嗎？
這也算是技強悍嗎。
）
(
樓主的思路有問題，這樣算當然會瘋掉，需要變個思路！ 
假設一列車從 A站駛往Z站 ，列車可同時容納2000名乘客 
　　途徑站點示意圖如下：（用專業的話說，一個長度26的數組） 
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 

　　有乘客甲購買了從 C --》 R 站的車票，則在本列車對應站點的數組位置 +1，這里注意R站下車，R站不加1 
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 
　　0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 

　　乘客乙購買了從 H--》V 的車票 ，同樣在本列車對應站點的數組位置再 +1 
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 
　　0 0 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 1 1 1 0 0 0 0 0 

　　乘客丙購買了從 U--》Y 的車票 ，同樣在U,V,W,X上站點的數組位置 +1 
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 
　　0 0 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 1 1 2 1 1 1 0 0 

　　那么當乘客丁要購買從 A --》 P 站的票時，系統只要計算，從A站 --> P站位置上乘客，是否每個站點的乘客總數都小于2000即可。 
       小于2000，就說明有票可出售，車上有空位，至于另一些同學提出的位置問題，完全用另一張的表記錄票與座位的關系即可。
)
(票是區段方式出的，算法必須靠近區段，層主算法思路基本是靠譜的)

想象一下，8萬人舉著錢對你高喊：賣給我。你好不容易在錢堆里找到一只手，拿了他的錢，轉身找120個同事，告訴他們減庫存，而這120個同事也和你一樣被8萬人圍著；也和你一樣，每賣出一個商品要找幾十個人減庫存……這就是12306動態庫存的變態之處。比你平時買東西的任何網站的庫存機制都復雜幾十上百倍。

再說一下搶票插件，機器永遠比人快，當你好不容易從8萬人里突出重圍，來到了柜臺前，你發現，我操，來了10萬根綁著錢的竹竿，而且當有退票出來的時候，你要闖過3層人肉才能接近柜臺，竹竿在8個人身后一伸，錢就到了柜臺前。你低頭看了一眼手機，票就沒了，竹竿卻永遠在那里伸著，永不低頭，永不眨眼。如果沒有這10萬根竹竿，雖然你很可能還是搶不到票，但不至于沮喪成這樣：我TM為什么總是手最慢的一個？！！

防機器人搶票，也不是加個圖片驗證碼那么簡單。我寫過文章系統性分析過，圖片驗證碼有6種機器暴力破解的辦法，搶票插件用的是我說的第三種，OCR識別（光學字符識別——觀察者網注）。Google采用的Wave波形字母已經能比較好地防住機器OCR了，ems.com.cn上的驗證碼就是反面教材，機器OCR成功率接近100%，12306的比ems的圖片驗證碼強一點。不過，驗證碼設置得復雜一點吧，人們要噴：這只是便宜大學生和辦公室白領，農民工連26個字母都認不齊，怎么搞？搞動畫驗證碼吧，也有人噴，視力不好的人怎么辦？最后驗證碼搞得太簡單了，皆大歡喜了，其實最高興的是開發搶票插件的公司。

就算采用了機器完全不可能識別的驗證碼，也防不住社會工程學的破解辦法。招募一堆網吧打游戲的青少年朋友，每成功輸入50個驗證碼給1塊錢，或者等值的虛擬貨幣、游戲裝備，我保證想賺這個錢的人數不勝數。這點錢對轉賣車票的利潤而言，是可以接受的成本。有沒有什么技術可以防住社會工程學的破解辦法呢？能防住網吧青少年的驗證碼只有【2克濃度為3%的U235在大亞灣核電站能發多少KW的電】。

以上討論只是把12306當成和淘寶一樣沒有歷史包袱從零起步的交易系統，實際上，它不是，它后面的票池，還有電話售票、火車站售票、代售點售票等多個傳統渠道要服務。除了客運服務，12306還有全國最大（很可能也是全球最大）的大宗物資貨運系統。

架空政策（包括定價政策、警方打擊黃牛政策、身份驗證政策）談技術，是不可能解決春運搶票困局的，要想讓春運的時候每個人在12306搶票都毫無擁擠感（但不一定能搶到票，鐵路運力擺在那），那就是逼著12306買一大堆服務器對付春運，春運過去后，成為跟amazon一樣牛逼的云計算服務商。和逼北京修一條10車道的高速公路去八達嶺長城一個道理。

目前的12306技術上是還有問題，比如，搶票高峰，輸入個身份證號和圖片驗證碼都卡得要死（本人親測），服務器端繁忙，你瀏覽器端卡什么呀。

但人家在進步。相信2014年春運的時候，技術已經不再是一票難求的主要問題。在鐵路運力不可能神速增加的情況下，要做到春運更公平地買票，需要停靠政策調整。

下文針對的是春節國慶這種非常暑期。其它時期，大部分線路保持現狀就行了，問題不大，極少部分票源緊張的線路可以按春運處理：

1、拍賣法，價高者得之

當硬座票拍出飛機票價格的時候，相信票就不難買了（可惜就是貴了），也沒有那么多黃牛了。要說淘寶有什么能幫12306一下子搞定技術問題的，淘寶的拍賣系統可以幫忙，浙江省高院在淘寶拍賣一年多，成交26億。

可惜這個方法不可能實行。現在的高鐵票價都被媒體和意見領袖噴成啥樣了，何況是拍賣。再說，火車票畢竟是生存之剛需，票價20年來不漲本來就有照顧補貼的成分在里面，全拍賣可能也是不妥當。

2、抽簽法，運氣好者得之

開車前2個月開放報名，開車前7天抽簽，中途可取消。預存票款，抽不中退款。上傳身份證和正臉自拍照，機器核對。

這樣的話，攔截黃牛的成功率就高很多了，黃牛可以預存票款，可以找到大量真實身份證號，你黃牛再讓每個給你身份證號的人把身份證照片和臉部自拍也給你試試？即使有人真想找黃牛，給身份證照片還是會猶豫一下吧。而且中間手工操作多了很多，黃牛成本提高，還不一定搞得到票。反正都是碰運氣，我想真正的消費者還是會選擇自己先去碰運氣吧。

這個方法實施難度也大，無論怎么設計抽簽規則，必然有人大叫“有黑幕，不要相信政府”。

開車前7天出抽簽結果，改變行程的人應該在7天前就能決定改還是不改了。沒抽到的也還有時間想別的辦法。當然不一定是7天，15天，10天也可以，具體幾天要有數據模型來算。

3、拍賣+抽簽

軟臥、高鐵商務座等高價位的，拍賣，反正買這個的是經濟能力相對較強的。那就拼誰經濟能力更強吧。

硬座、站票抽簽。

4、憑身份證進站，車票跟發票一樣，是報銷憑證，不是進站憑證；退票后錢進入12306賬戶，不可提現，只可該乘客下次乘車用；黃金周期間，個人賬號最多訂購10張票

這個辦法可以打擊黃牛囤票再轉賣；運行一段時間后，按賬戶余額弄個排行榜就知道誰是黃牛，可惜這個需要車站設備改造配合。