在路上

集群开始：(第一张图，为集群策略图)

选择创建新域配置，按顺序分别配置做如下配置： 管理服务器、被管理服务器、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。