请教大型WEB系统的架构设计和技术选型

目前系统架构如下:
  1.web层采用struts+tomcat实现,整个系统采用20多台web服务器,其负载均衡采用硬件F5来实现;
  2.中间层采用无状态会话Bean+DAO+helper类来实现,共3台weblogic服务器,部署有多个EJB,其负载均衡也采用F5来实现;
  3.数据库层的操作是自己写的通用类实现的,两台ORACLE数据库服务器，分别存放用户信息和业务数据;一台SQL SERVER数据库,是第三方的业务数据信息;
  web层调用EJB远程接口来访问中间件层.web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口;
  该系统中一次操作涉及到两个ORACLE库以及一个SQL SERVER库的访问和操作,即有三个数据库连接,在一个事务中完成.

  以上的描述不知道是不是足够清楚,目前想采用业界流行的一些框架来重新架构整个系统,请各位高手分析一下,这样的系统能不能采用struts+spring+hibernate框架来实现,如果可以的话，其中的多个数据库的连接、事务控制、负载均衡都如何实现，或者有其他更好的技术来架构系统？谢谢！

评论

56 楼 robbin 2007-09-04  

引用

2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户......
......
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。

这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：

1、你的tomcat没有配置好，严重影响了性能表现
2、tomcat和weblogic之间的接口出了问题

上面的帖子其实我也介绍过了，如果只是单纯的作为servlet容器来看，tomcat的性能不应该比weblogic差，甚至还要更好，所以你可以这样来拟定测试方案：

在同样硬件环境下对比测试tomcat5.5和weblogic10的servlet容器性能，分别写几个访问数据库，和不访问数据库的JSP页面测试就可以了，并发从500往上走，看看哪个throughput更高。记得要调优tomcat5.5，配置apr支持要打开。

如果测试结果表明tomcat并发响应能力远远差于weblogic，那就说明你的tomcat配置有很大的问题，好好钻研tomcat configuration && performance tuning吧；

如果测试结果表明tomcat并发响应能力与weblogic相当，或者差不多，那么很不幸，问题不在tomcat本身，而是出在了tomcat到weblogic的接口上。而tomcat是通过weblogic提供的EJB client jar去调用weblogic的EJB的，那你只好咨询BEA去寻求解决方案了。

55 楼 robbin 2007-09-04  

坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。阿里巴巴和淘宝网那是每天多少亿PV的电子商务网站了，其实也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本质上还是在用tomcat。

今年年初，RedHat在深圳的HW大客户在内部做过性能对比评测，JBoss4 vs WebLogic 9，在web容器一项的评测当中，JBoss4胜出。这个结果并不令人感到意外，因为web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。这一点你只要对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。

从你上面的发言来看，你们之所以采用EJB，无非是因为经费有限，无法购买充足的weblogic license。所以退而求其次，购买少量的weblogic license，专门跑业务层服务器，用SLSB暴露远程接口给tomcat调用。然后部署n十多台免费的tomcat服务器跑web。为省钱而采用EJB到是一个很新鲜的事，但实际上这就是一个很愚蠢的决定。

weblogic的优秀更多的体现在他对于J2EE标准优秀的支持，各种复杂的企业应用场景以及传统的中间件应用的丰富而方便的集成手段上。简单的来说，就是weblogic/websphere是企业应用的首选，特别是强调事务的企业应用，例如金融，电信计费。但在互联网应用方面，weblogic/websphere根本就体现不出有什么能够超过resin/tomcat的地方，诚然weblogic express的web容器稳定性要好于tomcat，但没有互联网企业在大规模部署tomcat水平群集的时候，还会为这一点而疯狂买单购买weblogic license。

所以我个人很不理解，作为一个互联网公司的CTO，怎么会如此迷信weblogic，因为我认识的互联网公司高层，没有什么人愿意用商业产品，绝大多数都是用开源的，我不惮揣测他的背景可能来自传统企业应用出身的吧，呵呵。

54 楼 davexin 2007-09-04  

robbin 写道

performance tuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。从上面这么多讨论当中，还不能很清晰的看出来这一点。从davexin某贴的内容：

引用

我们现在的问题是apache和tomcat的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库oracle是RAC群集。性能很好，不用担心。

来看，似乎在说瓶颈在于tomcat并发承载能力不够，但为什么tomcat只能承担单机200个并发？当并发急剧上升的时候，tomcat在执行动态请求的时候，瓶颈在哪里？是哪部分程序，或者哪个环节首先导致tomcat失去响应的？在davexin描述的刀片硬件上面，tomcat上面如果跑的仅仅是最简单的jsp页面，在采用BEA JRockit JVM的情况下，500个并发也可以达到。

我的推测是瓶颈还是出在EJB远程方法调用上！

tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。

如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。

另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。

谢谢你的建议，我会再测试一下tomcat和weblogic之间调用的时间远程调用的时间问题，看看tomcat的performance 能不能再提高一些。今天bea的人向我们推荐了一款他们收费的java虚拟机，他们声称具有在长时间运行时会有更好的性能，问他们为什么他们这款虚拟机性能更好，他们说是对java 的垃圾回收做了优化。
由于时间比较紧，还没来的及对测试，但是我感觉她的性能也好不到哪里去，不过我们测试的时候也对他们的JRockit 作了测试，和sun的jvm做对比，但优势并不明显。bea他们自己说以前在浙江的测试结果确实JRockit 比sun 好一些，但是我们这几天没有测试到这样的表现，也可能我们现在测试还有待改进。欢迎提出建议。

53 楼 davexin 2007-09-04  

bluemeteor 写道

davexin 写道

tomcat就不响应了。就像死了一样。

tomcat为什么死掉？当时CPU或者内存的占用率是多少？看看其中JVM占用了多少？有没有OOM的错误？不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。

BTW：国内还有这么火的游戏运营商么？我觉得只有WEB游戏才会达到楼主所描述的峰值访问，火一点的网游很难到达这种情况，总不会是网易吧，但是网易用了100多台服务器……

确实还有这么火的游戏，但不是网易，如果有时间的话，可以私下交流。

52 楼 davexin 2007-09-04  

感谢robbin和各位的热心回答。

近段时间正在做购买新硬件和新软件的预算，公司高层准备买weblogic10和oracle 10g，所以请了bea公司的人员和我一块做测试，经过近几天的测试，测试一下新的系统指标1万个并发，需要多少软件和多少硬件能够支撑，已经测试了不同的组合方式，有了不同的结果，分别如下：

1。1台weblogic10  能支持900个用户并发（没有用ejb），平均响应时间 10秒。

2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户，平均响应时间9秒，由于本人使用的loadRunner最多支持1000个web并发，虽然此时weblogic没有任何错误，但是没办法再向上压用户，所以不知道最高能支撑多少个并发用户，很遗憾。

3。1台weblogic8， 能支持900个用户并发（没有用ejb），平均响应时间 11秒。但是没有weblogic10在同样时间内处理的交易数量多。可以判定性能不能weblogic10。

4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。

5。1台tomcat6.14加1台weblogic8，还不如方案4，tomcat结超时更多，说明此种结构瓶颈在tomcat。由于还没有看tomcat6.14的调优资料。所以还请高手给建议。

6。1台tomcat4.1加1台weblogic10，性能同样不佳，问题出现在tomcat性能跟不上。

7。1台tomcat6.14加1台weblogic10，性能同样不佳，问题出现在tomcat性能跟不上。

明天还要做一个weblogic10 cluster测试，等有了测试结果，再根大家交流。

以上测试机器都为 linux as4 操作系统，2cpu + 2G内存，发现cpu利用率最高占45%，一般就在10%左右，内存可以用到1.5G。 loadRunner机器为2cpu + 2G内存，window server 2003操作系统。

有以上的结果，bea公司人员建议购买16-20cpu的licens。机器购买4cpu + 8G内存机器4-6台。前端tomcat增加到50台。

由于根据以前的宕机记录，主要表现在tomcat层，个别高峰时候也出现在F5。故不敢轻易的舍弃无状态session bean。由于tomcat做了大部分的业务，只有需要数据库的时候才调用weblogic中间件，由于weblogic的价格还是比较昂贵的，公司以前购买的weblogic licens数量限制。所以还不能把所有的tomcat换成weblogic。如果有20台weblogic的licens，我也就不担心1万个并发了。

51 楼 ahuaxuan 2007-09-04  

从前面反映的情况来看，我觉得robbin大哥的分析非常有道理，tomcat之所以并发低很可能是由于remote session bean造成的，remote session bean又一次被滥用了，在楼主的这种

业务情况下，web层和service层根本不需要分开，象楼主这样分开带来就是一访问业务层就带来长时间的远程请求，确实导致tomcat上servlet资源释放的问题。

那么remote session bean应该被用在什么地方呢，without ejb上有写到金融系统常用ejb。我把他的这句话延伸一下，也就是说当业务的运行时间远超过远程调用的时间时，我们

就可以用remote session bean来把这个业务分离出去。而楼主的系统中没有这种业务情况。所以使用remote session bean应该来说是一个错误的选择，不过这个错误的选择带来

的危害被大量的硬件所掩盖，带来的是成本的提高。而性能上还不如slsb。

所以我觉得如果要改架构最便捷的方法是使用slsb，把remote session bean去掉。这样改造的成本比较低，如果换成spring+hibernate成本就高得多了。也就是说可以

struts+Bean+DAO+helper，然后把weblogic作cluster，任意一个node上都部署相同的应用。也就是水平扩展，理论上来讲当性能不满足要求时添加node就行了，如果能做成农场就

更加方便了。当然即使非农场也没有关系，可以用现在在使用的stick分发。

这样的改造之所以方便是因为把remote session bean改成slsb是很容易的，而且团队里的人估计对ejb都更加熟悉一点，成本会比较低一点。

50 楼 chenqj 2007-09-04  

分布式并不可怕
对于读远大于写的应用，web端的缓存非常重要

49 楼 robbin 2007-09-04  

performance tuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。从上面这么多讨论当中，还不能很清晰的看出来这一点。从davexin某贴的内容：

引用

我们现在的问题是apache和tomcat的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库oracle是RAC群集。性能很好，不用担心。

来看，似乎在说瓶颈在于tomcat并发承载能力不够，但为什么tomcat只能承担单机200个并发？当并发急剧上升的时候，tomcat在执行动态请求的时候，瓶颈在哪里？是哪部分程序，或者哪个环节首先导致tomcat失去响应的？在davexin描述的刀片硬件上面，tomcat上面如果跑的仅仅是最简单的jsp页面，在采用BEA JRockit JVM的情况下，500个并发也可以达到。

我的推测是瓶颈还是出在EJB远程方法调用上！

tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。

如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。

另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。

48 楼 cauherk 2007-09-04  

这个帖子是技术贴，所以仅仅讨论技术问题。

1、F5的使用
F5不光可以做web的负载均衡，也可以做基于第4层的负载均衡。
比如：银行接口，大部分基于socket通讯的，就可以在前面架设一套F5设备，将请求分发到不同的服务器上。
大部分使用F5都是在web层次上，如果使用基于源IP地址的策略，有很多客户端都是基于代理服务器，这个时候源IP地址是一样的，其实并没有把这些用户给分发到不同的服务器上，建议采用基于cookie insert的方式，采用cookie的会话保持策略，loadbalance的算法，需要仔细的结合自己的应用的实际情况来设置。

2、大并发的问题
现在你得到了一个大概的系统能承受的并发，但是还达不到系统的设计目标。
应该从应用的角度去分析这个问题，web方面，通过工具(httplook)，检查一下客户端发起的请求都是什么响应状态，如果看到很多304请求状态，你需要优化你的url缓存，看一下每个url的耗费时间，仔细针对比较慢的进行调优；对于tomcat或者weblogic，在高并发的情况下，用kill -3 <PID>，获得ThreadDump(HeapDump需要特殊的设置)，看一下在高并发下，jvm的线程到底在干什么，仔细的分析可能对你有帮助。
如果在这些还没有改善的情况下，应当去想一想，硬件是否足够、配置是否合理等等系统级别的问题。

47 楼 zdonking 2007-09-04  

夸张的软硬件条件

46 楼 8000 2007-09-04  

对于你你们舍得投入巨资买weblogic，买oracle,买几十台HP OR ibm服务器的项目，最好的办法是拨打范凯先生的电话，告诉他们你们需要咨询，几个月后你总共加起来买2台服务器就可以搞定。

这可能是最最捷径的办法，真的！

45 楼 8000 2007-09-04  

EBAY 一台SUN V440，weblogic能做到500WAN Page view

44 楼 8000 2007-09-04  

cauherk 写道

建议一下：
1、数据库压力问题
所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。（某个超大型系统，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。
看到了你在应用前端(weblogic EJB)采用了F5，我个人不是很赞同这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。同样，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。
没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。
对了，对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

以你的投资，别说5000并发,500万并发都不是问题

1.首先为什么要分布WEB层，Service层？
2.为什么需要分布式事务？

43 楼 8000 2007-09-04  

without ejb吧

42 楼 myreligion 2007-09-04  

cauherk 写道

建议一下：
1、数据库压力问题
所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。（某个超大型系统，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。
看到了你在应用前端(weblogic EJB)采用了F5，我个人不是很赞同这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。同样，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。
没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。
对了，对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

做好cache应该就行了，楼主的业务比较简单，热点的业务数据应该也不多，可以考虑在web前面加上squid做cache，然后在应用层做点数据库的cache，问题应该不大。

对于CDN，我们用过；并没有想象中的那么好，cache的效果非常有限，延迟也比较大，而且CDN同步更新时对web服务器的压力非常大，我们web服务器就被个搞死过。如果不是为了南北铁通XXXX互联互通，建议有那个钱不如自己加几台服务器。

41 楼 glchengang 2007-09-04  

EJB并非不能用，而是看你怎么用，那本without EJB的书已经就这个问题讲得很明白了。楼主的技术构架总体来看没太大问题，细节方面还得在实际运行的时候再优化调整。想想看每秒30万的点击，那一秒钟该有多少是重复的数据呀，如果能把缓存做好，减少动态查询，相信20台web承受五万个并发都没问题。

40 楼 bluemeteor 2007-09-04  

davexin 写道

tomcat就不响应了。就像死了一样。

tomcat为什么死掉？当时CPU或者内存的占用率是多少？看看其中JVM占用了多少？有没有OOM的错误？不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。

BTW：国内还有这么火的游戏运营商么？我觉得只有WEB游戏才会达到楼主所描述的峰值访问，火一点的网游很难到达这种情况，总不会是网易吧，但是网易用了100多台服务器……

39 楼 tobato 2007-09-04  

jackson1225 写道

当有一款新游戏上线时,确实会出现一秒有几千人并发访问的情况.

引用

我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。

几千人访问都需要更新数据库么？ LZ说压力不在数据库上，那么几千人访问的压力就在web层了？
是这样么？不知道理解得对不对。

38 楼 davexin 2007-09-03  

tobato 写道

搂主把这些一次发出来多好。。看得真累
当然，如果数据库版本，操作系统版本，硬件具体情况都发出来可以参考的东西就更多了，也就会有更好的
方案。

引用

我们的项目确实需要分布式的.行业是网游代理，一旦有新游戏上线后，
就会有数千万级的用户访问量,目前的系统在这种情况运行就很慢了.
系统需要在 ORACLE数据库中写入业务数据后，还需要在游戏数据库里写入数据,
而游戏数据库一般都是SQL SERVER,所有的操作都需要在一个事务中完成.


具体业务:网游代理业务,系统要为玩家提供会员注册,游戏激活,充值等功能;
这些操作都是首先要记录玩家的注册,激活以及充值记录,然后要在游戏数据库中加入相应的信息.
如充值,首先记录充值日志,然后在游戏数据库中加入充值的游戏点.涉及到一次操作有多个数据库连接的事务控制问题.
访问量:一旦新游戏上线,应该在数千万级的用户量;平时没什么问题的.
人力:开发人员8人左右.

我替上面的兄弟回答一下具体的用户量和数据量吧，现在有用户4000万，马上要和另一个公司的会员系统合并，
加起来一共有9000万用户。数据量单表中有一亿条以上的数据。
这是基本的情况，其实我觉得现在的架构还是可以的，现在支持 的并发大概5000并发用户左右，
接下来会进行系统改造，目标支持1万个并发用户。准备采用 sna的设计方式。


你去测试一下吧，我们系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持
250-400个并发，再多的话，就会相应时间非常的常，超过20秒，
失去了意义 ，所以我们才得出这样的结论的。测试时使用的loadRunner8.0,不信的话，请你自己去测试一下吧，
不知道你的并发量4000是怎么得到的？还请解释一下。

不会采用 hibernate的，最多考虑一下spring，ejb还是不会抛弃的，
因为我们的数据库对数据库要求非常高的，机会每个sql语句都经过优化的，
况且，hibernate我们也不能保证使用之后会比现在的更好。改造系统的原因，
是因为业务的增加，用户的增加，还有公司高层对现有的系统提出更高要求和目标，
就是并发达到1万/秒

从业务分析，网游代理，那么用户玩游戏的时候和你们的服务没有关系把？应该直接与游戏服务器交互了。
冲值，激活显然可以避开分布式事务这个问题，为什么不采用延迟处理呢？ 如果都是oracle可以用oracle的job
如果不是，可以编写一个传输数据的程序，定时(n分钟or n秒)运行一次。我想1分钟的延迟，用户应该几乎感受不到。
避开分布式事务可以提高很多性能。遇到项目，确实需要问自己，真的需要分布式么？有些看似分布式的项目，其实
都可以避开的。我们的业务就是看似分布式，结果我们没有用分布式事务就处理了。
我感觉搞出分布式数据库主要还是为了买中间件产品。除非对时间要求真的很高！

你的数据库结构可能有问题，如果9000万用户数据，那么应该考虑分区、移出非活动数据等方式减小表的数据，
这样才能提高性能。大部分系统性能瓶颈都在数据库上，这个地方需要好好优化。

刀片机 2G内存支持 250-400个并发应该差不多了，再多要排队的。Weblogic跑的是什么机器？如果Weblogic机器够
强，完全可以把web应用放在weblogic上，weblogic作集群。

还是从业务上来考虑，这1万人并发究竟在干啥？ 1万人每秒都在注册？都在对数据库操作？不会把？因此，把业务
分离：静态页面访问类业务，数据库操作类业务分离，我想不要20台服务器就能解决了。

[cauherk的回复就很好]

我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。

37 楼 davexin 2007-09-03  

cauherk 写道

建议一下：
1、数据库压力问题
所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。
可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。
2、事务问题
你采用了两种类型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。（某个超大型系统，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。
看到了你在应用前端(weblogic EJB)采用了F5，我个人不是很赞同这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。同样，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。
3、web的优化
我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。
没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。
对了，对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
4、网络问题
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

说明一下：现在的压力不在数据库层，数据库是2种，oracle和sql server，我们也没有采用分布式的事务，因为也是发现分布式会对数据库造成很大的压力，包括我们银行接口部分，都是有特殊的处理方案，根据不同的业务有不同的处理方法，这点大家不用担心。
还有就是F5的负载均衡 是必不可少的，他的每秒点击量能达到将近30万，并且它有会话的 粘性，只要是同一个ip发过来的请求，它就会把它分到同一台机器的，不用 担心分发错误的。

不过也谢谢你的建议，分析的很到位。

我们现在的问题是apache和tomcat的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库
oracle是RAC群集。性能很好，不用担心。