五千的并发用户量,该用什么架构?后期优化不算,前期架构要架得住才行,求不吝赐教

水上冰石 2014-01-22 04:25:05
如题,中职院校用的一个教学平台,要达到所有学生同时在线的并发要求。现在处于前期架构,为了节省后期修改的时间,求高效的架构设计方向指导。现在用的是ssh,数据库用的mssql 2005,tomcat6,用了连接池技术。如果只是这么简单架构一下,5000用户会不会吃力,尤其要实现在线考试同时提交试卷的功能。
...全文
3677 44 打赏 收藏 转发到动态 举报
写回复
用AI写文章
44 条回复
切换为时间正序
请发表友善的回复…
发表回复
MiceRice 2014-06-30
  • 打赏
  • 举报
回复
引用 42 楼 dokia123 的回复:
最后一句话,是指访问哪些资源啊?举个例子说说。
静态资源,指不需要实时计算(甚至一定时间周期内不需要实时计算)的资源,比如:图片、JS脚本文件、CSS样式文件,以及可静态化(转为HTML)的页面。访问量较大的资讯网站,基本都会将新闻信息转换为HTML静态存储起来。 上述内容因为不需要实时计算,所以可以直接使用能支持高IO的Web服务器,如Apache或者Nginx等来提供访问服务,会比使用Java中间件有显著性能优势。
水上冰石 2014-06-30
  • 打赏
  • 举报
回复
引用 39 楼 Joyhen 的回复:
亲,不要为了架构而架构。《大型网站技术架构:核心原理与案例分析》你值得拥有
啥书,关于架构的?
dokia123 2014-06-29
  • 打赏
  • 举报
回复
引用 1 楼 ldh911 的回复:
数据结构设计的合理,程序写的优美,5000用户就不会有啥压力。 当然服务器不能太烂,搞个小霸王学习机是不行的;PC服务器有个双CPU(2核或4核),应用服务器内存16G+,数据库服务器内存32G+ 也就差不多了。有钱的话就搞集群,没钱就拉倒球。 另外,善用Web服务器分摊静态资源访问压力。
最后一句话,是指访问哪些资源啊?举个例子说说。
  • 打赏
  • 举报
回复
joyhen 2014-06-28
  • 打赏
  • 举报
回复
亲,不要为了架构而架构。《大型网站技术架构:核心原理与案例分析》你值得拥有
joyhen 2014-06-28
  • 打赏
  • 举报
回复
5000并发量不大的,分布式服务器,数据读写分离,合理的业务拆分,就妥了
G63AMG6X6 2014-06-26
  • 打赏
  • 举报
回复
学习了,6个字符串
sharky19 2014-06-25
  • 打赏
  • 举报
回复
学习中,有点高深
ydm305365 2014-06-20
  • 打赏
  • 举报
回复
其实我有一个思路不知道,是否可行,首先用ngnix做负载,在使用消息中间件做异步(ActiveMq),提交动作里的逻辑,只负责发送消息,把试卷信息发送给ActiveMq,支持持久化,这样这个提交动作就会很快结束,减少时间占用,然后在消息处理端开多线程程去处理消息。
高坚果兄弟 2014-06-17
  • 打赏
  • 举报
回复
学习了
haonan108 2014-06-17
  • 打赏
  • 举报
回复
学习下,有个想法不知是否可行,当学生进行答题首次访问页面时服务器端就将答案通过请求响应给客户端,这样答完题后直接通过前端来生成结果,可能会存在安全问题。
taoguangye 2014-06-17
  • 打赏
  • 举报
回复
这种情况很好解决吧,认真分析下,交完卷,后服务器就没有事做了,而一边处理交卷还要一边阅卷并存到数据库的话服务器瞬时负荷会很大,所以为什么不在交卷时先暂时快速将提交的数据先暂存到磁盘,处理完交卷后才来慢慢处理提交的数据呢,有些问题其实换种角度和方法,会海阔天空.
快快猪搞技术 2014-03-15
  • 打赏
  • 举报
回复
如果没有其他读写压力,现在的数据库对于单纯写效率其实已经很高了。每秒几千条应该没问题。web前端可以多部署几套,用负载均衡就可以了。如果对数据库没有信心,可以考虑一些nosql的方案来做。
乔不思 2014-03-07
  • 打赏
  • 举报
回复
mark有时间学习
pcvvv 2014-03-07
  • 打赏
  • 举报
回复
引用 23 楼 ldh911 的回复:
[quote=引用 21 楼 jiao_zg 的回复:] 奥?这是为什么?我又错了。。。
牵扯几个问题,一下子不能完全解释完毕。 首先是线程执行效率问题,线程数量越多,线程切换开销越大,也就是你宝贵的CPU全都浪费在切换线程上下文上了。毕竟你CPU就4/8/12个核,这么多线程说白了也就是轮流执行。而且线程数量达到一定程度后,性能会指数级下降。所以计算密集型一般就是 核数×2~×3 的线程数量就差不多了,当然你这例子中,显然不是计算密集型应用程序。 然后是中间件保护问题,5000个请求来了,我就真的要分配5000个线程去服务么?想想看:银行柜台、高速公路收费站、医院挂号处。现实生活中会给每一个并发资源配置对应的服务资源么?不会的。 那你可能会问:5000个请求来了,只有500个服务线程,其它请求咋办?答:参考现实世界,排队呗,中间件会让他们去排队的。 换个方式考虑这个问题,你用5000个线程去同时服务5000个请求,到了CPU这里还是排队处理(轮询处理);还浪费一堆的切换代价,那你何必不让他们先排队,有资格了一口气服务完毕? 最后关于数据库问题,500个服务线程需要从一开始就占用数据库连接到最后么?不是的吧?除了保存那一瞬间需要占用下数据库连接,其它时间都不需要吧。既然如此,弄那么多数据库连接出来干啥?浪费内存、浪费CPU开销、浪费生命、浪费世界观、人生观和价值观嘛~~~[/quote]
水上冰石 2014-03-05
  • 打赏
  • 举报
回复
引用 26 楼 zhuchao_ko 的回复:
我看下来,其实你们说的楼主根本不懂。
我在努力学习中。。
宁波朱超 2014-03-05
  • 打赏
  • 举报
回复
我看下来,其实你们说的楼主根本不懂。
猫神jdx 2014-02-27
  • 打赏
  • 举报
回复
引用 16 楼 mengweilil 的回复:
[quote=引用 14 楼 mengweilil 的回复:] nginx+vanish+mysql+coreseek+静态页面,cpu:8核,内存:12g。
引用 15 楼 jiao_zg 的回复:
[quote=引用 14 楼 mengweilil 的回复:] nginx+vanish+mysql+coreseek+静态页面,cpu:8核,内存:12g。
这是个什么意思?[/quote] 1、建议你使用的应用服务器:nginx 2、建议你使用缓存:vanish 3、建议你使用全文检索:coreseek(从数据库取出内容,生成索引,有php接口可以搜索,得到信息ID之后,返回数据库取出实际内容,可以减轻数据库压力,并且速度非常快)。 4、建议所有可以生成静态页面的都用静态页面。 5、建议使用的服务器的硬件配置,如果条件允许,数据库+全文搜索单独一台服务器。[/quote] 这里已经提级到目前中大型系统的一些配置,简单说一下 (1)nginx,负载均衡,就是部署N个服务器,由负载均衡器或负载中间件控制,把访问量平均分摊到N个服务器, nginx是负载均衡的其中一种,还有其他的 (2)vanish缓存机制,memcache,就是把一些常用的数据(很少修改)放到缓存,用户访问时候直接从缓存取出,减少数据库压力,缓存会有专门的服务器部署.vanish也是缓存一种 (4)静态页面,除了都用静态页面,现在还会做静态分离,就是把图片,CSS,JS这些单独配置到指定的服务器(设置好域名),主服务器再通过域名获取,主要是减轻服务器压力,图片很耗带宽,看看12306就知道为什么卡死
水上冰石 2014-02-26
  • 打赏
  • 举报
回复
引用 23 楼 ldh911 的回复:
[quote=引用 21 楼 jiao_zg 的回复:] 奥?这是为什么?我又错了。。。
牵扯几个问题,一下子不能完全解释完毕。 首先是线程执行效率问题,线程数量越多,线程切换开销越大,也就是你宝贵的CPU全都浪费在切换线程上下文上了。毕竟你CPU就4/8/12个核,这么多线程说白了也就是轮流执行。而且线程数量达到一定程度后,性能会指数级下降。所以计算密集型一般就是 核数×2~×3 的线程数量就差不多了,当然你这例子中,显然不是计算密集型应用程序。 然后是中间件保护问题,5000个请求来了,我就真的要分配5000个线程去服务么?想想看:银行柜台、高速公路收费站、医院挂号处。现实生活中会给每一个并发资源配置对应的服务资源么?不会的。 那你可能会问:5000个请求来了,只有500个服务线程,其它请求咋办?答:参考现实世界,排队呗,中间件会让他们去排队的。 换个方式考虑这个问题,你用5000个线程去同时服务5000个请求,到了CPU这里还是排队处理(轮询处理);还浪费一堆的切换代价,那你何必不让他们先排队,有资格了一口气服务完毕? 最后关于数据库问题,500个服务线程需要从一开始就占用数据库连接到最后么?不是的吧?除了保存那一瞬间需要占用下数据库连接,其它时间都不需要吧。既然如此,弄那么多数据库连接出来干啥?浪费内存、浪费CPU开销、浪费生命、浪费世界观、人生观和价值观嘛~~~[/quote] 这么一解释,我这个笨人也懂了 送花送花
MiceRice 2014-02-26
  • 打赏
  • 举报
回复
引用 21 楼 jiao_zg 的回复:
奥?这是为什么?我又错了。。。
牵扯几个问题,一下子不能完全解释完毕。 首先是线程执行效率问题,线程数量越多,线程切换开销越大,也就是你宝贵的CPU全都浪费在切换线程上下文上了。毕竟你CPU就4/8/12个核,这么多线程说白了也就是轮流执行。而且线程数量达到一定程度后,性能会指数级下降。所以计算密集型一般就是 核数×2~×3 的线程数量就差不多了,当然你这例子中,显然不是计算密集型应用程序。 然后是中间件保护问题,5000个请求来了,我就真的要分配5000个线程去服务么?想想看:银行柜台、高速公路收费站、医院挂号处。现实生活中会给每一个并发资源配置对应的服务资源么?不会的。 那你可能会问:5000个请求来了,只有500个服务线程,其它请求咋办?答:参考现实世界,排队呗,中间件会让他们去排队的。 换个方式考虑这个问题,你用5000个线程去同时服务5000个请求,到了CPU这里还是排队处理(轮询处理);还浪费一堆的切换代价,那你何必不让他们先排队,有资格了一口气服务完毕? 最后关于数据库问题,500个服务线程需要从一开始就占用数据库连接到最后么?不是的吧?除了保存那一瞬间需要占用下数据库连接,其它时间都不需要吧。既然如此,弄那么多数据库连接出来干啥?浪费内存、浪费CPU开销、浪费生命、浪费世界观、人生观和价值观嘛~~~
加载更多回复(22)

25,985

社区成员

发帖
与我相关
我的任务
社区描述
高性能WEB开发
社区管理员
  • 高性能WEB开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧