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