【轉】12306系統架構優化

coolshell陳皓優化方案
原文：http://coolshell.cn/articles/6470.html
1、業務複雜度比對
（1）qq業務模型：只訪問本身的數據
（2）秒殺業務模型：秒殺可以只接受前N個請求，後續請求直接返回
（3）奧運會售票業務模型：註冊+抽獎，非先來先搶，能夠過後線下處理
（4）電子商務業務模型：c2c只需關注本身的庫存
結論：庫存是b2c的噩夢，12306業務與之相似

2、瓶頸
庫存業務的操做模式基本是這樣的：
1）佔住庫存
2）付款
3）扣除庫存
這個過程當中，是要對數據進行加鎖的，高併發下數據的一致性保證很是之難。
併發究竟有多大呢？
12306的業務特色是，忽然放票，你們去搶。幾十分鐘內，立刻幾千萬的訪問量，很是恐怖（聽說高峯訪問是10億PV，集中在早上8點到10點）。
結論：高併發下數據一致性是12306的痛點

3、前端優化
（1）負載均衡：DNS+CDN；
（2）減小頁面連接數：減小瀏覽器http併發鏈接，合併js，合併css，合併圖標
（3）減小頁面大小：帶寬有限，壓縮，分離圖片服務
（4）頁面靜態化：同一時間查詢相同車次的結果頁面都是同樣的，甚至可將靜態化的文件放入/dev/shm下
（5）查詢優化：票務結果顯示「有/無」，而非具體數字，能大大簡化邏輯
（6）前端緩存：直接緩存動態頁面

4、後端優化
（1）數據冗餘：一個數據能夠冗餘存在多個表裏，代價是一致性
（2）數據鏡像：replication，仍然有一致性問題
（3）數據分區：分庫，分表，分字段
（4）負載均衡：靜態分流，動態分流
（5）異步化、throttle（節流，通常須要排隊）、批量處理

5、總結
不管如何，系統必定要能水平擴展，加機器能提升性能。

雲風的BLOG優化方案
原文：http://blog.codingnow.com/2012/01/ticket_queue.html
1、核心思想：排隊論，餐館裏拿到號的人才能進來吃飯

（1）生成一些簽名過的「號」給排隊者（「號」不可僞造）
（2）一個32G大數組，循環隊列，將「號」放入隊尾，並hash記錄「號」在隊列中的index
（3）利用一次hash查詢，由index和head可知排隊者前面有多少人
（4）若是排隊者前面沒有人了，好吧，給你個簽名過的session，進去吃飯吧（「session不可僞造」）

2、注意點
（1）刷「號」也是沒用的，不能讓你提早
（2）拿到「號」的人心切呀，急於知道他前面排了多少人，便反覆查詢，反覆查詢，能夠設定閾值，查詢頻率太高，則「票」做廢，這樣以下降你們查詢的頻率
（3）session有有效期，拿到session不去吃飯，從新排隊

3、總結
（1）拿到session後才能走正常購票流程，此時性能已經不是瓶頸，大不了多開幾個窗口，不正確或者超時的session立馬能夠斷掉
（2）排隊由「號」拿session能夠精確控制真正進入系統的流量，而排號的系統又是內存的高性能簡流程操做
（3）排隊的人只要看到本身前面的人公平的在減少，也會安心等待

曹政的和諧blog優化方案
原文：http://hi.baidu.com/ncaoz/item/9bdefa308f1bb7f3e7bb7a84
（ SK注：caoz同窗很自信，2人2周，40臺服務器搞定，你們一塊兒看下他的方案）
1、業務抽象
（1）車次查詢+餘票顯示，日均10億PV，這是主要矛盾
（2）註冊登陸，日均幾千萬PV
（3）下單，日均幾百萬PV
不涉及複雜的關係操做，不涉及推拉結構、不涉及革新展現。

2、優化方向
（1）存儲KV化，例如redis：基本全部查詢都是直線式的，能夠用redis的集合或者列表搞定
（2）後端查詢結果緩存化：
2.1）緩存符合要求的車次
2.2）緩存餘票
2.3）緩存有票/無票狀態
（3）前端緩存+防刷
（4）IO優化，幾百萬的訂單而已

3、總結
緩存（查詢結果靜態化）是整個優化方案的核心
這個手段極其適用於符合這兩個要求的場景：
（1）查詢頻率遠大於更新頻率
（2）全部用戶在同一時間查詢同一條件，返回結果都相同

4、引文
caoz在上文中引用了「楊建」網站Cache加速的文章，
楊建的BLOG-「網站加速-Cache爲王」連接以下：
原文：http://blog.sina.com.cn/s/blog_466c66400100bi2y.html

SK我的感受，雲風的「排隊論」優化簡單可信。