高性能併發系統架構應該如何設計？關鍵是什麼？12306

範凱    寫道

高性能併發系統其實分不少種類，是併發讀，併發寫，併發長鏈接，仍是併發事務？不一樣類型的架構設計是不一樣的。具體到12306就是併發事務，在這個領域，我我的沒有什麼經驗。

陳雄華    寫道

1)  優化前端網頁

• 充分利用CDN，使JS、圖片等靜態資源的請求可以就近訪問（順便說一下，若是12306訂票插件能從google提供的http://cdnjs.com中引用JS，而不去直接引用github的JS，就不會把github搞癱了）。
• 將JS、CSS合併，最小化請求數。將JS和CSS壓縮，最小化數據傳輸
• 啓用gzip壓縮網頁。

2)  羣集分發和調度

聽說12306是採用集中式構架的，集中式構架很難應對高併發，也很難水平擴容，分佈式不是僅僅將調度服務器，應用服務器，緩存服務器，數據庫服務器分開就行，應該進行更細的服務級劃分，對業務進行服務細分，作成一個個鬆散耦合的服務，而後把這些服務獨立分佈式部署。

3)  採用分佈式會話

爲了能夠進行靈活的請求調度，不該採用weblogic、websphere這些應用服務器自身的session管理用戶會話，而應該本身管理會 話，如將會話保存在獨立的集羣memcached服務器中，這樣每一個應用服務就都無狀態了，會話的請求能夠隨意分發給不一樣的服務器。這也是個人ROP開源 項目沒有使用HttpSession，而專門抽象出一個SessionManager接口的緣由，開發者應該本身去實現這個接口實現分佈式會話管理。

4)  關於數據庫設計優化

數據庫每每是系統瓶頸所在，首先應該對數據庫進行分庫設計，可採用兩級水平切割，如首先切割成幾個物理庫，而後在物理庫內部再採用表分割，通常是經過某個業務ID進行取模切割，下降單庫及單表的併發性，提升TPS。

合理採用讀寫分離技術，作到讀寫分離，能夠一寫多讀，有效下降數據庫的負載，數據的同步能夠視狀況採起應用層同步寫，讀取數據庫日誌更新或直接使用mysql讀寫分離技術等。

此外，業務服務化、服務解耦化是關鍵。

runfriends（來自論壇回覆） 寫道

我的認爲針對不一樣的系統要有不一樣的設計方案。 雖然12306能夠歸類爲電商領域，可是跟一般意義上的B2C仍是有巨大的差別。因此單純從12306上面討論高性能併發系統架構並無通用意義。 不過，有一個思想應該貫徹。那就是全部訪問力求分散到不一樣的服務器處理，不一樣類型的資源要堅持使用不一樣的集羣服務。動靜分離、讀寫分離，減小一次 頁面訪問的請求數和數據庫訪問次數，保持小事務粒度，注意線程安全，避免大數據量的查詢，創建索引（多表聯合、union、非參數化sql、笛卡兒積計 算、返回大數據集等數據庫操做應該避免）。 對於變化較小的查詢操做可將查詢工做交給專門的索引服務器完成。不過我的感受像12306這樣的業務，引入索引的意義不大也沒有必要。 12306的業務需求乍一看彷佛都是同一類型的資源，可是咱們可能根據車次、臥、軟、硬、站、時段、線路等信息將車票這個12306要處理的唯一類型的資源分紅若干子類，不一樣的子類請求由不一樣的集羣處理。