在路上

集群開始：(第一張圖，為集群策略圖)

選擇創(chuàng)建新域配置，按順序分別配置做如下配置： 管理服務器、被管理服務器、CLUSTER、MACHINE、JDBC POOL、JNDI。

1.Cluster，管理服務器與被管理服務器的配置不在這里贅述，注意將配各服務器拖入cluster，設置正確的ip/port等。

2.上面的列表是DomainA的配置設置情況，注意內存分配和線程分配，需要根據(jù)自身的應用情況，進行合理設置。這里是各個server共享weblogic server的內存設置

初始=2.4G  最大=4G。對jvm參數(shù)設置進行優(yōu)化，也可以起到間接優(yōu)化weblogic server的作用。jvm的優(yōu)化可以參考java相關文檔。至于執(zhí)行線程數(shù)，需要結合自身業(yè)務情況，具體分析設置。

3.JDBC POOL 設置，初始=10，增長=5，最大=50(一般性的應用，應該夠了)。如果使用Oracle RAC數(shù)據(jù)庫，建議使用mutipool,需要注意選擇池的機制：  load_banlance還是High availability。

   這兩種算法的區(qū)別如下：

   假設有兩個poolA和poolB

     load_banlance機制會將壓力均衡分布在兩個池上。由于負載均衡，雙雙宕機的幾率相對降低。

       High availability機制,正常的情況下,只有一個PoolA起作用,其poolB是stand-by,當起作用的那個poolA出現(xiàn)故障,則會被 WLS標記為disable,并將請求轉發(fā)到另外一個poolB上,并且定時測試被標記為disable的poolA,如果重新連接成功后,則將請求再切 換回PoolA上,PoolB繼續(xù)stand-by.

  相對于load_banlance，High availability對單機的負擔較大，但當有一個節(jié)點A宕機后，weblogic會將數(shù)據(jù)連接切換到節(jié)點B上。

  至于如何選擇，根據(jù)自身業(yè)務特點來選擇。

 案例：如果RAC 是2個節(jié)點，也就是2個數(shù)據(jù)庫實例，并且每個實例上有不用業(yè)務單元的表。假設有2個應用，將A應用的master庫設為節(jié)點A的DB,slave為節(jié)點B 的DB；應用B的設置正好相反。此時選擇High availability機制比較好。原因是：RAC  以Cache 同步為代價實現(xiàn)Cluster。在Cache Fusion 中，最大的消耗有兩處：
    －  鎖通知。這是無論如何我們也控制不了的，好在它的消耗不是最大的；
    －  Cache  內的數(shù)據(jù)同步。如果RAC  實例間不訪問同樣的數(shù)據(jù)塊，這一消耗是可以回避的。這一點我們能做到，而且，它是 Cache Fusion 的最大消耗者。回避的辦法就是像現(xiàn)在
這樣：讓不同的實例支撐不同的業(yè)務單元，前提是這兩個業(yè)務單元的表幾乎沒有交叉。

4. 可以在weblogic server之上加入一層代理服務器(apache)，用于處理靜態(tài)文件如圖片、js文件等。至于動態(tài)應用當然全權交給weblogic。