從技術層面看，從客觀現實出發，12306 逢節必癱情有可原嗎？

//基本的位操作定義
#define _LOCK_SEAT( a, b ) ( a |= b )
#define _HAVE_SEAT( a, b ) ( ( a b ) == 0 )
#define _ISLOCK_SEAT( a, b ) ( ( a b ) == b )
#define _FREE_SEAT( a, b ) ( a = (~b) )

return nSeat;
}
return -1;
}


------------------------下面是原回答---------------------------------------------------------------------------------------------
12306做得再好，也是無法改變買票難的客觀現實的，如果不癱的話，可能還會讓人覺得 網站一點都不卡，票居然眨眼就沒了，一定有黑幕啊！

從技術層面來講，以鐵道部擁有的資源和條件，12306是應該也可以做得更好的，12306或許是有著巨大的挑戰和困難，但至少不會是什麼出票事務有多複雜。

火車票售票邏輯其實是很簡單的，絕沒有有些同學說的那麼複雜，畢竟不同車次之間是無關聯的，而一趟車上，不同座位之間也是沒有關聯的，只是同一個座位在不同的車站上有關聯性。

下圖是我自己寫的一個簡單測試程序，一個2000座位的火車經過30個車站測出票邏輯模擬，經過優化之後，單線程每秒處理可以在600萬以上，雖然沒有考慮連接處理和其他邏輯，但至少在出票事務上是幾乎沒有瓶頸的，尤其是這個模擬還沒有考慮把不同席別的座位分開，所以實際中處理效率應該更快。而除了核心出票邏輯，其他事務幾乎都可以通過分散式處理來提高負載。

美國醫保網站出現的故障和中國12306網站的問題是否可以類比？

春運到來之前，火車票購票網站12306新版6日將上線試運行。新版推出了「更多選項」功能，旅客在錄入乘車人、日期、車次、席別等信息後，12306網站即可為旅客提供動態刷新、自動提交訂單等新功能，而這些功能此前是搶票插件獨有的。

　　這項功能簡直是業界良心，我都找不到吐槽點了 利益相關：剛幫同事搶了一張回家的卧鋪票。前後用了十分鐘。
　　相比之下——【美國醫改網站周一訪問量突破100萬 雖未崩潰但錯誤依舊】作為奧巴馬政府力推的新醫保改革法案所包含的一項重要舉措，醫保網站自今年10月1日推出以來，一直因網站伺服器和軟體平台故障頻頻，造成登錄困難，導致民眾怨聲載道，引發輿論對奧巴馬執政能力的質疑。

　　據說奧巴馬醫改網站投資了6.78億美元，崩潰了好幾輪了，這周修復後錯誤依舊。

　　再也不黑12306了！換算出來3000多萬美刀的費用，相比於美國醫改網站只有十分之一不到，峰值連接人數數十倍於醫保網，雖然故障不少，但勉強能正常運行，大多數人還是能順利訂到票，以後再也不噴它了！

誰能給我從技術層面上解釋一下為什麼 12306 捨不得買一個 https 證書？

轉自西西河，有關12306技術難度和實現水平的又一篇重磅文章。作者是前淘寶工程師，後來在一家電商公司做技術副總。和大多數人一樣，12306剛出來時他也罵，甚至為了證明這事兒很容易做，他發起了一個"替12306設計系統"的開源項目，兩年後就有了這篇長微博。如果你還覺得自己很牛逼，先超越他的思考吧。我只轉帖。。。不接罵。。。不謝！

車票表:
(車次, 區間, 已售)
(1024, [1,2], 0)
(1024, [1,2,3], 0)
(1024, [1,2,3,4], 0)
(1024, [2,3], 0)
(1024, [2,3,4], 0)
(1024, [3,4], 0)
主鍵是自增欄位,給"車次"欄位添加索引.
優化並發時,可以考慮根據"車次"進行分表分庫.
區間[1,2,3]的含義是:從車站1上車,經過車站2,到車站3下車.

2.找出一個區間如[2,3,4]里的子區間演算法(以PHP為例):
function foo(array $arr, array $tmp) {
$size = count($arr);
if($size == 1) return;
for($i=2;$i&<=$size;$i++) { $tmp[] = array_slice($arr, 0, $i); } array_shift($arr); foo($arr, $tmp); } $arr = array(2,3,4); $tmp = array(); foo($arr, $tmp); var_export($tmp); 在本例中得到: [2,3] [2,3,4] [3,4] 退票邏輯比購票邏輯簡單得多,直接給對應車次,對應區間的已售車票-1即可: update 車票表 set 已售=(已售-1) where 車次=1024 and 區間="2,3,4"; 余票查詢邏輯: 例如查詢車次1024上區間[2,3,4]的余票: select 已售 from 車票表 where 車次=1024 and 區間 in ("2,3,4", "2,3", "3,4", "1,2,3,4"); 用500減去上述區間已售車票的和就是區間[2,3,4]上的余票. 這裡假設列車滿載為500人.

邏輯理清了,個人覺得也並沒有如何如何的難,如何如何的不可實現.

12306存在的問題:
第一個,動不動就要求重新登錄,也就是登錄突然失效.
第二個,余票顯示時有時無,余票不能做到實時顯示就是在浪費用戶的精力甚至徒增伺服器壓力,讓大家以為還有票,繼續刷,其實沒有.
第三個,驗證碼偶爾出現明明輸入正確卻提示錯誤的問題.

除非讓中國最頂尖的技術團隊來做也是這個結果，否則就不是。

不好就得被批評，無關原諒不原諒

還是看到很多人在噴，我想，既然題主開了這個問題，自然是希望大家在技術上討論問題，而不是在那吃飽了沒事幹的在這噴。
洗地不洗地的，請仔細考慮，拿出你認為的技術方案來。

知乎，不是百度知道，也不是網易跟帖。
噴，是最沒用的答案。
你要是真有技術，你就說出你認為的技術問題在哪，你認為該怎樣解決。而不是毫無實質內容的回答，卻能依靠【紅人效應】得到那麼多的贊。

空談誤國，實幹興邦！

下文是原回答：
-------------------------------------------

必須情有可原啊！

就算是把淘寶團隊，IBM，亞馬遜團隊搞來，也不一定搞的比現在好多少。
只看一趟車，有那麼多個站，有的人才 A 站坐到 Z 站，有的 A 站 坐到 C 站，有的 B 站到 Z 站，有的 C 站到 Y 站，你告訴我，讓你寫這樣的系統，你會考慮怎麼做？是不是只要有一個人買票，所有人就不能買到這人需要的區間的這個座位？這意味著什麼，只要出一張票，就要全局所有訪問者都要通知。那麼多趟車次，怎麼可能處理的過來，你考慮過資料庫的感受嗎？你考慮過後端存儲需要多大的 IOPS 嗎？

具體說一下商品吧：
以一趟車為例，假如他有 A-Z 共 26 個站。有商務座、一等座、二等座。
那商品可絕對不是 3 種！
因為人可能從 A 去 B，可能 C ……那麼從 A 出發的商品就有 25 個商品！
那麼從 B 出發的呢，24 種商品
……
假如有人買了 A 到 Z 的，那麼其他所有商品數量都要減 1。
假如買了 A - B 的，那麼是不是所有從 A 出發的商品，都要減 1？
這麼說應該明白了一些，就不再一一展開了，想算的話，誰有空算一下這樣有多少種商品吧。
這和淘寶可不一樣！淘寶一個商品就是一個商品，和其他商品沒關係。
火車票這個，一趟車就有這麼多種商品，而且，商品還是動態庫存的，不是淘寶那樣的靜態庫存。

進程死鎖怎麼處理？
不管你前台做的再好，後台都要落在資料庫上的。資料庫性能怎麼提升？
資料庫是需要保證一致性的！集群的資料庫之間光同步就夠受的。

還有，你考慮過，還有電話訂票這個渠道么？這個渠道訂的票也是要寫入到這個系統的！

你要問我淘寶為啥撐得住。淘寶的商品和商品之間是松耦合，甚至等於是 0 耦合的，這個商品和那個商品是沒有關係的。簡單的說，買的時候，只要保證庫存別 &< 0 就好了。但票可不一樣，上面說過了！

還有人在噴黃牛用假身份證刷票，不去和公安系統做認證？
我去，現在這個樣子就已經處理不過來了，再和公安系統做認證，你考慮過公安系統能撐得住這麼大的認證請求量么！

來自wiki CAP定理

在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer"s theorem），它指出對於一個分散式計算系統來說，不可能同時滿足以下三點：

• 一致性（Consistency)（所有節點在同一時間具有相同的數據）
• 可用性（Availability）（保證每個請求不管成功或者失敗都有響應）
• 分隔容忍（Partition tolerance）（系統中任意信息的丟失或失敗不會影響系統的繼續運作）

根據定理，分散式系統只能滿足三項中的兩項而不可能滿足全部三項

其實無論如何，在運力嚴重不足的春運這個背景下，12306也會繼續被唾罵下去，無論其用戶體驗做的多麼好或者多麼差。

本質上來說，12306這個網站的建立，直接把過去幾十年來春運時，各個大中小城市各個火車站排隊買票、黃牛刷票、乘客買不到票等等情況，完完全全的搬到了互聯網上。
而另一方面，以前的各個火車站發生的矛盾、衝突、問題，在全國範圍內集中到了一個地方，也就是12306上。
因此，之前在火車站賣票沒法解決的黃牛問題（網上黃牛）、排隊等很久（12306上刷很久刷不到）、買不到票（12306上票沒了），被集中並且放大的呈現在了12306上。
在這樣的大背景下，只要運力不足，春運需求旺盛，永遠會有人對12306不滿下去。

而背後真正的原因，在於各種資源的嚴重地域不平衡發展（如教育、醫療、機會、收入等在各地的不平衡，導致大批人背井離鄉，從而導致春運對運力的高爆發需求）。如果每個人的家鄉都能夠像北上廣深等地一樣擁有最好的教育醫療環境、足夠的就業機會、以及足夠的收入，以中國人對故土的依戀，背井離鄉去外地的只會是少數。

可以理解，但不是情有可原。
如果一項技術尚不成熟，那麼執意要用此項技術來製作產品，那麼受到使用者的批評是理所當然的。此外，即使12306確實遇到了技術上的難題，這也只能說有一定的挑戰性，而並非證明了技術上不可實現——這是有著本質不同的。對於後者，我可以充分的同情12306；但對於前者，我只能認為12306沒有真正用心去做（聯繫12306那不太靠譜的根證書我不得不如此認定）。

「就算是把淘寶團隊，IBM，亞馬遜團隊搞來，也不一定搞的比現在好多少。」就我目前搜集到資料來看，只能認為這是臆測，希望提出這句話的人可以提供來源。

你們想要一個會崩潰的網站還是1秒鐘票全部售完流暢的網站？

我相信在技術上12306能做的更好，可是這就解決問題了嗎？ 當人們指責12306的時候真的是覺得網站癱瘓影響了他們的用戶體驗了嗎？ 不，他們是罵網站癱瘓引起的買不到票。

假設12306請到了淘寶的團隊做了一個瞬間能處理上億次訂單無比流暢的網站，那也能讓所有的票短時間內全部售罄。 該買不到票的還是買不到票，人們還會罵的更凶：

「媽的，票12點開始賣老子就去上了個廁所才12點01票就全賣光了！ 狗屁的鐵路部，一定有黑幕!"

"跟你講啊，今天火車站售票處被砸啦！砸的好啊！ 排了3天隊了，好不容易等到售票處開門那個鐵道部的傻逼說沒票了，去哪的都沒了！ 連排在第一位的人都沒買到，說什麼票全被網上的人買光了。 狗屁！肯定是被當成內部票了。 這群貪污受賄的狗官，要是毛主席在世的你們全得槍斃!"

"朋友們，你們還在為回不了家而煩惱嗎？ 來團圓火車票網訂票吧！ 只要輸入您的身份證號，車次和100%車費的手續費就能搶到票啦，搶不到全額退款!"
.......

從技術層面上講，確實沒有做好，一幫子人搞了好幾年花了那麼多錢，票買不到情有可原，因為運力不足，但是畢竟每年90%以上的人還是回家了，你網站起碼不宕機，演算法其實還能再優化好一點，在一定程度上還是能夠合理調配資源的。