我為12306 背書
在知乎上有位網友提問說：12306 外包給阿里巴巴、IBM 等大企業做是否可行？ 引起了網友們的熱烈探討。也正因為每年春節鐵路部門可謂大家聲討的對象，今年當然也不會例外，這兩年基本大家把怒火都發泄在了12306的訂票網站上，原因主要集中在網站性能引發購票困難的種種問題。
下面小編摘自知乎上大家贊同較多的一篇回復，轉載參考。
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系統改進面臨的一些問題，一些網友提出的解決方案的可行性。
1.“超級計算機能不能用于12306？”——不能，詳情見這個頁面；
2.“能不能用一個服務器甚至一個集群處理一個車次來加快速度？”——沒有意義，處理速度在硬件上主要受限于每個CPU線程獲得的內存帶寬與延遲，其中內存延遲更重要一些。一個核心處理還是一臺服務器處理，內存延遲這個參數是沒什么區別的；
3.“能不能在多地建立集群，分別處理某地的車次？”——道理同上；
4.“能不能取消座位實時復用，降低處理壓力？”——如果所有區間站的票數都是預先確定的，那么到最后必然會出現有的冷門區間座位空置的情況，這是旅客不希望看到的；
5.“能不能把座位實時復用改為延時復用，熱門車次第一次放票后，根據區間之間的情況在下一個放票點調整各區間票額？”——這樣做可以減輕計算壓力，但是會讓大量旅客在第一次訂票失敗后等待下一次放票，增加下一次放票的負載。而且這會干擾旅客的搶票計劃，原來是一個車次沒票后就去找下一個車次，現在是一個車次要搶兩次甚至更多，反而讓旅客更累；
6.“能不能改成預先排隊抽簽，放票前訂票旅客在網上選擇進入隊列，放票后抽簽決定，避免爭搶”——很多人提出類似這樣的主意。注意熱門車次放票被搶光后，沒買到票的旅客會立刻去找其他車次是否有票。也就是說即便有這個預排隊功能，也不能阻止沒去排隊的旅客在放票開始之后去買票。對于熱門車次而言，參與預排隊的旅客抽簽失敗的概率非常高，而他們抽簽失敗后多數會失去對這個功能的信任，轉而繼續選擇搶票的方式，于是很快大多數人都會放棄抽簽。如果設定為只有參與預排隊的旅客才能買到票，那么抽簽失敗的旅客就失去了對其他車次的選擇權，結果更是一場災難。希望提出類似方案的網友好好思考我上面這些內容。
7.“12306的負載不是比淘寶小很多么？”——淘寶2013年雙11峰值訂單數量一分鐘79萬筆，12306每次放票按500熱門車次算，根據央視直播春運火車票搶票 這篇報道，熱門車次峰值搶票速度在每分鐘500票左右。很容易算出現在12306的峰值訂單量在一分鐘10萬-30萬的級別，與淘寶雙11峰值是相同數量級。
我在前面提過供求關系是12306面臨的核心問題，可能很多沒有經濟學基礎的網友不太明白，我這里再詳細解釋下。
任何限價商品出現供不應求情況時，最終獲得商品的大多數消費者支付的成本都是要超出商品本身的標價的。一個簡單的例子，超市限量出售半價雞蛋，大批顧客去搶購，雖然排隊買到的顧客為雞蛋本身花的錢少了，但是這些顧客付出了在那里排隊的時間和人力成本。排了很久隊才買到雞蛋的顧客，為雞蛋支付的時間與人力成本甚至可能超過了他買半價雞蛋省下的金額。于此同時，限量供應的條件下必然有一些排隊者最終沒能買到雞蛋。之所以有人買到雞蛋有人沒買到，大多數情況下是因為前者比后者付出了更多的成本；排隊者是在跟其他排隊者競爭，那些看到長長的隊伍就放棄的潛在消費者就是競爭的失敗者。
12306的情況也是如此。在現有的車票限價限量供應體系下，在某些高峰期有乘車需求的旅客數量大大超過了鐵路系統在這些時間段的運輸能力。在這個前提下，必然會有大量旅客無法在這些時間段買到車票，被迫改變出行計劃或者出行方式；而買到票的旅客為車票支付的成本，大多數情況下都是高于甚至遠高于車票本身的標價的。超出的這一部分成本，可以體現為向黃牛買票支付的溢價，可以體現為在車站售票口排隊付出的時間精力，而到了12306的時代，就可以體現為為了搶到票而付出的等待成本。
因此，12306無論怎么改進，都不可能降低因為供求關系而產生的旅客獲得車票的額外成本。12306改進的結果只是會改變這種額外成本的形式。以前沒有網絡訂票，大家去售票廳排隊或者一次又一次打電話；現在有了網絡訂票，大家在網上卡到罵娘。但大家吐槽12306的種種缺陷時，其實原因并不是旅客真的特別重視網站的美觀程度、重視網頁的代碼是不是高水平，而是還有很多人沒能按自己的心意買到車票。旅客對12306的需求只有一條——買到旅客需要的車票；可是12306無法解決這個需求。對于旅客來說，卡三個小時但買到了票的體驗是60分，三次放票時每次都一秒鐘就被告知票已售完的體驗是0分。
于是12306的未來就會很麻煩。隨著系統的改進升級，整套系統的負載能力會越來越強大。可是性能的提升意味著熱門車次放票后售空的速度越來越快。上面引據的例子里，一個車次一分鐘就賣掉500張票；性能改進后，最終達到的效果可能是5秒鐘就賣掉全部票額。而對于旅客來說，賣票速度提升并不會減少他們為了獲得車票而付出的額外成本——以前是買一張票卡10分鐘半小時，現在一個訂單幾秒鐘就確認了，但是為了能在幾秒鐘里搶過其他旅客，你需要提升你的電腦性能，增加你的網絡帶寬，降低你的網絡延遲；你需要更強大的搶票軟件，一秒鐘內發起更多的請求……最后，你在硬件設備上增加的投入就是你付出的額外成本，相比之前你在等待網頁響應時付出的時間成本來說只是換了形式。以前售票廳時代大家比拼誰去排隊排的早，以后大家比拼誰的網絡性能好。而且，12306的響應速度越快，旅客之間的設備軍備競賽也就會越激烈。最后，大家會為了降低幾十毫秒的延遲購買國內的vpn通道，改用表現更好的網卡，跑到號稱能提供更高搶票性能的網吧去搶票……然后還是會有大量用戶因為競爭不過其他旅客而被迫改變出行計劃或出行方式。而且當旅客紛紛提升自己設備的性能時，對12306的壓力也會越來越大，12306自己也必須同步增加性能，投入越來越高的成本。從技術的角度講，12306面對的是一個隨著它自身性能增長而同步甚至更快提升的需求，具有這樣殘酷要求的類似案例就只有股票、期貨電子交易市場而已。甚至，12306最終的壓力可能會超過這些市場。
回到最開始的問題：12306包給知名大企業是否會更好？答案是，無論誰來做，最終結果都是一樣。
