曾嗤之以鼻 現(xiàn)在認為幾乎是奇跡　　　　1月11日起，12306網(wǎng)站開始銷售除夕當日火車票。每到此時，鐵路系統(tǒng)唯一的官方購票網(wǎng)站12306就會成為眾矢之的。今年也不例外，12306再次被淹沒在一片埋怨聲中?！　?月5日，觀察者網(wǎng)刊登了問答網(wǎng)站“知乎”上的用戶王強的解答，回答“如果把12306外包給IBM或者阿里巴巴來做的話，能不能比現(xiàn)在做得好？”這一問題?！　?月10日，一位ID名為“代碼狗”的前淘寶工程師，后來在一家電商公司做技術副總的IT業(yè)內(nèi)人士也在著名論壇“西西河”上發(fā)文，表達了他自己對12306系統(tǒng)的看法。　　值得注意的是，“代碼狗”在12306系統(tǒng)剛上線時也有過不少微詞。為了證明12306系統(tǒng)很容易搭建，“代碼狗”甚至曾經(jīng)發(fā)起過一個名為“替12306設計系統(tǒng)”的開源項目。通過工作中的實踐，“代碼狗”對于12306系統(tǒng)也有了新的認識?！　∮^察者網(wǎng)轉載此文，供讀者參考?！　∪娜缦拢骸　」俜接喥本W(wǎng)站12306崩潰時的頁面（資料圖）　　本人淘寶技術專家，2012年在一家百強民企做電商副總，當時在極為艱苦的條件下帶隊開發(fā)了一個B2C（企業(yè)針對個人開展的電子商務活動——觀察者網(wǎng)注）網(wǎng)站，走支付寶和銀聯(lián)支付通道，年營業(yè)額千萬級（作者注：當然實在太少了，我只是說這個網(wǎng)站投入了實際的運營）?！　∫簿驮谀莻€時候，我對12306嗤之以鼻，覺得他們做得太爛了，認為自己能帶隊花幾百萬半年時間做個好的出來。于是我狂妄地想做一個開源的訂票系統(tǒng)給他們。我花了一個星期時間思考建立數(shù)據(jù)模型，思考到庫存這一步的時候，我才發(fā)現(xiàn)，12306的庫存復雜性比淘寶、京東高很多倍，運算量也大很多倍。傳統(tǒng)的分布式數(shù)據(jù)庫、緩存、負載均衡技術并不能恰好滿足12306的需求。　　在平時，12306也就是個正常的電商網(wǎng)站。但一到黃金周，12306就是一個全站所有商品都秒殺，所有SKU都是動態(tài)庫存的變態(tài)?！　〖词共豢紤]線下既有的電話、代售點等渠道，要實現(xiàn)一個12306，最少最少也是千萬級別的硬件投入（作者注：這是當時的估算，沒有精算，可能與實際相差較大，總之，我說得不一定對，12306的業(yè)務也許沒我說的那么復雜，但也絕不是某些人噴的那么簡單），軟件和人力另算。那些叫囂只要40臺服務器、只要2個架構師4個程序員、大談分庫分表和前端CDN的人們，只是紙上談兵罷了。所謂初生牛犢不怕虎，做了三年CMS和BBS，就以這個經(jīng)驗來噴12306，未免太天真了?！　∶襟w人噴12306，是他們不懂技術，沒有能力和耐心來分析背后的難度。技術人員噴，則是因為大部分的技術人員在短時間思考時，容易陷入過于樂觀的誤區(qū)，經(jīng)典的例子就是估算工作量，程序員們往往容易估算出一個超短的工期，把寫程序的工作樂觀地想象成了打字員照稿敲鍵盤的工作。　　知乎那篇文章，我覺得不是洗地。排名第一和第二的答案都說得很客觀。淘寶技術是比12306強大很多倍，淘寶現(xiàn)在的系統(tǒng)也是花了10倍于12306的錢、時間和人才做起來的。根本原因還是鐵路運力不能滿足春運需求，淘寶也解決不了這個問題?！　?2306這一年來進步非常大。從前段動畫驗證碼、分時段搶票，到后端去小型機、虛擬化、內(nèi)存數(shù)據(jù)庫的運用?？梢哉f，12306是中國政府機關做的最強大的網(wǎng)站（電商系統(tǒng)），能在短短一兩年內(nèi)做出這樣的改變，幾乎是個奇跡，就連一些市場化的民企都望塵莫及，甚至一些上市公司都比不上它?。ū热?1job和ctrip）?！　∈路墙?jīng)過不知難，在網(wǎng)上批判12306的人，大部分還是形成了【國企=壟斷+腐敗+低效】的思維定勢。小部分是真的輕視了它的難度?！　≈劣?2306一期工程3個億（含硬件）貴不貴我不評價，我只提供一個數(shù)字供參考，百度一年的研發(fā)費用（不含硬件）是10億，這個數(shù)字來自百度財報。網(wǎng)上能查到。3億看起來好大一個數(shù)字，真用到超大型的電商系統(tǒng)、搜索引擎系統(tǒng)里面，其實也不算什么天文數(shù)字了?！　≡俳忉屢幌?，為什么秒殺壓力大，以及為什么12306的動態(tài)庫存很復雜?！　∠日f秒殺?！　?013年12月25日前后，天貓搞了一個圣誕季積分兌換活動，持續(xù)幾天。25號上午10點12分，放出了15000個天貓魔盒（淘寶集市有人賣，大概190-230塊），從成交記錄上看，是19秒內(nèi)全部搶完?！　嶋H上，我也參加秒殺了，那天的題目特別簡單（請輸入xxx漢字的拼音首字母），我應該是5秒內(nèi)答題完成并提交訂單，結果告訴我排隊的人太多，擠不進去，并提示14秒以后重試。人太多就是因為題目太簡單了，門檻越低，5秒內(nèi)擠進去的人也越多嘛，如果題目換成【2克濃度為3%的U235在大亞灣核電站能發(fā)多少KW的電】，5分鐘之內(nèi)也不會有1萬5千人跟我競爭。　　我想，14秒以后哪還有我的事情呀，于是重新答題秒殺，結果出現(xiàn)了服務器錯誤的頁面。反復刷新幾次，就告訴秒殺結束了。　　在群里問了一下同事，有不到10個人回答我，都說沒秒到（也可能秒到的人悶聲發(fā)大財，不回復我）。　　淘寶是什么技術水平呢，淘寶有至少4000技術人員，至少4萬臺服務器（這都是兩年前的公開數(shù)據(jù)了，按規(guī)定可以談論），2013年11月11日成交額351億，2012年全年成交額超過1萬億。　　淘寶擁有各種自主研發(fā)團隊：服務器、交換機（網(wǎng)上可以搜索到淘寶公開的綠色服務器開放標準）；操作系統(tǒng)（LinuxKerneltaobao版，yunos手機操作系統(tǒng)是阿里云的，暫時不計入）、Web服務器（Tengine）、Java語言虛擬機（JVMtaobao版）、數(shù)據(jù)庫（MySQL內(nèi)核taobao版，google和facebook也有自己的版本，HBase淘寶版、還有自己全部從頭開發(fā)的OceanBase）、負載均衡器（LVS，LVS始創(chuàng)人就在淘寶，擔任研究員）、Java運行容器（Jboss，其創(chuàng)始人之一，王文彬，也在淘寶，擔任副總裁）?！　√詫氝€有數(shù)不清的開源項目和中間件，如高性能Java通信中間件HSF、分布式數(shù)據(jù)庫中間件TDDL、異步消息系統(tǒng)notify等等等等?！　∫蕴詫氝@樣的技術水平，也不能做到秒殺時讓每個用戶都沒有擁擠感，為什么呢？　　一是要尊重物理原理，一臺服務器一秒鐘能承受的計算量是有極限的，任你怎么優(yōu)化，采用多高效的算法和編程語言，都突破不了某個極限，比方說汽車發(fā)動機驅動的F1賽車至今也不能突破400公里的時速（超音速推進號那個1千多公里的時速不能算，那是飛機引擎驅動的）。再往深了說，就不容易懂了。感興趣的可以從著名的C10K問題開始看起?！　《且紤]經(jīng)濟效益，十一黃金周的時候，北京主城區(qū)到八達嶺長城的路堵得嚴嚴實實，但不能因為黃金周的高峰，就把這段路修成長安街那樣10車道的高速公路。否則的話，花費天文數(shù)字（真的是天文數(shù)字，12306那3個億大概只夠修1-3公里）。修了一段路，黃金周是可以飆到80公里/小時了，可平時呢，拿來給兩邊的居民曬谷子？　　淘寶目前的硬件和帶寬數(shù)量，已經(jīng)超出日常運營的需求了，就是留了相當大的余量給大促銷（眾所周知的是雙十一，雙十二，其實基本每個季度都有大促銷，每個月都有促銷，甚至天天都在促銷——聚劃算）。amazon當年就是為了應對黑色星期五的大促銷購置了大量的服務器，平時訂單量沒那么大了，amazon就把富余的服務器拿來搞云計算了。順便說一下，阿里云是當今中國第一世界數(shù)一數(shù)二的云計算服務商，和amazon走的路也有點像?！　≡僬f動態(tài)庫存?！　√詫毭霘⑻熵埬Ш械臅r候，只有一個商品（行話叫做SKU），它的庫存是15000個。有一個人秒殺到了，庫存就減1，19秒賣完的，一秒要成功產(chǎn)生789個訂單（下訂單的請求可能是8萬個，只是可能啊，非實際數(shù)字，也可能是1萬個，用于說明一下壯觀程度）。想象一下，你在廣場上賣火車票，一秒鐘有8萬人舉著錢對你喊：賣給我！　　上過大學的人都知道，比秒小的時間單位還有毫秒、皮秒、飛秒。但交易系統(tǒng)登記一個交易可不像原子繞著原子核跑一圈那么簡單，它要做這些事：檢查是否惡意訪問、取到系統(tǒng)時間、取到顧客默認收貨地址、核對顧客秒殺資格（當時的規(guī)定是天貓T2.T3達人）、生成訂單號、把顧客ID系統(tǒng)時間訂單號收貨地址寫入訂單系統(tǒng)、扣除顧客天貓積分、商品庫存減一、給顧客打標記（每人只能秒一個，下次不能秒了）等等，這每一件事都要花費毫秒級別的時間，這些操作加起來的時間可能是接近1秒級別的，但由于淘寶的服務器比較強悍，而且采用了分布式和集群技術，結果比1秒理想一點。但即使有1萬臺服務器，也不能把這個時間稀釋成萬分之一秒，因為，商品只有一種，它有15000個庫存，對應的數(shù)據(jù)庫記錄只有一行，所有的交易請求都要到這里來處理?！　∧懿荒馨堰@15000個拆分成5000個商品并分配到5000臺服務器上呢？那樣不就可以5000臺服務器同時處理了嗎？答案是不能，首先，5000個商品，意味著有5000個商品詳情頁，5000個購買按鈕，這對前期的營銷、引流是個災難。基本上就沒法做引流入口了，顯然這違背了商業(yè)管理原則，人為增加了信息混亂程度。其次，天貓魔盒秒殺也不是啥大事，即使按官方標價399元來計算，也就6百萬的交易。如果6百萬的交易要花費那么大的配套成本，那就太不劃算了。再次，淘寶有十幾億商品，這十幾億商品的展示交易和管理，本來就是分布到上萬臺服務器上去了。沒有必要再把每個商品按庫存拆成多個商品了?！　∵@789人搶到了，還不一定會付款（99積分換天貓魔盒還好一點，不需要去網(wǎng)銀，成本也極低，大部分是會付款的，3999秒殺iPhone5S就不一定，有人可能網(wǎng)銀有問題，有人可能改變主意不想要了），所以就又帶來訂單取消重新恢復庫存的問題。還有想要的消費者們，會認為還有機會，繼續(xù)在前臺刷一會兒，最終這個秒殺會被熱情的消費者們猛刷30秒到1分鐘?！　∫环昼娺^去了，服務器終于可以喘口氣了吧？等等，還有超賣，原來，某兩臺服務器在同一毫秒都拿到了鎖，都去減了庫存，15000個庫存，被下了15500個訂單，又得取消一部分訂單。。。如果采用單線程獨占鎖，是可以做到同時只有一個服務器線程減庫存的，但那樣就對并發(fā)高峰的能力就差了好多了。8萬人舉著錢，可能只有8個人能下單成功，這個擁擠狂熱的搶購就要持續(xù)10分鐘以上。平時秒個天貓魔盒，10分鐘也就10分鐘吧，雙十一就慘了，收銀臺一下子減少了90%，還想做到350億，要么做夢，要么再加10倍服務器和帶寬。所以，商業(yè)是不完美的，要在絕對正確和絕對的快速之間做個取舍，保證相對快速又極為正確，允許一定的庫存錯誤和超賣（具體允許多少我也不知道）?！　『昧?，講了這半天淘寶，可以說12306了吧？　　我以北京西到深圳北的G71次高鐵為例（這里只考慮南下的方向，不考慮深圳北到北京西的，那是另外一個車次，叫G72），它有17個站（北京西是01號站，深圳北是17號站），3種座位（商務、一等、二等）。表面看起來，這不就是3個商品嗎？G71商務座、G71一等座、G71二等座。大部分輕易噴12306的技術人員（包括某些中等規(guī)模公司的專家、CTO）就是在這里栽第一個跟頭的。　　實際上，G71有136*3=408種商品（408個SKU），怎么算來的？請看：　　如果賣北京西始發(fā)的，有16種賣法（因為后面有16個站），北京西到：保定、石家莊、鄭州、武漢、長沙、廣州、虎門、深圳。。。。都是一個獨立的商品，　　同理，石家莊上車的，有15種下車的可能，以此類推，單以上下車的站來計算，有136種票：16+15+14....+2+1=136。每種票都有3種座位，一共是408個商品。　　好了，再看出票時怎么減庫存，由于商務、一等、二等三種座位數(shù)是獨立的，庫存操作也是一樣的，下文我就不再提座位的差別的，只討論出發(fā)與到達站。另外，下文說的是理論世界的模型，不是說12306的數(shù)據(jù)庫就是這么設計的。　　旅客A買了一張北京西（01號站）到保定東（02號站）的，那【北京西到保定東】這個商品的庫存就要減一，同時，北京西到石家莊、鄭州、武漢、長沙、廣州、虎門、深圳等15個站臺的商品庫存也要減一，也就是說，出一張北京到保定東的票，實際上要減16個商品的庫存！　　這還不是最復雜的，如果旅客B買了一張北京西（01號站）到深圳北（17號站）的票，除了【北京西到深圳北】這個商品的庫存要減一，北京西到保定東、石家莊、鄭州、武漢、長沙、廣州、虎門等15個站臺的商品庫存也要減1，保定東到石家莊、鄭州、武漢、長沙、廣州、虎門、深圳北等15個站臺的商品庫存要減1。。?？傆嬕獪p庫存的商品數(shù)是16+15+14+……+1=120個?！　‘斎唬膊皇敲恳粡埰倍嫉膸齑娑纪耆@樣實時計算，可以根據(jù)往年的運營情況，在黃金周這樣的高峰時段，預先對票做一些分配，比如北京到武漢的長途多一點，保定到石家莊的短途少一點。我沒有證據(jù)證實鐵道部這樣做了，但我相信，在還沒有12306網(wǎng)站的時候，鐵道部就有這種人工預分配的策略了?！　∠胂笠幌?，8萬人舉著錢對你高喊：賣給我。你好不容易在錢堆里找到一只手，拿了他的錢，轉身找120個同事，告訴他們減庫存，而這120個同事也和你一樣被8萬人圍著；也和你一樣，每賣出一個商品要找?guī)资畟€人減庫存……這就是12306動態(tài)庫存的變態(tài)之處。比你平時買東西的任何網(wǎng)站的庫存機制都復雜幾十上百倍。　　再說一下?lián)屍辈寮?，機器永遠比人快，當你好不容易從8萬人里突出重圍，來到了柜臺前，你發(fā)現(xiàn)，我操，來了10萬根綁著錢的竹竿，而且當有退票出來的時候，你要闖過3層人肉才能接近柜臺，竹竿在8個人身后一伸，錢就到了柜臺前。你低頭看了一眼手機，票就沒了，竹竿卻永遠在那里伸著，永不低頭，永不眨眼。如果沒有這10萬根竹竿，雖然你很可能還是搶不到票，但不至于沮喪成這樣：我TM為什么總是手最慢的一個？??！　　防機器人搶票，也不是加個圖片驗證碼那么簡單。我寫過文章系統(tǒng)性分析過，圖片驗證碼有6種機器暴力破解的辦法，搶票插件用的是我說的第三種，OCR識別（光學字符識別——觀察者網(wǎng)注）。Google采用的Wave波形字母已經(jīng)能比較好地防住機器OCR了，ems.com.cn上的驗證碼就是反面教材，機器OCR成功率接近100%，12306的比ems的圖片驗證碼強一點。不過，驗證碼設置得復雜一點吧，人們要噴：這只是便宜大學生和辦公室白領，農(nóng)民工連26個字母都認不齊，怎么搞？搞動畫驗證碼吧，也有人噴，視力不好的人怎么辦？最后驗證碼搞得太簡單了，皆大歡喜了，其實最高興的是開發(fā)搶票插件的公司。　　就算采用了機器完全不可能識別的驗證碼，也防不住社會工程學的破解辦法。招募一堆網(wǎng)吧打游戲的青少年朋友，每成功輸入50個驗證碼給1塊錢，或者等值的虛擬貨幣、游戲裝備，我保證想賺這個錢的人數(shù)不勝數(shù)。這點錢對轉賣車票的利潤而言，是可以接受的成本。有沒有什么技術可以防住社會工程學的破解辦法呢？能防住網(wǎng)吧青少年的驗證碼只有【2克濃度為3%的U235在大亞灣核電站能發(fā)多少KW的電】?！　∫陨嫌懻撝皇前?2306當成和淘寶一樣沒有歷史包袱從零起步的交易系統(tǒng)，實際上，它不是，它后面的票池，還有電話售票、火車站售票、代售點售票等多個傳統(tǒng)渠道要服務。除了客運服務，12306還有全國最大（很可能也是全球最大）的大宗物資貨運系統(tǒng)?！　〖芸照撸òǘ▋r政策、警方打擊黃牛政策、身份驗證政策）談技術，是不可能解決春運搶票困局的，要想讓春運的時候每個人在12306搶票都毫無擁擠感（但不一定能搶到票，鐵路運力擺在那），那就是逼著12306買一大堆服務器對付春運，春運過去后，成為跟amazon一樣牛逼的云計算服務商。和逼北京修一條10車道的高速公路去八達嶺長城一個道理。　　目前的12306技術上是還有問題，比如，搶票高峰，輸入個身份證號和圖片驗證碼都卡得要死（本人親測），服務器端繁忙，你瀏覽器端卡什么呀?！　〉思以谶M步。相信2014年春運的時候，技術已經(jīng)不再是一票難求的主要問題。在鐵路運力不可能神速增加的情況下，要做到春運更公平地買票，需要?？空哒{整?！　∠挛尼槍Φ氖谴汗?jié)國慶這種非常暑期。其它時期，大部分線路保持現(xiàn)狀就行了，問題不大，極少部分票源緊張的線路可以按春運處理：　　1、拍賣法，價高者得之　　當硬座票拍出飛機票價格的時候，相信票就不難買了（可惜就是貴了），也沒有那么多黃牛了。要說淘寶有什么能幫12306一下子搞定技術問題的，淘寶的拍賣系統(tǒng)可以幫忙，浙江省高院在淘寶拍賣一年多，成交26億?！　】上н@個方法不可能實行?，F(xiàn)在的高鐵票價都被媒體和意見領袖噴成啥樣了，何況是拍賣。再說，火車票畢竟是生存之剛需，票價20年來不漲本來就有照顧補貼的成分在里面，全拍賣可能也是不妥當?！　?、抽簽法，運氣好者得之　　開車前2個月開放報名，開車前7天抽簽，中途可取消。預存票款，抽不中退款。上傳身份證和正臉自拍照，機器核對?！　∵@樣的話，攔截黃牛的成功率就高很多了，黃?？梢灶A存票款，可以找到大量真實身份證號，你黃牛再讓每個給你身份證號的人把身份證照片和臉部自拍也給你試試？即使有人真想找黃牛，給身份證照片還是會猶豫一下吧。而且中間手工操作多了很多，黃牛成本提高，還不一定搞得到票。反正都是碰運氣，我想真正的消費者還是會選擇自己先去碰運氣吧?！　∵@個方法實施難度也大，無論怎么設計抽簽規(guī)則，必然有人大叫“有黑幕，不要相信政府”?！　￠_車前7天出抽簽結果，改變行程的人應該在7天前就能決定改還是不改了。沒抽到的也還有時間想別的辦法。當然不一定是7天，15天，10天也可以，具體幾天要有數(shù)據(jù)模型來算?！　?、拍賣+抽簽　　軟臥、高鐵商務座等高價位的，拍賣，反正買這個的是經(jīng)濟能力相對較強的。那就拼誰經(jīng)濟能力更強吧?！　∮沧?、站票抽簽?！　?、憑身份證進站，車票跟發(fā)票一樣，是報銷憑證，不是進站憑證；退票后錢進入12306賬戶，不可提現(xiàn)，只可該乘客下次乘車用；黃金周期間，個人賬號最多訂購10張票　　這個辦法可以打擊黃牛囤票再轉賣；運行一段時間后，按賬戶余額弄個排行榜就知道誰是黃牛，可惜這個需要車站設備改造配合。求采納為滿意回答。