原文地址：http://blog.csdn.net/qq_21260033/article/details/78969329

讀了幾篇有關12306架構設計的博客,在這里做下簡單的總結:

主要角色:用戶?
主要功能:查詢剩余票數 售票

一 分析業務?
業務復雜點:?
1 庫存集中:所有登錄的用戶訪問的都是數據中心的票據數據?
2 復雜的業務邏輯:還有很多查詢操作，查時間，查座位，查鋪位，一個車次不 行，又查另一個車次，其伴隨著大量的查詢操作，下單的時候需要對數據庫操作。另外，關于秒殺，完全可以做成只接受前N個用戶的請求(完全不操作后端的任何數據， 僅僅只是對用戶的下單操作log)，這種業務，只要把各個服務器的時間精確同步了就可以了，無需在當時操作任何數據庫。可以訂單數夠后，停止秒殺，然后批量寫數據庫。火車票這個豈止是秒殺那么簡單。能不能買到票得當時告訴用戶啊。?
3 數據一致性造成效率瓶頸:訂票系統應該和電子商務的訂單系統很相似，都是需要對庫存進行：1)占住庫存，2)支付(可選)，3)扣除庫存的操作。這個是需要有一致性的檢查的，也就是在并發時需要對數據加鎖的。B2C的電商基本上都會把這個事干成異步的，也就是說，你下的訂單并不是馬上處理的，而是延時處理的，只有成功處理了，系統才會給你一封確認郵件說是訂單成功。我相信有很多朋友都收到認單不成功的郵件。這就是說，數據一致性在并發下是一個瓶頸。?
4 用戶量巨大:春運期間,當票放出來的時候，就會有幾百萬人甚至上千萬人殺上去，查詢，下單。幾十分鐘內，一個網站能接受幾千萬的訪問量，這個是很恐怖的事情。據說12306的高峰訪問是10億PV，集中在早8點到10點，每秒PV在高峰時上千萬。?
5 動態庫存

與淘寶對比:?
淘寶要比B2C的網站要簡單得多，因為沒有倉庫，所以，不存在像B2C這樣有N個倉庫對同一商品庫存更新和查詢的操作。下單的時候，B2C的 網站要去找一個倉庫，又要離用戶近，又要有庫存，這需要很多計算。試想，你在北京買了一本書，北京的倉庫沒貨了，就要從周邊的倉庫調，那就要去看看沈陽或 是西安的倉庫有沒有貨，如果沒有，又得看看江蘇的倉庫，等等。淘寶的就沒有那么多事了，每個商戶有自己的庫存，庫存分到商戶頭上了，反而有利于性能。

優化方案:?
1 服務端處理請求的負載均衡?
通過DNS的負載均衡器(一般在路由器上根據路由的負載重定向)可以把用戶的訪問均勻地分散在多個Web服務器上。這樣可以減少Web服務器的請求負載。因為http的請求都是短作業，所以，可以通過很簡單的負載均衡器來完成這一功能。最好是有CDN網絡讓用戶連接與其最近的服務器(CDN通常伴隨著分布式存儲)?
2 減少前端鏈接數:?
我看了一下12306.cn，打開主頁需要建60多個HTTP連接，車票預訂頁面則有70多個HTTP請求，現在的瀏覽器都是并發請求的。所以，只要有100萬個用戶，就會有6000萬個鏈接，太多了。一個登錄查詢頁面就好了。把js打成一個文件，把css也打成一個文件，把圖標也打成一個文件，用css分塊展示。把鏈接數減到最低。?
3 減少網頁大小增加帶寬?
4 優化查詢:使用noSQL數據庫完成余票查詢 設計如下:?
數據庫的count操作并不快，因此對于繁忙季節的繁忙表，每次都count是鐵定不行的。我想到的一個辦法是：把上面提到的預售車票表加載到內存中。我們用一個64位long類型數字表示一張車票，每趟車的每種座位類型是一個long數組。?
對于每個long數字，前面的32位用來順序存儲32個車站（假設一趟車最多有32個站，沒查過，不行可以放長點），每一位標記“車票是否包含此站”。如G113 濟南到南京的票（車站順序為第3到第5站），long數字的第2到第4位設置為1，其他前32位設置為0。后面的32位用來表示車票在車票出售表中的唯一編號。這樣根據一個long類型數字，我們就能表述一張票的發售信息了。?
比如2012年1月13號G113，有軟臥500張和硬臥1500張。那就需要兩個數組。20120113_G113_軟臥 對應一個長度500的long數組；20120113_G113_硬臥 對應一個長度1500的long數組。存儲所有售票信息。?
有點類似BitSet的感覺，對空間要求不高。我們可以做個系統把所有車票信息按照這種結構加載到內存中。對于實時查票，如查詢2012年1月13號G113車次 濟南->南京 的余票，就是遍歷兩個數組，檢查位數為2和4的long數字有多少個，就直接獲得了軟臥和硬臥的剩余票數。對于現代計算機，這點遍歷，時間是納秒級的。?
當車票被出售后，從long數組中刪除票信息，比如先置為-1表示已經無效。再用后臺線程實際刪除（避免寫沖突，將刪除延遲到重建一個數組所消耗的多少納秒內剛好沒有寫請求的時間段中）。如果long數組長度為0，那就是沒有車票了，直接返回0；用戶再怎么刷，也不會干擾數據庫。?
5 數據鏡像(負載均衡)?
幾乎所有主流的數據庫都支持鏡像，也就是replication。數據庫的鏡像帶來的好處就是可以做負載均衡。把一臺數據庫的負載均分到多臺上，同時又保證了數據一致性(Oracle的SCN)。最重要的是，這樣還可以有高可用性，一臺廢了，還有另一臺在服務。?
6 數據分離:?
主從復制 讀寫分離 分庫分表?
7 硬件云服務?
達到動態分配硬件資源,節省開銷

總結

以上是生活随笔為你收集整理的浅谈12306架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。