coolshell陳皓優化方案
原文：一、業務複雜度比對
二、瓶頸
庫存業務的操作模式基本是這樣的：
1）佔住庫存
2）付款
3）扣除庫存
這個過程中，是要對資料進行加鎖的，高併發下資料的一致性保證非常之難。
併發究竟有多大呢？
12306的業務特點是，突然放票，大家去搶。幾十分鐘內，馬上幾千萬的訪問量，非常恐怖（據說高峰訪問是10億pv，集中在早上8點到10點）。
結論：高併發下資料一致性是12306的痛點
三、前端優化
（1）負載均衡：dns+cdn；
（2）減少頁面鏈結數：減少瀏覽器http併發連線，合併js，合併css，合併圖示
（3）減少頁面大小：頻寬有限，壓縮，分離服務
（4）頁面靜態化：同一時間查詢相同車次的結果頁面都是一樣的，甚至可將靜態化的檔案放入/dev/shm下
（5）查詢優化：票務結果顯示「有/無」，而非具體數字，能大大簡化邏輯
（6）前端快取：直接快取動態頁面
四、後端優化
（1）資料冗餘：乙個資料可以冗餘存在多個表裡，代價是一致性
（2）資料映象：replication，仍然有一致性問題
（3）資料分割槽：分庫，分表，分欄位
（4）負載均衡：靜態分流，動態分流
（5）非同步化、throttle（節流，一般需要排隊）、批量處理
五、總結
無論如何，系統一定要能水平擴充套件，加機器能提高效能。
雲風的blog優化方案
原文：一、核心思想：排隊論，餐館裡拿到號的人才能進來吃飯
（1）生成一些簽名過的「號」給排隊者（「號」不可偽造）
（2）乙個32g大陣列，迴圈佇列，將「號」放入隊尾，並hash記錄「號」在佇列中的index
（3）利用一次hash查詢，由index和head可知排隊者前面有多少人
（4）如果排隊者前面沒有人了，好吧，給你個簽名過的session，進去吃飯吧（「session不可偽造」）
二、注意點
（1）刷「號」也是沒用的，不能讓你提前
（2）拿到「號」的人心切呀，急於知道他前面排了多少人，便反覆查詢，反覆查詢，可以設定閾值，查詢頻率過高，則「票」作廢，這樣以降低大家查詢的頻率
（3）session有有效期，拿到session不去吃飯，重新排隊
三、總結
（1）拿到session後才能走正常購票流程，此時效能已經不是瓶頸，大不了多開幾個視窗，不正確或者超時的session立馬可以斷掉
（2）排隊由「號」拿session可以精確控制真正進入系統的流量，而排號的系統又是記憶體的高效能簡流程操作
（3）排隊的人只要看到自己前面的人公平的在減小，也會安心等待
曹政的和諧blog優化方案
原文：（ sk注：caoz同學很自信，2人2周，40臺伺服器搞定，大家一起看下他的方案）
一、業務抽象
（1）車次查詢+餘票顯示，日均10億pv，這是主要矛盾
（2）註冊登入，日均幾千萬pv
（3）下單，日均幾百萬pv
不涉及複雜的關係操作，不涉及推拉結構、不涉及革新展示。
二、優化方向
（1）儲存kv化，例如redis：基本所有查詢都是直線式的，可以用redis的集合或者列表搞定
（2）後端查詢結果快取化：
2.1）快取符合要求的車次
2.2）快取餘票
2.3）快取有票/無票狀態
（3）前端快取+防刷
（4）io優化，幾百萬的訂單而已
三、總結
快取（查詢結果靜態化）是整個優化方案的核心
這個手段極其適用於符合這兩個要求的場景：
（1）查詢頻率遠大於更新頻率
（2）所有使用者在同一時間查詢同一條件，返回結果都相同
四、引文
caoz在上文中引用了「楊建」**cache加速的文章，
楊建的blog-「**加速-cache為王」
鏈結如下：
原文：sk個人感覺，雲風的「排隊論」優化簡單可信。
12306購票系統後端優化
後端效能優化技術 前面討論了前端效能的優化技術，於是前端可能就不是瓶頸問題了。那麼效能問題就會到後端資料上來了。下面說幾個後端常見的效能優化技術。一 資料冗餘 關於資料冗餘，也就是說，把我們的資料庫的資料冗餘處理，也就是減少表連線這樣的開銷比較大的操作，但這樣會犧牲資料的一致性。風險比較大。很多人把...
12306的優化思考
一 場景分析 1 平時訪問量不高，但是春運幾天會出現瞬間高峰 2 訂單的事務性要求較高 3 全國開放，並且票數要精準 4 瞬間訪問量大 二 調優可行性方案 1 資料層次 請使用oracle，在資料穩定性以及千萬級別的資料量上還是比較有保障 2 cache層次 3 前端處理 4 業務層次 5 事務處理...
單點系統架構的優化
明明架構要求高可用，為何系統中還會存在單點？回答 單點master的設計，會大大簡化系統設計，何況有時候避免不了單點 在哪些場景中會存在單點？先來看一下乙個典型網際網路高可用架構。典型網際網路高可用架構 2 負載均衡層，nginx是整個服務端的入口，負責反向 與負載均衡工作 3 站點層，web se...