高并发weblogic集群

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能否合理的承受压力。