12306称有信心解决技术问题 不与企业合作(转)

来源:百度文库 编辑:超级军网 时间:2024/04/29 12:16:42
http://tech.163.com/12/0920/05/8BQQVAMO00094MOK.html

12306称有信心解决技术问题 不与企业合作

近两天,多名网友上传截屏图,显示在12306网站从登录到预订、排队、处理等各个环节都遭遇卡壳。

昨日起,铁路部门通过网络和电话开始发售9月30日“中秋节”的车票。据铁路上海站预测,9月30日预计发送旅客34.6万人次。在这一波购票高峰下,12306网站昨日“卡壳”依旧。旅客诉苦:网络购票系统新实施的“强制排队”功能,仿佛把火车站的队伍挪到了网上。

铁路购票系统从研发到诞生,10年内历经6次升级,从人工发售硬板票到实现实名制售票、电子客票和电子支付,但火车票“一票难求”的本质仍未改变。

把火车站队伍移到网上

“排队咯!排队咯!谁也在排队啊?”昨日中午11点10分,网友“主播晓菡”在自己的微博上贴出截图,上面显示“车票状态为排队等待中,还需等待超过30分钟”。

几经波折,该网友终于在昨天下午成功买到车票,“上午开始排队,下午到了办公室一度打不开12306网站,终于打开了之后发现我的订单没有了……于是重新订票,重新排队,最后下午4点多终于付上款了。”

但更多的购票者就不像她这般“顺利”了。据悉,12306购票网站于上周日完成了新一轮升级,但是众多用户反映,升级后用户购票可能会被强制排队,由于系统存在多处漏洞,排队后购买失败的概率很大。一时间,效率低下的12306购票网站成了网友吐槽的对象。

“今日该车次和席别已有超过1495人次先于您提交订票请求,至处理您提交请求时可能已无票,是否继续?”一名旅客在预订9月29日北京西开往乌鲁木齐的T69次列车时,遇到了上述尴尬的遭遇。点击“确定”,等待的时间是个无底洞,说不定还有无票的可能;点击“取消”,只会越排越后面,还有可能刷不出新的页面。旅客诉苦:“12306网站只是把火车站的队伍挪到了网上,‘一票难求’的本质还是没有变。”

为了验证网友的说法是否属实,早报记者分别在昨天上午、下午和晚间多次尝试登录12306购票网站,除了上午顺利登录一次之外,其他均显示系统访问量过大无法登录。

“有信心解决问题”

其实,12306网站订票系统在推出之初就频现访问量过大瘫痪的尴尬。在今年1月份的春运新闻发布会上,铁道部副部长胡亚东透露, 12306网站的注册用户数量突破1000万,从1月1日到1月7日日均访问量超过10亿次。

对于旅客的不满,铁道部相关人士透露,部里对电子票务系统的态度是“承认不足,努力改进,“今年春运总结的时候,相关领导要求团队继续解决技术难题。”

近日,该网站又遭到网友质疑存在出票猫腻。对此,铁道部该人士透露:“铁道部10年前就在研究院设立课题组,研发电子订票系统。铁路有信心能解决出现的问题。”

据介绍,12306互联网购票系统是基于中国铁路客票发售和预订系统(简称客票系统)这一核心系统构建的。客票系统在10余年的运营过程中先后完成6次升级:1.0版本实现了计算机售票取代人工硬板票,2.0版本实现了区域级联网,3.0版本实现了全国联网售票,4.0版本实现了与清分清算系统的对接,5.0版本实现了席位复用和共用,5.2版本实现了实名制售票、电子客票和电子支付。

网站不会和企业合作

网上预约“国庆”车票、更改动车座位编号、月底推出手机购票业务……铁路部门近期推出一系列便民举措,反而让旅客担心,连一个网站都建设不好,又如何能确保“手机购票”等新业务项目不会“卡壳”?

在今年春运时就有网友提出,铁路部门可以和电商平台合作,借用后者的技术和管理经验来把12306购票网站做好。携程网CEO范敏曾在微博上表示,“放开高铁票务有利铁老大改善形象,机票早已市场化,高铁为何不可放开?”

负责铁路电子票务系统的主要是铁道科学研究院电子所。对于为何不与国内成熟电子商务系统合作的质疑,一位电子所的研究员告诉早报记者:“我们12306网站是非营利性质的,不会和商业企业合作,而且我们对自己的技术有信心。”http://tech.163.com/12/0920/05/8BQQVAMO00094MOK.html

12306称有信心解决技术问题 不与企业合作

近两天,多名网友上传截屏图,显示在12306网站从登录到预订、排队、处理等各个环节都遭遇卡壳。

昨日起,铁路部门通过网络和电话开始发售9月30日“中秋节”的车票。据铁路上海站预测,9月30日预计发送旅客34.6万人次。在这一波购票高峰下,12306网站昨日“卡壳”依旧。旅客诉苦:网络购票系统新实施的“强制排队”功能,仿佛把火车站的队伍挪到了网上。

铁路购票系统从研发到诞生,10年内历经6次升级,从人工发售硬板票到实现实名制售票、电子客票和电子支付,但火车票“一票难求”的本质仍未改变。

把火车站队伍移到网上

“排队咯!排队咯!谁也在排队啊?”昨日中午11点10分,网友“主播晓菡”在自己的微博上贴出截图,上面显示“车票状态为排队等待中,还需等待超过30分钟”。

几经波折,该网友终于在昨天下午成功买到车票,“上午开始排队,下午到了办公室一度打不开12306网站,终于打开了之后发现我的订单没有了……于是重新订票,重新排队,最后下午4点多终于付上款了。”

但更多的购票者就不像她这般“顺利”了。据悉,12306购票网站于上周日完成了新一轮升级,但是众多用户反映,升级后用户购票可能会被强制排队,由于系统存在多处漏洞,排队后购买失败的概率很大。一时间,效率低下的12306购票网站成了网友吐槽的对象。

“今日该车次和席别已有超过1495人次先于您提交订票请求,至处理您提交请求时可能已无票,是否继续?”一名旅客在预订9月29日北京西开往乌鲁木齐的T69次列车时,遇到了上述尴尬的遭遇。点击“确定”,等待的时间是个无底洞,说不定还有无票的可能;点击“取消”,只会越排越后面,还有可能刷不出新的页面。旅客诉苦:“12306网站只是把火车站的队伍挪到了网上,‘一票难求’的本质还是没有变。”

为了验证网友的说法是否属实,早报记者分别在昨天上午、下午和晚间多次尝试登录12306购票网站,除了上午顺利登录一次之外,其他均显示系统访问量过大无法登录。

“有信心解决问题”

其实,12306网站订票系统在推出之初就频现访问量过大瘫痪的尴尬。在今年1月份的春运新闻发布会上,铁道部副部长胡亚东透露, 12306网站的注册用户数量突破1000万,从1月1日到1月7日日均访问量超过10亿次。

对于旅客的不满,铁道部相关人士透露,部里对电子票务系统的态度是“承认不足,努力改进,“今年春运总结的时候,相关领导要求团队继续解决技术难题。”

近日,该网站又遭到网友质疑存在出票猫腻。对此,铁道部该人士透露:“铁道部10年前就在研究院设立课题组,研发电子订票系统。铁路有信心能解决出现的问题。”

据介绍,12306互联网购票系统是基于中国铁路客票发售和预订系统(简称客票系统)这一核心系统构建的。客票系统在10余年的运营过程中先后完成6次升级:1.0版本实现了计算机售票取代人工硬板票,2.0版本实现了区域级联网,3.0版本实现了全国联网售票,4.0版本实现了与清分清算系统的对接,5.0版本实现了席位复用和共用,5.2版本实现了实名制售票、电子客票和电子支付。

网站不会和企业合作

网上预约“国庆”车票、更改动车座位编号、月底推出手机购票业务……铁路部门近期推出一系列便民举措,反而让旅客担心,连一个网站都建设不好,又如何能确保“手机购票”等新业务项目不会“卡壳”?

在今年春运时就有网友提出,铁路部门可以和电商平台合作,借用后者的技术和管理经验来把12306购票网站做好。携程网CEO范敏曾在微博上表示,“放开高铁票务有利铁老大改善形象,机票早已市场化,高铁为何不可放开?”

负责铁路电子票务系统的主要是铁道科学研究院电子所。对于为何不与国内成熟电子商务系统合作的质疑,一位电子所的研究员告诉早报记者:“我们12306网站是非营利性质的,不会和商业企业合作,而且我们对自己的技术有信心。”
世界上没有任何一个网站的服务器承受的压力大于铁道部的,铁道部一直在努力。
诸葛没亮 发表于 2012-9-21 18:11
世界上没有任何一个网站的服务器承受的压力大于铁道部的,铁道部一直在努力。
航空的售票方式为何不借鉴呢?
众多的机票代理商,分散的多点对多点售票体制,本质上没有拥堵点
这才是先进的设计理念

让自己的网站服务器承受压力成为世界第一,这并不光彩,而只能说明从顶层设计就是彻底的失败
航空的售票方式为何不借鉴呢?  众多的机票代理商,分散的多点对多点售票体制,本质上没有拥堵点  这才是 ...
即使航空售票什么的不也一样吗?最终的数据还是在航空售票的服务器处理,主要是飞机票的数据量小。大数据量下分散售票其实是行不通的,这样服务器处理数据和售票系统不一定匹配不说还更没有效率。就好比北京修京藏,京新,京化高速公路出京一样,听着挺多,但在张家口境内汇合成一条,北京不堵了,车都在张家口堵着呢。
实在不明白售票网站怎么会采用数字代号12306,有什么特殊含义么?这样的号码不容易记啊。干嘛不直接是火车票这样的拼音或者首字母简写,或者学习日本建立中国铁道的统一标识,比如CHR。这样搜索也方便啊。
实在不明白售票网站怎么会采用数字代号12306,有什么特殊含义么?这样的号码不容易记啊。干嘛不直接是火车票 ...
crh chr记错了怎么办,谁知道中国高速铁路怎么用英文说,难道非得用耻辱号(crh)来记怎么搜索才能找到买票网站吗?那打铁道部客服怎么拨crh啊
诸葛没亮 发表于 2012-9-21 18:11
世界上没有任何一个网站的服务器承受的压力大于铁道部的,铁道部一直在努力。
百度、google服务器的压力没有谷歌大???
百度、google服务器的压力没有谷歌大???
比如百度,在很多地方的宽带运营商处长期租用vip机房,百度是一个vip机房对应一个地区,而铁道部所有的数据都必须经过铁道部的数据库,所以说铁道部承受的服务器压力全世界第一不为过,和各个终端的数据都要一致还有车座复用等等都不是我们想的那么容易的,如果你真正去开发这个系统肯定有更多意想不到的问题出现。何况还得兼容之前的设备,而且还得平滑升级,铁道部售票系统即使停一天那影响可就大了去了。。
诸葛没亮 发表于 2012-9-23 13:06
即使航空售票什么的不也一样吗?最终的数据还是在航空售票的服务器处理,主要是飞机票的数据量小。大数据 ...

航空售票的机制至少经过实践证明没这么多毛病

“其实行不通”,你试过?
哈  航空售票的机制至少经过实践证明没这么多毛病  
民航的售票数据库也是集中的,其多售票渠道最终还是到民航数据库,这和我举的张家口的高速公路是一个道理。而目前铁道部买票和航空有区别吗?要说有只能说航空是点对点的,而铁路不是直达的,中间有停靠站,座位考虑复用,比民航处理数据量要大,更何况铁路出行的人口数量。铁道部平时崩溃吗?每天10亿级别的访问量带来多少数据,民航的服务器能承受了吗?铁道部好歹还是有良心的,你看看四六级的查分网站在哪里?
诸葛没亮 发表于 2012-9-23 21:33
比如百度,在很多地方的宽带运营商处长期租用vip机房,百度是一个vip机房对应一个地区,而铁道部所有的数 ...
百度可以租机房,铁道部不可以???各个铁路局租机房不行???
wcdmabbs 发表于 2012-9-24 16:24
百度可以租机房,铁道部不可以???各个铁路局租机房不行???
铁道部应该就一个数据中心,没必要搞局中心。
这样巨大规模的企业中心,都自建机房拉专线。
压力问题,忘情的博客里已经说得很清楚了,尤其是第一条。
http://blog.sina.com.cn/s/blog_3e489c7101019xf5.html
其实从我自己使用12306网站的体验看,还是很快捷方便的。除了去年春节期间,基本上没有遇到特别难登陆和购买的情况,有票就是有票,没有就是没有。
百度可以租机房,铁道部不可以???各个铁路局租机房不行???
别管租多少机房,机房都得和数据库连通,这么大量的数据你说通过集中起来局域网联通快还是分散到各个机房宽带快?
诸葛没亮 发表于 2012-9-24 18:00
别管租多少机房,机房都得和数据库连通,这么大量的数据你说通过集中起来局域网联通快还是分散到各个机房 ...

百度不存在这样的问题???

壮东风 发表于 2012-9-24 17:25
铁道部应该就一个数据中心,没必要搞局中心。
这样巨大规模的企业中心,都自建机房拉专线。
压力问题, ...


不觉得你给的帖子能够说服人。铁道部在卖票上对比以前确实有进步,但还不够。


这样巨大规模的企业中心,都自建机房拉专线。没说不能自建机房,只是一个数据中心不大合理,你给的帖子也认为建分布式数据中心是更好的办法。


简单说一下我的想法:分布式数据中心,在所在地铁路局范围内买票完全可以在本铁路局数据中心处理,异地跨铁路局买票通过12306处理,同等硬件条件下,可以大幅度提高效率。

另外,12306的访问量高,很大程度上是因为重复访问,采用分布式数据中心,减少排队等候时间,可以减少很多重复访问。



壮东风 发表于 2012-9-24 17:25
铁道部应该就一个数据中心,没必要搞局中心。
这样巨大规模的企业中心,都自建机房拉专线。
压力问题, ...


不觉得你给的帖子能够说服人。铁道部在卖票上对比以前确实有进步,但还不够。


这样巨大规模的企业中心,都自建机房拉专线。没说不能自建机房,只是一个数据中心不大合理,你给的帖子也认为建分布式数据中心是更好的办法。


简单说一下我的想法:分布式数据中心,在所在地铁路局范围内买票完全可以在本铁路局数据中心处理,异地跨铁路局买票通过12306处理,同等硬件条件下,可以大幅度提高效率。

另外,12306的访问量高,很大程度上是因为重复访问,采用分布式数据中心,减少排队等候时间,可以减少很多重复访问。


不和企业合作,就是关上了智力支持的大门,闭门造车开始了,你现在够聪明,不代表你明天还是狗聪明,应该开放,分工,才可以用最小的力气做最大的事情,一个人或者一家单位什么都独立搞,之歌思想就是错误的,除非这个事情企业做不了,比如原子弹什么的,如果企业可以的话,都应该交给企业去完成。外包就可以了,安全什么的在这个基础之上在来完善,不好吗?
说白了其中有猫腻
找家高明互联网企业开发根本用不了这么多钱,效果还更好
现在死撑面子,置国人需求于不顾
看看那个界面,那个使用体验,感觉就是上个世纪的网站似的,把中国面子丢尽了
wcdmabbs 发表于 2012-9-25 12:22
不觉得你给的帖子能够说服人。铁道部在卖票上对比以前确实有进步,但还不够。
分布式数据中心已经不符合时代潮流了。
售票系统不是网站,数据流量要考虑什么南北问题,12306对售票系统接口的调用流量不大,图片、CSS等静态素材估计已经考虑过CDN了。
分布式数据中心实际上是走了回头路,铁道部售票系统跟银行系统非常类似,你可以看看各大行和银联这10年来的发展,都是集中再集中,最终变成一个全国中心。
在一个大中心里,如果在不同路局购票,本来就不构成冲突,跨路局时,如果走分布的道路,还要通过一个全国交换中心转接,效率没有丝毫提高。
分布式中心尤其不利于管理。
那篇文章第一点里有一句话:“订票系统访问的是中心的票量数据”,其实已经把最关键的地方都说了,为什么窗口、代售点在网上购票开通以后不受影响?很简单,接口限流了,这不是分布式中心能解决的问题。
其实吧,集中处理架构本身也是没有神马问题的。例如嘛:
每个车次的票用一个服务器、一个数据库来跑,那么就算我现在用的笔记本来做服务器处理起来估计都没神马问题。关键是全国有好多个车次呢?估计有5000个吧,那就需要计算中心维护5000台笔记本7*16(订票只有16个小时每天)小时运行。这个工作量其实是很大的,当然可以换成小型机,就算他的处理能力是我的笔记本的10-100倍(具体需要看它的cpu、内存),就算100倍吧,需要维护50台小型机,这个工作量也不小,如果换成大型机,粗略估计5台吧。这个工作量比较现实了。这样,计算中心的瓶颈排除了。
通讯瓶颈:其实12306的并发要求真的很高,远比qq、网游、B2C运营商的并发要求高。并发要求高,要解决的话,绝招无非就是并行咯。就像高速公路,一个车道不够跑,咱给他开10个不就结了。和高速公路不同的是,交易请求不知道变道,从哪个道上去就从哪个道下来。所以需要在入口处将交易请求区分开,避免拥堵。简单的解决办法是,后端的5个大型机(根据情况,可以横向扩展),每个有自己的专用车道,客户端根据客户的请求自行判断该走哪个道。后端服务器同时维持车道分配图,以前本来该自己处理的请求,由于新建了车道,分流了,则将前端应该访问的车道数据返回前端,由前端向正确的服务器重新发起请求。
wcdmabbs 发表于 2012-9-25 11:57
百度不存在这样的问题???
存在,但是数据的压力很小,因为百度是做搜索的。百度类似于qq,只是对个人帐号有一些数据需要读取,而且还不是交互式的,不是动态的。
agsgs 发表于 2012-9-25 13:14
说白了其中有猫腻
找家高明互联网企业开发根本用不了这么多钱,效果还更好
现在死撑面子,置国人需求于不 ...
高明的互联网企业?我认为目前太极的思路是对的,给点时间嘛。一个负责引导分配的前端服务器,加上分好组的中心数据库是很高效的。现在是前端服务器处理能力有点不足,排队的算法应该有些不足,这些都是好改的,前端加几个服务器,排队的统计算法考虑的充分一些就行,新升级的系统遇上买票高峰出问题是可以理解的。
12306的主页太丑了,就这个都能看出来不怎么样。
壮东风 发表于 2012-9-25 13:14
分布式数据中心已经不符合时代潮流了。
售票系统不是网站,数据流量要考虑什么南北问题,12306对售票系统 ...
[color=Red]写了那么多,我小结一下:

2)集中式的卖票很难搞定,使用上述的技术可以让订票系统能有几佰倍的性能提升。而在各个省市建分站,分开卖票,是能让现有系统性能有质的提升的最好方法。


如果你认为他说的是对的,就看完全文吧


为了减轻对中心服务器的压力,应该在各个分局建立工作中心,把核心数据库的数据备份出来。一些查询,前期的判断就依赖这个缓冲数据库,只有最后的购票确认环节才去查询和更新核心数据库,这样,就把节假日大量的无效请求压力分散到各个路局数据中心了。而真正的有效请求压力是恒定的:因为票额是有限的。无票状态在分局就拒绝了,不会反复消耗核心数据库的资源。就像秘书帮领导排会客表那样,领导不至于无法响应过多的请求。

按这个思路,很容易确定核心数据库需要的工作容量:每天最大出票额*每个购票业务的带宽消耗。

而节假日的压力就由各路局数据中心去承担了。哪个路局的压力大,就专门扩大它的规模即可。单个路局的压力,无论如何也不会比目前更严重了,毕竟现在是面对全国的潜在购票压力。

wcdmabbs 发表于 2012-9-26 00:30
写了那么多,我小结一下:

2)集中式的卖票很难搞定,使用上述的技术可以让订票系统能有几 ...


未必全对。
这篇文章很准确地指出了症结,后面的技术改进措施跟一般思路差不多,仅作参考即可。
物理分开的分区中心,跟大中心的逻辑分隔,效果是相同的,而现在的通信条件大为改善,不用担心服务请求应答的数据流量。
分布系统可以分担压力的观点,对流量型的网站比较适用,但对于在线交易系统,是一个误解。
分区中心的管理和数据交换是很大的问题,而且不利于提高软硬件的使用效率。
这些年走的路就是从分散到集中,不可能走回头路。
wcdmabbs 发表于 2012-9-26 00:30
写了那么多,我小结一下:

2)集中式的卖票很难搞定,使用上述的技术可以让订票系统能有几 ...


未必全对。
这篇文章很准确地指出了症结,后面的技术改进措施跟一般思路差不多,仅作参考即可。
物理分开的分区中心,跟大中心的逻辑分隔,效果是相同的,而现在的通信条件大为改善,不用担心服务请求应答的数据流量。
分布系统可以分担压力的观点,对流量型的网站比较适用,但对于在线交易系统,是一个误解。
分区中心的管理和数据交换是很大的问题,而且不利于提高软硬件的使用效率。
这些年走的路就是从分散到集中,不可能走回头路。
mmgm 发表于 2012-9-26 01:40
为了减轻对中心服务器的压力,应该在各个分局建立工作中心,把核心数据库的数据备份出来。一些查询,前期的 ...
这些应对措施在大中心就可以做,不必物理上分割为小中心,目前通信不是问题。
除了铁道部有信心,没有任何人对他们有信心。没人在乎你花了3个亿还是5个,问题是能不能解决问题,而不是一次又一次的说“我们有信心解决问题”,信心有个屁用,
为了减轻对中心服务器的压力,应该在各个分局建立工作中心,把核心数据库的数据备份出来。一些查询,前期的 ...
那按你的想法做然后把各个路局的服务器挪回铁道部中心岂不是更有效率?
那些答曰数据库并发很简单的专业人士,可以自己试着在PC(无论多牛的配置)用access+SQL,看看能否完成同时每秒2w个查询,5000个更新再加100个回滚操作。
要知道,就算是IBM、甲骨文,当前的数据库技术对于目前的人类需求来讲,也不是没有瓶颈,他们的技术不是天顶星。


各位觉得淘宝的做得如何?
类似于光棍节狂欢,我之前看到如下描述:

11日零点过后,第1分钟,进入淘宝商城的会员有342万”。过一会工程师主动拿起电话:“交易额超过1亿了,现在是第8分钟。”接下来,“第21分钟,刚突破2亿”。“第32分钟,3亿了”。“第1个小时,4.39亿”。这些数据随后出现在微博上,引起一片惊呼

淘宝能够举办如此盛宴,网站的技术实力可见一斑。淘宝网拥有全国最大的hadoop分布式计算集群之一,日新增数据50TB,有40PB海量数据存储。分布在全国各地80多个节点的CDN网络,支持的流量超过800Gbps。淘宝的搜索引擎能够对数十亿的商品数据进行实时搜索,另外还拥有自主研发的文件存储系统和缓存系统,以及java中间件和消息中间件系统,这一切组成了一个庞大的电子商务操作系统。另外从商业数据上来看,AMAZON的财报显示2011年完成了大约 480亿美金的交易额,EBAY2011年财报全年完成了大约600亿美金的交易额(不包括其独立的汽车交易平台)。不管从交易额、商品数量、同比增速等指标上看,淘宝网均远超于此,是目前全球最大的电子商务平台。(由于淘宝非上市公司,未公布2011年业绩,以上内容来自淘宝网技术副总裁@_行癫 的微博)


能网上订票的列车 有没有3000趟?,平均下来每一趟1K访问算(热门线路肯定不止,但冷门的肯定没有),总数300万访问量。
(百度了下,全部列车有4000左右)

各位觉得淘宝的做得如何?
类似于光棍节狂欢,我之前看到如下描述:

11日零点过后,第1分钟,进入淘宝商城的会员有342万”。过一会工程师主动拿起电话:“交易额超过1亿了,现在是第8分钟。”接下来,“第21分钟,刚突破2亿”。“第32分钟,3亿了”。“第1个小时,4.39亿”。这些数据随后出现在微博上,引起一片惊呼

淘宝能够举办如此盛宴,网站的技术实力可见一斑。淘宝网拥有全国最大的hadoop分布式计算集群之一,日新增数据50TB,有40PB海量数据存储。分布在全国各地80多个节点的CDN网络,支持的流量超过800Gbps。淘宝的搜索引擎能够对数十亿的商品数据进行实时搜索,另外还拥有自主研发的文件存储系统和缓存系统,以及java中间件和消息中间件系统,这一切组成了一个庞大的电子商务操作系统。另外从商业数据上来看,AMAZON的财报显示2011年完成了大约 480亿美金的交易额,EBAY2011年财报全年完成了大约600亿美金的交易额(不包括其独立的汽车交易平台)。不管从交易额、商品数量、同比增速等指标上看,淘宝网均远超于此,是目前全球最大的电子商务平台。(由于淘宝非上市公司,未公布2011年业绩,以上内容来自淘宝网技术副总裁@_行癫 的微博)


能网上订票的列车 有没有3000趟?,平均下来每一趟1K访问算(热门线路肯定不止,但冷门的肯定没有),总数300万访问量。
(百度了下,全部列车有4000左右)
jerry0201 发表于 2012-9-26 13:12
那些答曰数据库并发很简单的专业人士,可以自己试着在PC(无论多牛的配置)用access+SQL,看看能否完成同时 ...
老兄,
你拿 access 完成每秒2万查询?还要更新,还要回滚?
access本来就不是干这个级别的活
这样测试有什么意义?
各位觉得淘宝的做得如何?  类似于光棍节狂欢,我之前看到如下描述:  
只能告诉你没有可比性,qq还同时几亿在线呢。。
诸葛没亮 发表于 2012-9-26 16:34
只能告诉你没有可比性,qq还同时几亿在线呢。。
那么不看日PV ,不看在线,
我们来看最终结果——订单处理量如何?
忘情的博客里引用文章说的
淘宝可以每小时处理完成60万订单
这样算下来 一周在1亿左右

我查询了下 2012春节铁路发送旅客量 2.35亿人次
http://politics.people.com.cn/GB/101380/17130953.html

抛开不能网络购票的、电话订票的、现场发售的,您觉得还剩多少?算50% 约为1.17亿如何,实际上这个比例是看高了的,还有网上可以预售12天的票,这1.17亿,交给系统处理的时间要比淘宝的多的多
这样算下来,您怎么看?
壮东风 发表于 2012-9-26 07:33
未必全对。
这篇文章很准确地指出了症结,后面的技术改进措施跟一般思路差不多,仅作参考即可。
物理 ...
没有具体的数据,说这些没有意义。

你看看25楼的说法吧,我的想法跟他一样,就是通过分布式布置减少无效访问。

如果铁道部能建立一个能媲美沃尔玛的数据中心,拥有足够的处理能力,集中式数据中心一样行的通。
诸葛没亮 发表于 2012-9-21 18:11
世界上没有任何一个网站的服务器承受的压力大于铁道部的,铁道部一直在努力。
设计理念落后 还好意思拿来做借口。
铁道部的思路很古怪,为什么要在客流量高峰升级系统?打怪升级还的从小怪开始。上线的时候是春节,被骂死,升级是国庆,都是高峰期,再强悍的服务器和流量也顶不住这么大的数据量啊,而且根本就不会给系统留下优化的时间。

laoQ 发表于 2012-9-26 19:41
那么不看日PV ,不看在线,
我们来看最终结果——订单处理量如何?
忘情的博客里引用文章说的


这个不具对比性吧。淘宝的交易可以分布性。各个交易之间无联系。而且也较少在同一交易点出现暴力点击事件

而铁路,一个火车一个班次聚集巨大的暴力点击点。

至于你说的数据,你还不如直接按此文提供的“从1月1日到1月7日日均访问量超过10亿次。”
访问量是10亿次。而淘宝按你的算法是1亿左右。

最后,其实就算网站不瘫痪(现在这种等待方法已经算不瘫痪了),最根本的票源与节假日爆发的需求完全不能匹配。肯定会
出现很多人买不到票的。而只要有少数人买不到票就足够在网络上放大影响了
laoQ 发表于 2012-9-26 19:41
那么不看日PV ,不看在线,
我们来看最终结果——订单处理量如何?
忘情的博客里引用文章说的


这个不具对比性吧。淘宝的交易可以分布性。各个交易之间无联系。而且也较少在同一交易点出现暴力点击事件

而铁路,一个火车一个班次聚集巨大的暴力点击点。

至于你说的数据,你还不如直接按此文提供的“从1月1日到1月7日日均访问量超过10亿次。”
访问量是10亿次。而淘宝按你的算法是1亿左右。

最后,其实就算网站不瘫痪(现在这种等待方法已经算不瘫痪了),最根本的票源与节假日爆发的需求完全不能匹配。肯定会
出现很多人买不到票的。而只要有少数人买不到票就足够在网络上放大影响了
laoQ 发表于 2012-9-26 15:43
各位觉得淘宝的做得如何?
类似于光棍节狂欢,我之前看到如下描述:
没有可比性吧,淘宝那个是分布式的,12306这个是集中式的。


从用户角度来说,集中也好 ,分布也好, 那是架构的问题
用户只管用户体验,
做得烂,难道就可以说:我是集中式?

从用户角度来说,集中也好 ,分布也好, 那是架构的问题
用户只管用户体验,
做得烂,难道就可以说:我是集中式?