服務器集羣就是指將很多服務器集中起來一起進行同一種服務，在客戶端看來就象是隻有一個服務器 集羣可以利用多個計算機進行並行計算從而獲得很高的計算速度，也可以用多個計算機做備份，從而使得任何一個機器壞了整個系統還是能正常運行
RAC，全稱real application
clusters，譯爲“實時應用集羣”， 是Oracle新版數據庫中採用的一項新技術，是高可用性的一種，也是Oracle數據庫支持網格計算環境的核心技術。
曾在淘寶寫過一段時間代碼，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 的動態庫存很複雜。
先說秒殺。
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 萬億。
淘寶擁有各種自主研發團隊：服務器、交換機（網上可以搜索到淘寶公開的綠色服務器開放標準）；操作系統（Linux Kernel taobao 版，yunos 手機操作系統是阿里雲的，暫時不計入）、Web 服務器（Tengine）、Java 語言虛擬機（JVM taobao 版）、數據庫（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 秒殺 iPhone 5S 就不一定，有人可能網銀有問題，有人可能改變主意不想要了），所以就又帶來訂單取消重新恢復庫存的問題。還有想要的消費者們，會認爲還有機會，繼續在前臺刷一會兒，最終這個秒殺會被熱情的消費者們猛刷 30 秒到 1 分鐘。
（超賣這一部分科普筆法寫得有錯誤，鑑於 12306 目前全在內存數據庫中讀寫，沒有產生超賣問題，先把這個段落刪去。感謝@吹西門的雪指正）
好了，講了這半天淘寶，可以說 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 網站的時候，鐵道部就有這種人工預分配的策略了。
想象一下，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 年春運的時候，技術已經不再是一票難求的主要問題。在鐵路運力不可能神速增加（孫中山先生計劃的 20 萬公里鐵路，土共修了快 70 年，才修到 10 萬公里）的情況下，要做到春運更公平地買票，需要停靠政策調整。
下文針對的是春節國慶這種非常暑期。其它時期，大部分線路保持現狀就行了，問題不大，極少部分票源緊張的線路可以按春運處理：
1. 拍賣法，價高者得之
當硬座票拍出飛機票價格的時候，相信票就不難買了（可惜就是貴了），也沒有那麼多黃牛了。要說淘寶有什麼能幫 12306 一下子搞定技術問題的，淘寶的拍賣系統可以幫忙，浙江省高院在淘寶拍賣一年多，成交 26 億。
可惜這個方法不可能實行。現在的高鐵票價都被媒體和意見領袖噴成啥樣了，何況是拍賣。再說，火車票畢竟是生存之剛需，票價 20 年來不漲本來就有照顧補貼的成分在裏面，全拍賣可能也是不妥當。
2. 抽籤法，運氣好者得之
開車前 2 個月開放報名，開車前 7 天抽籤，中途可取消。預存票款，抽不中退款。上傳身份證和正臉自拍照，機器覈對。
這樣的話，攔截黃牛的成功率就高很多了，黃牛可以預存票款，可以找到大量真實身份證號，你黃牛再讓每個給你身份證號的人把身份證照片和臉部自拍也給你試試？即使有人真想找黃牛，給身份證照片還是會猶豫一下吧。而且中間手工操作多了很多，黃牛成本提高，還不一定搞得到票。反正都是碰運氣，我想真正的消費者還是會選擇自己先去碰運氣吧。
這個方法實施難度也大，無論怎麼設計抽籤規則，必然有人大叫“有黑幕，不要相信政府”。
開車前 7 天出抽籤結果，改變行程的人應該在 7 天前就能決定改還是不改了。沒抽到的也還有時間想別的辦法。當然不一定是 7 天，15 天，10 天也可以，具體幾天要有數據模型來算。
3. 拍賣 + 抽籤
軟臥、高鐵商務座等高價位的，拍賣，反正買這個的是經濟能力相對較強的。那就拼誰經濟能力更強吧。
硬座、站票抽籤。
4. 憑身份證進站，車票跟發票一樣，是報銷憑證，不是進站憑證；退票後錢進入 12306 賬戶，不可提現，只可該乘客下次乘車用；黃金週期間，個人賬號最多訂購 10 張票
這個辦法可以打擊黃牛囤票再轉賣
運行一段時間後，按賬戶餘額弄個排行榜就知道誰是黃牛了
可惜這個需要車站設備改造配合。