12306能扛住明星出軌這種流量衝擊嗎？
整理 | Jane
出品 | AI科技大本營
2019 年的春運將於明天正式開啟，據國務院新聞辦公室 18 日在新聞釋出會上的介紹，今年預計全國旅客傳送量將達到 29.9 億人次，比去年春運增長 0.6%。最近基於各種軟體、小程式的搶票大戰已經如火如荼， 每年最難買的就是一張春運回家的票 。據 2018 年春運期間的資料統計，12306 日均頁面瀏覽量達到 556.7 億次，最高峰時段頁面瀏覽量達 813.4 億次，1 小時最高點選量 59.3 億次，平均每秒 164.8 萬次。
這兩年 12306 的技術貌似有長進，不斷嘗試引入外部技術力量來解決問題，比如與阿里雲合作，將業務放到阿里雲的計算平臺上，幫助 12306 平穩渡過春運的購票高峰，而 12306 系統在春運高峰期可以穩定執行，又採用了哪些具體技術？一位網友曾與大家分享過 12306 與雲端計算技術相容性、12306 業務與雙十一業務背後面臨哪些不同的技術難點等知識：
節選自：@匿名使用者（阿里雲程式設計師，某年 12306 春運專案幕後碼農）
1.從技術上看，不是說做好了阿里雙11就能做好 12306。個人感覺兩者同屬於重量級的網站業務，雙十一在業務規模上更有挑戰，而 12306 則在業務複雜度上更高。
2.火車票跟很多票（包括淘寶天貓的商品、機票、體育場館門票等）有不一樣的屬性。比如，從北京到廣州，沿途有多個站點，理論上乘客可以選擇任意 一段區間購票，所以每買一張區間票，可能同時裂變出多張區間票。這個邏輯比大多數電子商務系統要複雜的多.購票差異還不僅限與此。假如說要再新增一些更人性化的feature，比如根據訂票者身份證裡的年齡優選上下鋪、優選號等，那麼查詢和出票邏輯就更復雜了。
3.天量的火車票查詢是影響 12306 效能的重要原因之一，大概佔了 90% 以上的訪問流量。更棘手的是：峰谷的查詢有天壤之別，幾乎沒有辦法在成本和併發能力之間做一個好的平衡。以往的一個做法是從幾個關鍵入口流量控制，保障系統可用性，但是會影響使用者體驗。
淘寶/天貓大促的時候，也會增加伺服器，阿里的業務盤子大，這些新增的機器很快會被其他業務（包括阿里雲）消化掉，可能還不夠。但是對於 12306 來說，就比較難做到這一點。這成為12306 與阿里雲合作的一個契機：通過雲的彈性和“按量付費”的計量方式，來支援巨量的查詢業務，把架構中比較“重”（高消耗、低週轉）的部分 放在雲上。這是一個充分利用雲端計算彈性的絕好例項，也是在系統架構上做“輕重分離”的一個典型case，把小而精的核心業務系統保持不動，把 “傻大笨粗”（非貶義）的系統遷移到雲端計算上。
然而，即使有一些後端的技術支援，也 有阿里雲端計算作為背後的基礎設施， 12306 還要解決高併發，分散式，快取，負載均衡等問題，其中一個非常關鍵問題就是高併發情況。談到高併發問題，就不得不提總因這個問題而崩潰的微博系統，在“鹿晗公佈戀情”的時候系統沒抗住，經過不懈的努力後，表示可以同時支援 8 位明星併發出軌，然而在“趙麗穎、馮紹峰官宣結婚”事件上，還是沒撐住。那在春運高峰下都不會崩潰的 12306 系統，是不是坑得住這種流量衝擊呢？
近日，關於這個話題大家在知乎上也展開了熱烈的討論：
-
先列舉幾個【可以支援、扛得住】方的觀點：
@那位先生： 首先我們需要知道的是，一張火車票的售出不僅僅只是把這張火車票對應的座位狀態標記為已售出，其中還可能會影響到該車次其他路程段的售票狀態。對於微博這類資料傳播顯然是沒有售票複雜的。然後我們再看一組官方資料：從2018年12月30日開始，12306網站開始預售，農曆臘月廿三（小年）的車票，春運售票漸入高峰，至2019 年1月4日，達到第一輪高峰峰值，日頁面瀏覽量（PV）達 1310.6 億次，全天發售車票 1282 萬張。
@李國寶： 回顧 12306 網際網路售票系統的發展，高峰售票量由 2012 年春運的 119 萬張 / 天，增至 2013 年春運的 364 萬張 / 天，系統架構的優化與調整起到了至關重要的作用。2014 和 2015 年春運售票量再次超過 500 萬和 600 萬，最高達到 636 萬 / 天，驗證了二次優化後架構的合理性和有效性。 12306 網際網路售票系統在優化架構的同時，還在核心業務中用低成本的 X86 平臺全面替代了原有的小型機平臺，其架構優化實踐對同類大規模併發訪問的網上交易系統具有重要的借鑑意義。
@霜公子： 以技術水平來看優化後的12306 是有技術實力抗住明星出軌的，然而顯然業務場景差距很大。12306的難點更多高併發下事務處理，寫和讀的一致性等等，但是車票的放票高峰是可以分時段分流並且可大概估計的，在春運、十一等假期重點優化加資源。明星出軌其實更多的只是一個高併發讀的場景 ，也許都比不上某條春運熱門線路的查詢刷屏請求量高，但是什麼時候出軌什麼時候被報出來 是沒法預估的。如何保證資源不浪費的情況下又能抗住瞬時的大量請求是很難解決的。
-
下面是幾個【技術角度】的分析觀點：
@豬了個去： 兩者涉及的難點不一樣。12306系統中涉及的是海量事務的高併發，明星出軌是比較單純的讀流量比較大。場景就比這個簡單多了，按照過去 n 次的故障，都是程式猿不怎麼小心，或者是加的機器不夠造成的。明星出軌要麼是熱搜掛了：熱搜是多麼美好的一個熱點應用啊，都基本是一個關鍵詞，關鍵入口引導往固定的搜尋詞，然後加快取機器就好了，流量不要落到後面的搜尋引擎就行。要麼是評論掛了，要麼是轉發掛了：那幾千萬評論說多是多，但實際上沒幾個人會無聊得把這些評論看個遍，也沒人在乎到底誰比誰評論得早，順序亂一點都沒太大關係。最難的屬於時間線的維護，幾千萬轉發意味著有幾千萬條動態被髮出去了，也意味著寫流量大增。不過比 12306 好的一點是：沒有事務就好說，不會產生衝突。
@懂二進位制的十： 普通人都太小看 12306 的負載能力了，其實 12306 的研發可以稱得上是鎮國級的黑科技。舉個例子北京到深圳有 24 站，當買下這一張車票時，庫存得去除 24+23+……2+1＝300 張票。2018 年春運全國旅客傳送量約 29.8 億人次，平均每天約 1 億人次（經評論區指正，這是總客流量，鐵路發客量不到 4 億人次）。跟這個數字比較起來微博百萬乃至千萬級的閱讀量簡直就是弟弟，更不要說春運售票是高併發事件，要求寫和讀一致，而微博更偏重於高併發的讀，雖然流量爆炸，但沒有產生事務。大家之所以會產生微博很容易宕機的錯覺大概是因為明星出軌是一個不可預測事件，完全無法預先做好準備，而像卓偉這樣喜歡留一句“週一見”的預告型爆料就十分方便提前加伺服器。
@Arthur Guo： 拋開場景來談技術不怎麼靠譜，好多還扯到了架構，這個分明是兩個場景問題。12306/雙11，是如何應對瞬時流量的問題，這個考驗的上限；微博，是如何應對突發流量的問題，這個考驗的是靈活度，所謂的動態擴容，有經驗的同學可能還會知道，峰值只有很短的時間，有的時候擴容完了，流量就下去了。理論上來說，微博峰值的流量肯定不如淘寶和 12306，並且淘寶和 12306 還有更多的是寫，但是如果淘寶不知道哪天是雙十一的零點，一年 365X24X60X60 每一秒都可能是雙十一的零點……這個就是突發流量和能提前準備的流量應對的不同，不過一切問題本質都是經濟問題，突發流量面臨的問題就是，平時流量帶來的經濟價值在保證利潤的前提下，能夠常備多少機器。
如果不從技術角度，從【使用者體驗角度】出發或【搞笑風格】的回答：
@狗子你變了： 明星你隨便出軌，只要我火車不出軌就就行了。
@lou： 你是不是小看春運了。
@大熊： 看到這個問題，我突然想起了前幾天聽羅振宇的演講《時間的朋友》。記得裡面說起春晚的廣告，天貓中了標，把伺服器擴充套件到了雙十一巔峰時的四倍，結果春晚當天還是掛了。後來發現春晚當天的訪問量是雙十一峰值的十六倍······事實證明，雙十一或者玩微博的人群，仍然只是一小部分，12306 的負載能力遠比你想象的大得多。你們對人民群眾的力量一無所知······
@王聽玄： 對於一般的流行網站來說，明星出軌的流量叫做衝擊。對於 12306 來說，明星出軌的流量叫做一個普通的星期二。
@灬藍灬天灬： 哪個明星出軌的流量大過春運？
（以上回答均來源於知乎使用者）
營長也諮詢了幾個技術朋友和作者，真要比較，不是簡單一兩句就能一概而論的，涉及的專業知識也很多，資料庫、快取、網路、分散式佇列、CPU 等等，單從高併發情況來說，12306 和 微博也是不同的，微博的高併發是讀，12306 是讀和寫，所以應對的問題場景不同，仍需要針對應用場景做具體分析與優化。
引用連結：
https://www.zhihu.com/question/27321479/answer/37292320
https://www.zhihu.com/question/308463476
https://www.zhihu.com/question/308463476/answer/569452666
https://www.zhihu.com/question/308463476/answer/569462672
https://www.zhihu.com/question/308463476/answer/571102424
https://www.zhihu.com/question/308463476/answer/571489896
https://www.zhihu.com/question/308463476/answer/570655216
（*本文為 AI科技大本營整理文章，轉載請聯絡微信 1092722531）
--【完】--
◆
公開課預告
◆
主題：端側卷積神經網路發展及其應用
時間：1月24日晚8點
講師：李戰斌（支付寶演算法專家）
