1.原始查詢系統描述
查詢系統的數據庫是2節點的RAC，中間件是24臺weblogic服務器做集羣，前端是負載均衡器，如圖：
2.存在的問題
每天業務高峯期weblogic中間件頻頻宕機，後端的2節點RAC數據庫已經難以承載現今的併發量，大量阻塞線程堆積在weblogic中間件上，具體問題如下：
1) Adminserver 壓力過大，集羣中被管服務器太多，在業務高峯期監控受阻。
2) 數據庫的承載能力過小，使得調用JDBC的服務嚴重受阻。
3) 集羣承載能力有限，無法完成高併發。
4) 絕大多數被管服務器在業務高峯期處於過載的狀態，宕機現象一直髮生。
5) cpu資源沒有合理利用，單顆CPU（加載weblogic的那顆）業務高峯期壓力很大能到100%，其他cpu處於空閒狀態。
3.新一代查詢系統方案
根據原查詢系統存在的問題，我們將weblogic中間件層做擴容，由原系統的單一weblogic集羣擴充至六套集羣，每個集羣中部署8個weblogic服務器，每臺物理機器部署2個weblogic，如圖：
相關設置：
1) 設置weblogic過載保護：將每個weblogic 等待和執行的線程數之和設置爲500
（即 shared capacity for work manager）。
2) 設置weblogic阻塞線程診斷：診斷阻塞線程的時間間隔爲60，容忍阻塞的線程數爲200。
3) 設置weblogic JDBC連接數：每個連接池設置連接數爲50，這樣系統能夠承載：50*2*（48-6）=4200個JDBC併發連接。
4.方案綜述：
1) 能夠支持21000人併發連入系統，計算：500*（48-6）=21000
2) 能夠支持4200人併發查詢數據庫，計算：50*2*（48-6）=4200
3) 爲保證系統的穩定運行，利用weblogic的過載保護，合理的設置weblogic的承載上限
4) 縮短阻塞線程的診斷時間間隔，早治療早康復。
5) 利用多集羣的模式，合理的減少了集羣中被管服務器的數量，從而降低AdminServer管理，監控集羣的壓力。
6) 易於水平擴展，直接增加集羣的數量就能夠增加系統負載能力，當然數據庫也要相應的調整。
5.對數據庫的要求：
能夠支持4200的併發讀寫，若還爲2節點的RAC，那麼每個節點的processes得大於等於2500。
6.方案不確定的因素：
1) 每臺物理機器上的2個weblogic是否能夠做到各佔用一個cpu。
2) 每個weblogic承受500的併發連入（等待+執行的），這樣的多線程，客戶的cpu能否合理的承受壓力。