大家来讨论一下这个问题:奥运门票系统第一小时承受了800万访问量,是表示系统要能承受800万并发用户访问系统才能正常吗?如何才能做到?

superhasty 2007-11-01 06:04:31
如果不是,则系统大约要能承受多大的并发访问的能力(要在1小时内处理800万用户的订票操作)。

从WEB服务器来说,如果使用的是IIS+ASP.NET,你认为需要多少台WEB服务器可以实现?相关方案是什么?
...全文
659 49 打赏 收藏 转发到动态 举报
写回复
用AI写文章
49 条回复
切换为时间正序
请发表友善的回复…
发表回复
Seeko0 2007-11-03
  • 打赏
  • 举报
回复
刚才楼上有人说可以参考火车站设计,想到火车票的预售系统,事先根据不同的站点分配不同的车票,也就是说每个站的票数是有限的,这样就避免了跨区域重复购票的可能.如果奥运会的网上售票也事先根据区域来划分票段,那本区域内买的票其它区域购买不了,然后采用分布式设计,在系统负荷轻的情况下把售票的结果反映给中心服务器,或者按时进行汇总统计.这样应该能减轻不少的压力.当然这里面也涉及到统筹分析学,这类人才相信应该不少.至于上面有人怀疑.net上万级的数据吞吐能力,我想是杞人忧天了,没有见过MSDN突然访问不到了.
flyflytiger 2007-11-03
  • 打赏
  • 举报
回复
到底是怎么回事?
zzmsl 2007-11-03
  • 打赏
  • 举报
回复
纳斯达克采用sql server 2005 每秒可以处理 20w 个交易,微软的广告。
xuan.ye 2007-11-03
  • 打赏
  • 举报
回复
确实和技术无关,关键是如何应用

但是800w人/小时,确实有点吓人,很恐怖,很难想象,如果是一个网路游戏,很正常,但是一个web页面,这个能真是头一回

这个和程序员无关,主要是好的服务器和群集技术。
dxservice 2007-11-03
  • 打赏
  • 举报
回复
mark
spy1024 2007-11-03
  • 打赏
  • 举报
回复
这家公司董事长叫王建琪,何许人也?
dc5858518 2007-11-03
  • 打赏
  • 举报
回复
Seeko0说的最后一句很经典!~


至于上面有人怀疑.net上万级的数据吞吐能力,我想是杞人忧天了,没有见过MSDN突然访问不到了.



确实!~一个很现实的问题!~不要担心那一门技术功能不行!~还是先看看自己对这门技术了解多少吧~!
qqsweb 2007-11-02
  • 打赏
  • 举报
回复
奥运门票第二阶段预售首日预订热情空前高涨,网站瞬间访问量达八百万次,因技术原因暂停销售。票务中心向公众道歉,11月5日将通过媒体公布新的售票信息。






其实这么大数据处理 没有完美的方案的结果! 就是彻底堵塞!
honey52570 2007-11-02
  • 打赏
  • 举报
回复
接分

谢谢
itcoco 2007-11-02
  • 打赏
  • 举报
回复
是 歌华特马捷公司 这个公司么
wgqlj 2007-11-02
  • 打赏
  • 举报
回复
.net估计撑不下吧。
像alibaba、淘宝这样对事务要求比较高的网站绝对是考验性能的。
只知道淘宝采用的是oracle+JBoss。(来自淘宝网校园宣讲时的信息)
跟LZ的话题有点类似。
bwangel 2007-11-02
  • 打赏
  • 举报
回复
对于那种居高临下的态度,偶很反感。
loverdotnet 2007-11-02
  • 打赏
  • 举报
回复
========================================
其实可以做成在各地方做分级售票系统,如上海设立一个售票服务器集群,每天把销售记录上传到中央服务器,可以减轻压力。
========================================

当然不行了。甚至可能出现实际票都卖完了,但上海还在卖。

不过我认为你的思路还是对的,可以把一些体育项目的票分开到不同的服务器上。比如:原来只有A服务器保存所有的票数据,现在增加1台B,把田径、游泳等项目的比赛门票放到B服务器上。这样,还是可行的。但我还有点困惑:很多人是在所有的项目中查哪些项目还有票的。这个是不是变得麻烦了呢?

================================================================================================================

这种情况可以让总部每天分配给各个地方销售的最高额度嘛,这是最简单的办法,可能也是比从技术角度考虑问题更简单的办法哦,凡是不要一味从技术角度去想,呵呵,会进死胡同的哦。
Cherish20 2007-11-02
  • 打赏
  • 举报
回复
这样的问题,应该从DBA角度考虑,可能有助于问题的明朗化。
在程序中,并发虽要严格控制,但DB的连接并发处理,却耐人寻味。
wdzr_826 2007-11-02
  • 打赏
  • 举报
回复
一小时800万,一秒钟也就2000来人,没什么了不起的.
----------
你算术及格...高等数学不及格...
---------------------------------------
这句话经典。
活靶子哥哥 2007-11-02
  • 打赏
  • 举报
回复
相当于洪水攻击
搬运工木木 2007-11-02
  • 打赏
  • 举报
回复
而且,一直觉得国内的太多软件公司没有多少技术含量,以至于我们的奥委会选择合作商时宁肯选择了一家不到50人的合资小公司。
-----------------------------------------------------------------------------
选择这家公司并不是因为技术因素,而是关系因素,你用GOOGLE去搜一下这家公司的老板名字就知道了
wuxing2006 2007-11-02
  • 打赏
  • 举报
回复
继续 应该不是很变态,猜一下,服务器群集,然后采用 动态集成后期绑定的形式,掉用webservice
llainn 2007-11-02
  • 打赏
  • 举报
回复
一小时800万,一秒钟也就2000来人,没什么了不起的.
==============
这咱情况很复杂,不能按平均的说
vrhero 2007-11-02
  • 打赏
  • 举报
回复
一小时800万,一秒钟也就2000来人,没什么了不起的.
----------
你算术及格...高等数学不及格...
加载更多回复(29)
为什么区块链必须是高并发的? 1. 摩尔定律早已结束目前,提高并发性是解决人类计算能力的主要方向了。但是并发的编程模型一直受到来自上下两方的压力。2000年开始之际,人们已经意识到摩尔定律失效了。你不太可能期待着今年写的C代码在明年的时候能够被更快的处理器运行了。因为处理器性能的提升主要是通过堆积更多的core来完成。所以为了编写更快的代码,你要做的是编写并发式的程序,同时使用更多的核、更多的CPU、更多的机器。对于并发式的编程模型这就是来自于下方的压力。当今的主流商业应用软件都是跑在web端的,7乘24小时级以上的并发访问。人们已经无法想象一个运行在桌面的单机程序实现同样的商业价值。对于编程模型来说,这是来自于上方的压力。所以当我们谈论区块链时,我们需要明白支持并发性才能满足市场的需求。2. 线程模型并不理想线程模型是上世纪90年代提出的并发模型,线程模型广泛应用在Java虚拟机、CLR、.net虚拟机中,甚至应用于Erlang这样更高级的系统。线程模型失败的地方在于如果你在读一段Java或C sharp代码,你无法明白有多少个线程在里面。我们可以讨论并行性和并发性,也可以讨论并发式和分步式,前提是我们必须搞清这几个概念。并行性指同步进行的多项活动之间并不共享信息。就像一条八车道的公路,根本没有换道,那就是并行。当你开始允许换道时,不同的活动和线程之间出现交互,那就是并发。分布式就是把每一笔交易想像成一辆车,换道就是切换到不同的处理器上。分布式必然需要面对故障模式,如果允许单独某个任务失败,就带来了本地(local)的概念。线程有不同的概念,包括有操作系统线程和cpu内核的物理线程等等。我谈论的是虚拟机上提供并发性的编程模型。线程模型的问题是本质上在编程语言的语义层面并没有提供并发性的支持。我用语言集成查询作为一个例子,证明语言集成将最终胜出。语言集成查询开始于微软的函数式编程大牛Eric Meyer。数据存储的两个方法是:1,提供一个支持数据存储的库;2,提供一个查询的语言特性。在第一种情况下,并没有类型系统(type system)帮助你对查询进行语义检查。在后一种情况下,类型系统和编译器参与检查确保查询处于良好状态并且不会中断。在过去的十五年中,语言集成查询已经是最热门的话题之一。所以时间将会证明,语言整合的方法会稳步胜出。回到并发的话题,采用库的方法就是线程模式的思路。在语义层面的扩展就是Rholang、 Pict 或者Vim等移动进程演算(mobile process calculi )的思路。type system保证了你在读一段Rholang程序时,能够看到有多少个进程在进行。同样的,如果你采用 pi calculus 或者 ambient calculus也可以具有同样的优势。3. DAO事件其实是一个并发问题并发性成为一种语法现象。因为它是语法,是可以对代码进行分析并检查各种并发属性的语法。一个非常好的示例是竞争条件(race condition):两个事件是否有可能以任意顺序发生?DAO事件其实是一个并发问题,是竞争条件。如果有对应的语言表示,就可以通过语法分析(也称为静态分析),捕获这些错误。即使是熟悉并发问题的老程序员,仍然会不时地搞错,例如用餐哲学家(dining philosophers)或其他类型的问题,所在为并发编写算法是非常困难的。当我在八十年代末和九十年代初期在Rosette工作时,我注意到即使使用非常强大的编程语言,并发编程也是非常困难的事情。不幸的是编程理论停止了二三十年,市场好像卡住了。我惊诧于Javascript一直统治着浏览器平台。我计划开发一个基于Rholang的浏览器语言,使用Rholang从头编写浏览器。4.现在的区块链都错了大多数交易是孤立不相关的。大多数人的财务状况都是彼此分开的。当你去喝咖啡时,地球另一面的人在买菜,你们的交易不相关,在区块链世界中,这一点非常重要。如果我们必须对这些交易进行系列化,我们就走进了死胡同。所有的交易都必须经过一个虚拟机。如果那个虚拟机是顺序的(sequential),Transaction将不得不按线性排列,这正是以太坊虚拟机的模式。在这种情况下,无论是DAG还是区块,那都无所谓了。在区块链上使用序列化模型时,不可能有语言层面的并发的显式表示。因此无法使用静态分析来获得并发行为,并发都隐藏在幕后。这就像一个干净和纯粹的函数式语言和Java之间的区别。使用与lambda演算接近的函数式语言,你所看到的就是你所获得的。所有执行实际上都在代码中。而对于Java来说,程序中存在着一堆隐藏的状态:堆栈、线程数以及类似的东西都在代码中。 
电商项目中,秒杀属于技术挑战难度很大的业务。后台可以发布秒杀商品后或者将现有商品列入秒杀商品,热点分析系统会对商品进行分析,对热点商品做特殊处理。商城会员可以在秒杀活动开始的时间内进行抢购,抢购后可以在线进行支付,支付完成的订单由平台工作人员发货,超时未支付订单会自动取消。 秒杀系统中一共涉及到管理员后台、搜索系统、秒杀系统、抢单流程系统、热点数据发现系统等等。B2B 、B2C商城秒杀商品数据一般都是非常庞大,流量特别高,尤其是双十一等节日,所以设计秒杀系统,既要考虑系统抗压能力,也要考虑系统数据存储和处理能力。秒杀系统虽然流量特别高,但往往高流量抢购的商品为数不多,因此我们系统还需要对抢购热门的商品进行有效识别。 那秒杀系统里面需要解决的问题有哪些呢?1、如何应对海量商品访问?2、热点分析系统该如何设计,实现普通商品和热点商品的实时转换?3、普通商品和热点商品的抢单该如何设计和实现?4、面对海量的订单,我们该如何实现订单生成?5、面对用户超时未支付的订单,我们该如何设计和处理,包括订单信息变更和库存变更等。等等的问题? 本课程将从实战角度带你构建秒杀系统,解决以上我们关注的问题,同时结合实战讲解技术点,让大家在实战中掌握知识点。课程包含JavaEE、微服务、Linux、任务调度、大数据等综合性知识,让大家成为一个综合人才,提高自己的竞争力,为以后跳槽涨薪做好重复准备,机遇来了就能抓住。 课程所用的开发环境为:window10 开发工具:IDEA本课程用到技术:SpringBootSpringCloudMyBatisMySQLFreemark模板引擎BinlogCanalXXL-JOB分布式任务调度NginxLua轻量级脚本语言Flink实时分析KafkaZookeeperRedisOpenrestyMaven等等
购买提醒:全程代码实战,本系列课程建议有Java开发经验2年以上的学员观看和购买。录制本套教程的初衷,通过从业10年接触过很多的技术开发人员,尤其在面试一些技术人员的时候,发现他们的技术知识更新较慢,很多人渴望接触到高并发系统和一些高级技术架构,为了帮助更多人能够提升自己和接触到这类技术架构,并满足企业的人才需求,利用业余时间我开始录制这套教程。通过录制教程有很多学员给我反馈信息,给了我很大的鼓舞,当然也有吐槽,我想说的是技术是没有边界的,脱离一线业务场景去谈技术,都是耍流氓的。如对我录制的教程内容有建议请及时交流。本套课程历经1年时间研发,案例来源于真实业务场景抽离,由从业10年企业一线架构师实录,没有基础不建议购买。购买后提供企业级多方位指导,通过本套案例可以让你学习目前主流的微服务技术架构和多种企业级高并发和海量数据、高可用、分布式、支付、多语言、前后端分离等技术的综合应用解决方案。在开始本课程前给大家科普几个概念: 高并发是指在比较短的时间内有大量的访问访问目标系统系统负载饱和或者过载宕机。 高并发的应用,我们应该都有用过或者见过,比如天猫、京东、拼多多、亚马逊的秒杀抢购还有12306的抢票。我们在体验应用的时候,可能并不会像到这种高并发系统背后的技术实现难度。高并发系统都存在这几种问题,高并发读、高并发写、访问高峰突发性、反馈结果的即时性。在抢购的时候,尤其是抢购火车票的时候,我们经常会疯狂的刷库存,几亿用户产生非常大的高并发读; 通过以上的科普相信大家对课程有一个基本的认知了,本套教程以应用最为广泛的电商系统为标本,给大家构建一个亿级微服务秒杀系统,让大家跟着我的步骤能学习行为背后的原理。本课程采用全新的微服务架构,运用了很多工业界企业解决方案和高级技术,带大家手把手实现一个高性能,高并发,高可用等的亿级微服务秒杀系统,本课程会包含很多高级的内容,比如微服务架构、分布式部署方案、多线程、支付、多语言、全链路性能压力测试等,让大家在实战中学习知识,在实战中不断进步。该课程是一个完整的微服务架构秒杀系统项目代码,案例具有很高的商业价值,大家可以根据自己的业务进行修改,便可以使用。本套课程可以满足世面上绝大多数企业级的业务场景,本课程全部代码可以直接部署企业,普通集群,支撑**并发;集群规模大,支撑亿级并发。本课程包含的技术: IDEA集成开发工具 SpringBoot2.0.2.RELEASE SpringCloudFinchley.RELEASE Thymeleaf(模板引擎技术) 微信支付 支付宝支付 银联支付 分布式数据库Mycat MySQL Druid RabbitMQ 分布式事务 分布式锁 事件驱动 多线程 MyBatis QuartzEhcache Redis Hystrix 单点登陆CAS Nginx Lua Restful AOP技术 性能压力测试Jemter VUE+jQuery+Ajax+NodeJS Python Go语言课程亮点: 1.与企业无缝对接、真实工业界产品 2.主流支付全覆盖(微信、支付宝、银联) 3.前后端分离(主流技术架构) 4.实现高并发请求和实现高可用架构解决方案 5.多语言(Java、Go、Python) 6.亿级微服务秒杀系统(支撑海量数据) 7.大型系统分布式部署方案 8.全链路性能压力测试  9.分布式事务解决方案 10.事件驱动设计解决方案 11.多线程技术的实战应用 12.高并发下的服务降级、限流实战 13.分布式架构师下实现分布式定时调度 14.集成MyBatis实现多数据源路由实战 15.集成Redis缓存实战 16.Eureka注册中心 17.OpenFeign声明式服务调用 18.Hystrix服务熔断降级方式 19.基于Hystrix实现接口降级实战 20.集成SpringCloud实现统一整合方案 21.全程代码实操,提供全部代码和资料 22.提供答疑和提供企业技术方案咨询购买提醒: 我本人在企业从业10年,因为热爱,所以坚持,下一个10年依然会在企业一线服务,因此对于课程中的技术点可以提供全方面的业务场景解决方案。我本人并非培训机构脱离一线业务场景的讲师,从业多年接触过大量的真实业务场景案例,后面会逐步通过教程案例分享我多年的实战经验,送给同行一句话:技术是服务于业务的,脱离一线业务场景就是耍流氓。

62,046

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

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