透過12306五大焦點看高性能高并發(fā)系統(tǒng)
幽云十八 發(fā)表于：12年02月20日 09:46 [轉(zhuǎn)載] IT168
焦點四：軟件層需要做哪些工作?
軟件層將直接決定整個系統(tǒng)應對高并發(fā)的能力，其將應用服務器與數(shù)據(jù)庫、存儲結(jié)合成為一個有機的整體，使數(shù)據(jù)在這些IT設備之間傳輸，可以說軟件層做得好與不好可能性能差異能達幾倍到一個量級。那么在以高并發(fā)為前提的情況下，軟件層要做什么呢?
百度首席架構(gòu)師林仕鼎認為在解決請求尖峰時可采用threadpool或event-driven兩種做法。這兩種做法都需要自己維護請求隊列，也帶來了提高穩(wěn)定性的可能性。簡單地說，就是增加flow control機制，上游根據(jù)下游的負載做throttling，反饋可以有ack/poll等多種做法，有時需要由最下游一路反饋到最前端。并采用延遲截斷，對于太老的請求，直接給出拒絕響應，讓它在應用層重試。
4399架構(gòu)師曹政則提供了更多更具體的方式，他認為可將存儲key- value化，因為基本上查詢都是直線式的，所以key-value就是很好的工具;因為出票可能需要找一下車次，座位，只能一一對應的查詢就不好用;弄 個redis帶個列表結(jié)構(gòu)進去就可以了。春節(jié)放票總共多少張?又不是一次放出來，每張票對應一個key，一個value，能吃多少內(nèi)存?后面跟個數(shù)據(jù)庫做 同步，這點數(shù)據(jù)量對于現(xiàn)在的服務器來說根本不是問題。并且在注冊登陸也可以在 mysql基礎(chǔ)上弄個redis掛在前頭響應以提高查詢速度。
實際上，在12306在線購票系統(tǒng)中，查詢操作是很常見，因為你需要查詢車次，還需要查詢余票。基于這點，曹政認為可將查詢結(jié)果緩存化、靜態(tài)化，這可通過兩個步驟實現(xiàn)，起始地，目標地查詢 - 常見查詢目標(如北京到成都)全部預制緩存。非常見查詢目標，基于第一次查詢的結(jié)果緩存，這樣查詢車次基本上無壓力。
查詢有票狀態(tài)就更簡單了，因為票數(shù)只有有票，無票兩個狀態(tài)，某日某車次作為一個key-value類型存儲(仍用redis即可)。某類車票發(fā)生從 有到無或從無到有的變化，才通知緩存更新。更新是后臺通知的，而非基于用戶查詢。比如某車次硬臥票售完，通知一次更新，硬座售完，通知一次更新，軟座售 完，通知一次更新。以此類推，這樣的緩存更新次數(shù)極少。而且可以給前端返回甚至靜態(tài)結(jié)果(基于查詢條件生成靜態(tài)結(jié)果，是個Seoer都會的，后臺在票數(shù)變 化時通知更新，這樣結(jié)構(gòu)上就與前端查詢無關(guān)了，而且一樣可以保持實時性)。
最后還可對前端緩存進行處理來提高響應速度�？赡艽蠖鄶�(shù)人都被10億PV給嚇到了，但實際上這里面有很大的水分，因為有很多可能是利用代碼或者腳本 進行的自動刷新，自然而然就會產(chǎn)生較大的泡沫，而實際上絕對不會有那么多�；谶@點，則可通過緩存來避免“爆機”，并且有例子證明，這樣做的效果是能夠應 對一小時20億的刷新，12306的10億刷新根本就不成問題。
當然，網(wǎng)上的各種關(guān)于軟件層的建議還有很多很多，包括之前提到的云風的排隊系統(tǒng)也應該屬于軟件層的內(nèi)容，因為篇幅的原因，在此我們僅選取了幾個較為典型的建議。
