臨近春節12306.cn網站車票秒了又秒，全國人民都在罵，我們就來討論下12306網站的性能和實現，只討論性能問題，不討論那些UI，用戶體驗，或是是否把付款和購票下單環節分開的功能性的東西）
首先還是想先說說業務問題。
一.有人可能把這個東西和QQ或是網遊相比 。但我覺得這兩者是不一樣的，網遊和QQ在線上或是登入時訪問的更多的是用戶自己的數據，而訂票系統訪問的是中心的票量數據，這是不一樣的。不要覺得網遊或QQ能行你就以為這是一樣的。網遊和QQ 的後端負載相對於電子商務的系統還是簡單。
二.有人說春節期間訂火車的這個事好像網站的秒殺活動 。的確很相似，但是如果你的思考不在表面的話，你會發現這也有些不一樣。火車票這個事，一方面會伴隨著大量的查詢操作，更BT的是下單的時候需要對數據庫很多的一致性的操作，一方面是從起點到終點各個分段票的一致性，另一方面，買的人路線、車次、時間選擇很多，會不停地改變下單方式。而秒殺，直接殺就好了，沒有那麼多查詢和一致性的問題。另外，關於秒殺，完全可以做成只接受前N個用戶的請求（完全不操作後端的任何數據， 僅僅只是對用戶的下單操作log），這種業務，只需要在內存cache中放好可秒殺的數量，還可以把資料分佈開來放，100商品，10台伺服器一台放10個，無需在當時操作任何資料庫。可以訂單數夠後，停止秒殺，然後大量寫資料庫。而且秒殺的商品不多。火車票這個不是像秒殺那麼簡單的，春運時間，幾乎所有的票都是熱門票，而且幾乎是全國人民都來了，而且還有轉車業務，多條線的庫存都要做事務操作，你想想吧，這有多難。 （淘寶的雙十一也就3百萬用戶，而火車票瞬間有千萬級別甚至是億級別的）。
- 三.
有人拿這個系統和奧運會的票務系統比較。我覺得還是不一樣。雖然奧運的票務系統當年也一上線就廢了。但奧運用的是抽獎的方式，也就是說不存在先來先得的搶的方式，而且，是事後抽獎，事前只需要收信息，事前不需要保證數據一致性，沒有鎖，很容易水平擴展。
四. 訂票系統應該和電子商務的訂單系統很相似- ，都是需要對庫存進行：1）佔住庫存，2）支付（可選），3）扣除庫存的操作。這個是需要有一致性的檢查的，也就是在並發時需要對資料加鎖的。 B2C的電商基本上都會把這個事做成異步的，也就是說，你下的訂單並不是馬上處理的，而是延時處理的，只有成功處理了，系統才會給你一封確認郵件說是訂單成功。我相信有很多朋友都收到認單不成功的郵件。
這就是說，資料一致性在並發下是一個瓶頸 。
五.
鐵路的票務業務很變態
，其採用的是突然放票，而有的票又遠遠不夠大家分，所以，大家才會有搶票這種有中國特色的業務的做法。於是當票放出來的時候，就會有幾百萬人甚至上千萬人殺上去，查詢，下單。幾十分鐘內，一個網站能接受幾千萬的訪問量，這是很恐怖的事。 據說12306的高峰訪問是10億PV ，集中在早8點到10點，每秒PV在高峰時上千萬。 🎜🎜🎜🎜多說幾句：🎜
我說那麼多，我只是想從業務上告訴大家，我們需要從業務上真正了解春運鐵路訂票這樣業務的變態之處。
前端效能最佳化技術
要解決效能的問題，有很多常用的方法，我在下面列舉一下，我相信12306這個網站使用下面的這些技術會讓其效能有質的飛躍。
一、前端負載平衡
通過DNS的負載平衡器（一般在路由器上根據路由的負載重定向）可以把用戶的存取均勻地分散在多個Web伺服器上。這樣可以減少Web伺服器的請求負載。因為http的請求都是短作業，所以，可以透過很簡單的負載平衡器來完成這項功能。最好是有CDN網路讓使用者連接與其最近的伺服器（CDN通常伴隨著分散式儲存）。 （關於負載平衡更為詳細的說明請參閱「後端的負載平衡」）
二、減少前端連結數
我看了一下12306.cn，打開主頁需要建60多個HTTP連接，車票預訂頁面則有70多個HTTP請求，現在的瀏覽器都是並發請求的（當然，瀏覽器的一個頁面的並發數是有限的，但是你擋不住用戶開多個頁面，而且，後端伺服器TCP鏈接在前端斷開始，還不會馬上釋放或重要）。所以，只要有100萬個用戶，就有可能會有6000萬個連結（訪問第一次後有了瀏覽器端的cache，這個數會下來，就算只有20%也是百萬級的連結數），太多了。一個登入查詢頁面就好了。把js打成一個文件，把css也打成一個文件，把圖示也打成一個文件，用css分塊展示。把連結數減到最低。
三、減少網頁大小增加頻寬
這個世界不是哪個公司都敢做圖片服務的，因為圖片太耗頻寬了。現在寬頻時代很難有人能體會到當撥號時代做個圖頁都不敢用圖片的情形（現在在手機端瀏覽也是這個情形）。我查看了一下12306首頁的需要下載的總檔案大小大約在900KB左右，如果你訪問過了，瀏覽器會幫你快取很多，只需下載10K左右的檔案。但是我們可以想像一個極端一點的案例，1百萬用戶同時訪問，且都是第一次訪問，每人下載量需要1M，如果需要在120秒內返回，那麼就需要，1M * 1M /120 * 8 = 66Gbps的頻寬。很驚人吧。所以，我估計在當天，12306的阻塞基本上應該是網路頻寬，所以，你可能看到的是沒有回應。後面隨著瀏覽器的快取幫助12306減少很多頻寬佔用，於是負載一下就到了後端，後端的資料處理瓶頸一下就出來。於是你會看到很多http 500之類的錯誤。這說明後端伺服器垮了。
四、前端頁靜態化
靜態化一些不常變的頁和數據，並gzip一下。 還有一個變態的方法是把這些靜態頁面放在/dev/shm下，這個目錄就是內存，直接從內存中把文件讀出來返回，這樣可以減少昂貴的磁碟I/O 。使用nginx的sendfile功能可以讓這些靜態檔案直接在內核心態交換，可以大幅增加效能。
五、最佳化查詢
很多人查詢都是在查一樣的，完全可以用反向代理合併這些並發的相同的查詢。這樣的技術主要用查詢結果快取來實現，第一次查詢走資料庫取得數據，並且把資料放到緩存，後面的查詢統統直接存取快取。為每個查詢做Hash，使用NoSQL的技術可以完成這個最佳化。 （這個技術也可以用做靜態頁面）
對於火車票量的查詢，個人覺得不要顯示數字，就顯示一個「有」或「無」就好了，這樣可以大大簡化系統複雜度，並提升性能。把查詢對資料庫的負載分出去，讓資料庫可以更好地為下訂單的人服務。
六、快取的問題
快取可以用來快取動態頁面，也可以用來快取查詢的資料。快取通常有那麼幾個問題：
1）快取的更新。也叫快取和資料庫的同步。有這麼多種方法，一是快取time out，讓快取失效，重查，二是，由後端通知更新，一量後端發生變化，通知前端更新。前者實現起來比較簡單，但實時性不高，後者實現起來比較複雜 ，但實時性高。
2）快取的換頁。內存可能不夠，所以，需要把一些不活躍的資料換出內存，這個和操作系統的內存換頁和交換內存很相似。 FIFO、LRU、LFU都是比較經典的換頁演算法。相關內容請參考 Wikipeida的快取演算法 。
3）快取的重建和持久化。快取在內存，系統總是要維護，所以，快取就會遺失，如果快取沒了，就需要重建，如果資料量很大，快取重建的過程會很慢，這會影響生產環境，所以，快取的持久化也是需要考慮的。
諸多強大的NoSQL都很好支援了上述三大快取的問題。
後端效能最佳化技術
前面討論了前端效能的最佳化技術，於是前端可能就不是瓶頸問題了。那麼效能問題就會到後端資料上來了。下面說幾個後端常見的效能最佳化技術。
一、資料冗餘
關於資料冗餘，也就是說，把我們的資料庫的資料冗餘處理，也就是減少表連接這樣的開銷比較大的操作，但這樣會犧牲資料的一致性。風險比較大。很多人把NoSQL用來做數據，快是快了，因為數據冗餘了，但這對數據一致性有大的風險。這需要根據不同的業務進行分析和處理。 （註：用關聯式資料庫很容易移植到NoSQL上，但反過來從NoSQL到關聯式就難了）
二、資料鏡像
幾乎所有主流的資料庫都支援鏡像，也就是replication。資料庫的鏡像帶來的好處就是可以做負載平衡。把一台資料庫的負載均分到多台上，同時又保證了資料一致性（Oracle的SCN）。最重要的是，這樣還可以有高可用性，一台廢了，還有另一台在服務。
資料鏡像的資料一致性可能是個複雜的問題，所以我們要在單一資料上進行資料分區，也就是說，把一個暢銷商品的庫存均分到不同的伺服器上，如，一個暢銷商品有1萬的庫存，我們可以設定10台伺服器，每台伺服器上有1000個庫存，這就好像B2C的倉庫一樣。
三、資料分區
資料鏡像不能解決的一個問題就是資料表裡的記錄太多，導致資料庫操作太慢。所以，把資料分區。資料分割區有很多種做法，一般來說有以下這幾種：
1）把資料把某種邏輯來分類。例如火車票的訂票系統可以按各鐵路局來分，可按各種車型分，可以按始發站分，可以按目的地分……，反正就是把一張表拆成多張有一樣的字段但是不同種類的表，這樣，這些表就可以存在不同的機器上以達到分擔負載的目的。
2）把資料按字段分，也就是垂直分錶。例如把一些不常改的資料放在一個表裡，常改的資料放在另外多個表格裡。把一張表變成1對1的關係，這樣，你可以減少表格的字段數，同樣可以提升一定的效能。另外，欄位多會造成一筆記錄的儲存會被放到不同的頁表裡，這對於讀寫效能都有問題。但這樣一來會有很多複雜的控制。
3）平均分錶。因為第一種方法是不一定平均分均，可能某個種類的數據還是很多。所以，也有採用平均分配的方式，透過主鍵ID的範圍來分錶。
4）同一資料分區。這個在上面數據鏡像提過。也就是把同一商品的庫存值分到不同的伺服器上，例如有10,000個庫存，可以分到10台伺服器上，一台上有1000個庫存。然後負載平衡。
這三種分區都有好有壞。最常用的還是第一種。資料一旦分區，你就需要有一個或多個調度來讓你的前端程式知道去哪裡找資料。 把火車票的資料分區，並放在各個省市，會對12306這個系統有非常有意義的質的性能的提高 。
四、後端系統負載平衡
前面說了資料分區，資料分區可以在一定程度上減輕負載，但是無法減輕熱銷商品的負載，對於火車票來說，可以認為是大城市的某些主幹線上的車票。這就需要使用資料鏡像來減輕負載。使用資料鏡像，你必然要使用負載平衡，在後端，我們可能很難使用像路由器上的負載平衡器，因為那是均衡流量的，因為流量並不代表伺服器的繁忙程度。因此，我們需要一個任務分配系統，還能監控各個伺服器的負載狀況。
任務分配伺服器有一些困難：
我看到有很多系統都用靜態的方式來分配，有的用hash，有的就簡單地輪流分析。這些都不夠好，一個是不能完美地負載平衡，另一個靜態的方法的致命缺陷是，如果有一台計算伺服器死機了，或者我們需要加入新的伺服器，對於我們的分配器來說，都需要知道的。另外，還要重算哈希（一致性hash可以部分解決這個問題）。
還有一種方法是使用搶佔式的方式進行負載平衡，由下游的計算伺服器去任務伺服器上拿任務。讓這些計算伺服器自己決定自己是否要任務。這樣的好處是可以簡化系統的複雜度，而且還可以任意即時地減少或增加計算伺服器。但是唯一不好的就是，如果有一些任務只能在某種伺服器上處理，這可能會引入一些複雜度。不過整體來說，這種方法可能是比較好的負載平衡。
五、非同步、 throttle 和 批量處理
非同步、throttle（節流閥） 和批量處理都需要對並發請求數做隊列處理的。
所以，只要是異步，一般都會有throttle機制，一般都會有隊列來排隊，有隊列，就會有持久化，而係統一般都會使用批量的方式來處理。
雲風同學設計的「排隊系統」 就是這個技術。這和電子商務的訂單系統很相似，就是說，我的系統收到了你的購票下單請求，但是我還沒有真正處理，我的系統會跟據我自己的處理能力來throttle住這些大量的請求，並一點一點地處理。一旦處理完成，我就可以發郵件或簡訊告訴用戶你來可以真正購票了。
在這裡，我想透過業務和用戶需求方面討論一下雲風同學的這個排隊系統，因為其從技術上看似解決了這個問題，但是從業務和用戶需求上來說可能還是有一些值得我們去深入思考的地方：
1） 隊列的DoS攻擊。首先，我們思考一下，這支隊伍是個單純排隊的嗎？這樣做還不夠好，因為這樣我們不能杜絕黃牛，而且單純的ticket_id很容易發生DoS攻擊，比如，我發起N個ticket_id，進入購票流程後，我不買，我就耗你半個小時，很容易我就可以讓想買票的人幾天都買不到票。有人說，用戶應該要用身分證來排隊， 這樣在購買裡就必需要用這個身分證來買，但這還不能杜絕黃牛排隊或是號販子。因為他們可以註冊N個帳號來排隊，但就是不買。黃牛這些人這個時候只需要做一個事，把網站搞得正常人不能訪問，讓用戶只能透過他們來買。
2） 對列的一致性？對這個隊列的操作是不是需要鎖？只要有鎖，性能一定上不去。試想，100萬個人同時要求你來分配位置號，這個隊列將會成為效能瓶頸。你一定沒有資料庫實現得效能好，所以，可能比現在還差。 搶資料庫和搶隊列本質上是一樣的 。
3） 隊列的等待時間。購票時間半小時夠不夠？多不多？要是那時用戶剛好不能上網呢？如果時間短了，使用者不夠時間操作也會抱怨，如果時間長了，後面在排隊的人也會抱怨。這個方法可能在實際操作上會有很多問題。另外，半小時太長了，這完全不現實，我們用15分鐘來舉例：有1千萬用戶，每一個時刻只能放進去1萬個，這1萬個用戶需要15分鐘完成所有操作，那麼，這1千萬用戶全部處理完，需要1000*15m = 250小時，10天半，火車早開了。 （我並非信口開河， 根據鐵道部專家的說明：這幾天，平均一天下單100萬，所以，處理1000萬的用戶需要十天。這個計算可能有點簡單了，我只是想說，在這樣低負載的系統下用排隊可能無法解決業務問題 ）
4） 隊列的分散式。這個排隊系統只有一個隊列好嗎？還不夠好。因為，如果你放進去的可以購票的人如果在買同一個車次的同樣的類型的票（比如某動車臥舖），還是等於在搶票，也就是說系統的負載還是會有可能集中到其中某台伺服器上。因此，最好的方法是根據用戶的需求——提供出發地和目的地，來對用戶進行排隊。而這樣一來，隊列也就可以是多個，只要是多個隊列，就可以水平擴展了。這樣可以解決效能問題，但是沒有解決使用者長時間排隊的問題。
我覺得完全可以從網上購物學習。 在排隊（下單）的時候，收集好用戶的資訊和想要買的票，並允許用戶設定購票的優先級，比如，A車次臥舖買不到就買B車次的臥舖，如果還買不到就買硬座等等，然後用戶把所需的錢先儲值好，接下來就是系統完全自動地非同步處理訂單。成功不成功都發送簡訊或電子郵件通知用戶。這樣，系統不僅可以省去那半小時的使用者互動時間，自動化加快處理，還可以合併相同購票請求的人，進行批次處理（減少資料庫的操作次數）。 這種方法最妙的事是可以知道這些排隊用戶的需求，不但可以優化用戶的隊列，把用戶分佈到不同的隊列，還可以像亞馬遜的心願單一樣，透過一些計算就可以讓鐵道部做車次統籌安排和調整（最後，排隊系統（下單系統）還是要保存在資料庫裡的或做持久化，不能只放在記憶體中，不然機器一down，就等著被罵吧）。
小結
寫了那麼多，我小結一下：
0） 無論你怎麼設計，你的系統一定要能容易地水平擴展。也就是說，在你的整個資料流中，所有的環節都要能夠水平擴展。這樣，當你的系統有效能問題時，「加30倍的伺服器」才不會被人宥笑。
1） 上述的技術不是一朝一夕能搞定的，沒有長期的積累，基本無望 。我們可以看到，無論你用哪一種都會引發一些複雜性，設計總是在做一種權衡。
2）集中式的賣票很難搞定，使用上述的技術可以讓訂票系統能有幾佰倍的性能提升。而在 各省市建分站，分開賣票，是能讓現有系統性能有質的提升的最佳方法 。
3） 春運前夕搶票且票量供遠小於求這種業務模式是相當變態的，讓幾千甚至上億的人在某個早晨的8點鐘同時登錄同時搶票的這種業務模式是變態中的變態。業務型態的變態決定了無論他們怎麼辦幹一定會被罵。
4）為了那麼一兩個星期而搞那麼大的系統，而其它時間都在閒著，有些可惜了，這也就是鐵路才幹得出來這樣的事了。
