在路上

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

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

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

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

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

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

   這兩種算法的區別如下：

   假設有兩個poolA和poolB

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

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

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

  至于如何選擇，根據自身業務特點來選擇。

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

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