Osheep

时光不回头,当下最重要。

日访问量超过50W的架构的讨论

本篇文章主要介绍了”日访问量超过50W的架构 30分,无满意结帖,结帖人pyunsong]”,主要涉及到日访问量超过50W的架构 30分,无满意结帖,结帖人pyunsong]方面的内容,对于日访问量超过50W的架构 30分,无满意结帖,结帖人pyunsong]感兴趣的同学可以参考一下。
基于目前的公司要求,现要开发一个类似 b2c的网站,日访问量在50W左右,要请问下网络上的高手..架构如何构建; C#(4.0)+mvc3.0+sqlserver 2008+IIS 6.0  可行否,服务器要如何布署。 struts2+spring3+hibernate+oracle11g+win2003(iis 6.0) 可行否,服务器要如何布署。 struts2+spring3+hibernate+oracle11g+linux(tomcat6.0) 可行否,服务器要如何布署。 如何处理高并发? 谢谢!

這個問題還真沒遇到過,我也想知道,Mark。。。。

50万并不高,三种哪种都行。 加个0么,算是较高吧。 重点在如何设计,技术的选择很重要。要找到瓶颈最重要,用技术去解决瓶颈问题。 另外,好象带宽没有进入你的视线,这也很重要。

宽带100M差不多了。这个问题已解决。 谢谢!

struts2+spring3+ibatis+oracle11g+linux(tomcat6.0) 可行否,服务器要如何布署。  前面搞 啊apache tomcat集群. 数据库集群.

50W真不高,不过追求性能的话,直接 spring3Mvc+ibatis 性能更靠谱点

主要看你的技术属于那块.

技术C#(MVC), java(spring MVC   struts2 MVC  )都用过。。现在主要想了解下服务器方面的事。开发完后。如何布署最合适??      因为后台有大量的数据分析。。

50万是同时在线吗?还是每秒50万读请求?如果每秒50万订单那可不简单 

引用 8 楼 zhumin726 的回复:50万是同时在线吗?还是每秒50万读请求?如果每秒50万订单那可不简单 淘宝也不可能做到50W单/秒吧。每天50W的访问量,真心不算太高。 主要还是数据读写分离,前台从QueryDB读取数据,下单等action操作,走SSB通道,将数据发送到后台数据库。QueryDB和后台数据库之间可通过同步链做数据同步。 其他的什么技术了随便了。

为什么都是框架,难道原始JDBC不行吗?所有的框架最终都是转换为原始JDBC执行的

才那么点50w,小网站

各层做好缓存,基本就没问题了

才五十万,怎么设计都行!

引用 13 楼 fonyer 的回复:才五十万,怎么设计都行! 我也觉得不算高。。。

关键不是50W大小的问题,具体来说如果是日访问量50W,能做到客户对数据访问时的读写控制就可满足,至于用什么框架就得看自己的部署了,用什么都要把数据访问做好。

每秒50W还是每日50W?这两者区别不是一般的大哦,每秒50W的话,必须服务器集群,上1000M的出口带宽才行

站着说话不腰疼 。  引用 13 楼 fonyer 的回复:才五十万,怎么设计都行! 引用 11 楼 worm128 的回复:才那么点50w,小网站

架构都是可行成熟的,个人感觉需要考虑的是服务器集群

50万是起步数据。不算高

该回复于2013-04-17 17:11:23被管理员删除

引用 5 楼 helloqiner 的回复:50W真不高,不过追求性能的话,直接 spring3Mvc+ibatis 性能更靠谱点顶起

该回复于2012-12-18 15:30:30被管理员删除

日访问50W?还需要ORACLE?省点钱用mysql吧。 500000/3600/24=5.78,一秒钟也就5.78个请求,算你峰值是平均的3倍,也就17个。 一台不差的服务器足以支撑。实在没信心可以用压力测试工具,攻击一下服务器。 如果你项目不太,对后期拓展维护要求不高,数据量不大,也并不需要考虑什么架构。 数据库做好点,sql写好点就行。直接用hibernate提供的hql也足以胜任。

sprin3mvc + mybatis(或者直接用spring jdbc)(记着搞个连接池)(strtus,hibernate神马的省省吧……)  nginx/httpd  + 双点tomcat。(三台虚机即可)。 数据库随便你用什么了,如果读的相当频繁,搞个memcache 50W/天没什么压力……代码别写太烂就行

先不说50w大不大。考虑之后的,按上面说的spring+ibatis(连接池proxool)+memcache应该可以,前面lvs(主要是防止挂掉一台的情况或者新版本发布的时候可以逐步发,nginx也可以),下面apache处理静态的东西,resin处理动态的东西。数据库主从的话感觉50w应该一个就能撑,不过为了防止之后规模变大,代码上一定是要支持主从的(配置分开,读写连不同的配置)。给静态文件都设置个有效期,增加gzip压缩(apache里面设置)。js、css采用版本的方式防止更新的时候客户端文件不变。

上面说有大量的分析的话,一个数据库就不好了,还是要主从

楼上的好多都觉得小。。。。。。。。。。前期设计要考虑到以后的 50W只是初步吧 楼主是想最好的办法  而不只是满足50W/天

二台数据库服务器、二台web服务器、加一个F5负载均衡器(可以随时扩充服务器)

多搞几台服务器,宽带搞大点,程序的话一般的购物网站没有太多复杂的逻辑,其实不管是.NET,JAVA还是PHP都是可以解决的,Bing也是基于.NET的

并发量平均下来每秒6个都没有,高峰时间估计100不到.找个靠谱点的服务器,代码不要太垃圾都能跑起来。

该回复于2013-02-15 17:28:54被管理员删除

我觉得程序的设计算法,数据库的优化设计才是最重要的

50万嘛。。无压力,缓存处理好,数据库处理好。。搞定

毫无压力,问题在于数据库

建议楼主在设计项目的时候考虑到后期的扩展,考虑网络MVC框架结构,后期数据量大到时候可以增加网关(服务器)服务器直接交换使用webservice 50万访问量并不高。每天网关处理几千万条数据都没问题

50w的日访问量架构——原则:都用免费软件(或者开源) 1、struts2和mybatis做网站的技术开发架构(针对数据库操作肯定不用说也是数据库连接池,如果性能更好就只有JDBC了)。 2、nginx做负载均衡,resin做web容器集群 3、针对热数据或者常量数据可以放到TTServer(持久化)或者memcache(非持久化)中数据缓存。 4、针对数据库方面mysql就行了,如果有这方面瓶颈,可以分库或者分表解决。

日50万不算高,但是考虑同时并发的量有多大,开发的话一定要按分布式设计,一开始不用搞太多的集群,楼主的几种方案都可以,做做压力测试,不要有性能瓶颈. 如果以后访问量上去了可以加集群的数量,前端的负载均衡,最后还可以数据库分库分表. 前端页面静态化,缓存等等要考虑.

搞个牛逼的服务器额

呵呵,50w每日,肯定有峰值的,估算下再问架构问题吧,简单地说平均每秒没啥意义啊。

该回复于2013-03-12 08:55:10被管理员删除

该回复于2013-03-12 09:19:40被管理员删除

可行。。。。

b2c类电子商务网站单从pv上来衡量架构还是有点困难的,要看整个系统每天所能承受的订单量,从前端页面上来看,很多页面都已经静态化了, 直接使用nginx访问静态页面含无压力。50W PV,选择适合自己业务发展需要的就好了。不需要太纠结架构。前端稍微弄好点就OK了。我们的架构是spring+mybatis 分布式服务+前端spring+struts2(b2c网站,每天的订单数40W+,流水记录每天100W+,PV每天在1KW左右)。

学习了 大神们继续说啊

日访问量在50W左右不好评定它的性能指标,最好有个具体一点的秒并发量,性能是以吞吐量来评定的,就是最高值达到一秒多少访问量; 系统的性能不取决于用什么框架和系统平台,能力是主要决定因素;框架、系统平台、解决方案的选择还要结合项目成本,结合交货期,以及系统将来的规模。 此外,如果是企业级别的系统,性能不是唯一参考指标,还有伸缩性、可维护性、可用性、可靠性等,这些都是与系统的成败紧密结合的。 所以不能根据你的一句日访问量就能判断用什么框架和平台的,可以给出详细一点的需求,大家讨论讨论。

不多,你可以用压力压一下每秒50次看看就知道了

点赞