欢迎来到天天文库
浏览记录
ID:19906947
大小:52.50 KB
页数:6页
时间:2018-10-07
《关于一个大型web系统架构设计和技术选型的讨论摘录》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、关于一个大型web系统架构设计和技术选型的讨论摘录2007年09月13日星期四上午09:36一、1、数据库压力问题 所有的压力最终都会反映到数据库方面,一定要对数据库有一个整体的规划。 可以按照业务、区域等等特性对数据库进行配置,可以考虑分库、使用rac、分区、分表等等策略,确保数据库能正常的进行交易。 2、事务问题 你采用了两种类型数据库,一个SQLServer、一个oracle,如果一个交易需要在两个数据库中操作,那么必须考虑到分布式事务,你应该仔细的设计你的系统,来避免使用分布式事务,以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提
2、交的策略(并不保证数据的完整),来避免分布式事务的问题,毕竟commit失败的几率很低。(某个超大型系统,有3套数据库,也是采用的延迟提交策略,避免分布式事务带来的对数据库过大的压力)。 看到了你在应用前端(weblogicEJB)采用了F5,我个人不是很赞同这个方案,虽然F5是一个好的L4产品,也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB,如果采用了这种方案,把不需要使用分布式事务的交易变成了分布式交易,试想,一个web如果在一个请求中,访问了后端两个EJB,那么L4就会有可能把请求分发到不同的服务器上,没有对事务维持在一个服务器中,就不
3、能使用本地事务。同样,一个web,访问后端一个请求,这个请求中需要3个EJB,那么极有可能把这3个请求分发到不同的服务器,又造成了分布式事务。weblogic是一个好的J2EE产品,对这种有事务关联的负载均衡,它会优先考虑采用一个服务器里面的应用,这样就采用了本地事务,提高了响应速度,减小了分布式事务对应用和数据库的压力。 3、web的优化 我个人认为,一个商业的应用,硬件的投资可能不是主要的瓶颈,往往可维护性,可扩展性是最主要的问题。 没有必要采用不成熟的方案,要更多的使用成熟的方案,将静态、图片独立使用不同的服务器,对于常态的静态文件,采用E-TAG
4、或者客户端缓存,google很多就是这样干的。对于热点的功能,考虑使用完全装载到内存,保证绝对的响应速度,对于需要频繁访问的热点数据,采用集中缓存(多个可以采用负载均衡),减轻数据库的压力,比如:很多配置信息,操作员信息等等。 对了,对于几乎除二进制文件,都应该在L4上配置基于硬件的压缩方案,减少网络的流量。提高用户使用的感知。 4、网络问题 你不可能要求所有的使用人员,都和你的服务器在一个运营商的网络内,可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资,可以采用CDN(内容分发网),减轻你的服务器压力。二、F5的负载均衡是必不可少
5、的,他的每秒点击量能达到将近30万,并且它有会话的粘性,只要是同一个ip发过来的请求,它就会把它分到同一台机器的,不用担心分发错误的。现在的问题是apache和tomcat的能力不平衡,动态的内容压力太大,不是数据库的压力,我们的数据库 oracle是RAC群集。性能很好三、tomcat为什么死掉?当时CPU或者内存的占用率是多少?看看其中JVM占用了多少?有没有OOM的错误?不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。把缓存做好,减少动态查询四、1、F5的使用 F5不光可以做web的负载均衡
6、,也可以做基于第4层的负载均衡。 比如:银行接口,大部分基于socket通讯的,就可以在前面架设一套F5设备,将请求分发到不同的服务器上。 大部分使用F5都是在web层次上,如果使用基于源IP地址的策略,有很多客户端都是基于代理服务器,这个时候源IP地址是一样的,其实并没有把这些用户给分发到不同的服务器上,建议采用基于cookieinsert的方式,采用cookie的会话保持策略,loadbalance的算法,需要仔细的结合自己的应用的实际情况来设置。2、大并发的问题 现在你得到了一个大概的系统能承受的并发,但是还达不到系统的设计目标。 应该从应用的角度
7、去分析这个问题,web方面,通过工具(httplook),检查一下客户端发起的请求都是什么响应状态,如果看到很多304请求状态,你需要优化你的url缓存,看一下每个url的耗费时间,仔细针对比较慢的进行调优;对于tomcat或者weblogic,在高并发的情况下,用kill-3,获得ThreadDump(HeapDump需要特殊的设置),看一下在高并发下,jvm的线程到底在干什么,仔细的分析可能对你有帮助。 如果在这些还没有改善的情况下,应当去想一想,硬件是否足够、配置是否合理等等系统级别的问题。五、似乎在说瓶颈在于tomcat并发承载能力不够
8、,但为什么tomcat只能承担单机200个并发?当并发急剧上升的时候,tomca
此文档下载收益归作者所有