12306外包给阿里巴巴/IBM到底是否可行?

来源:百度文库 编辑:超级军网 时间:2024/04/27 21:36:26
春运开始以后12306免不了要罢工几次,毕竟人民群众买票回家的热情实在是高涨,12306很难承受如此大的压力。每次12306网站罢工以后都会有人忍不住对其进行吐槽,而还有人认为如果把12306外包给IBM或者阿里巴巴来做的话效果一定会比现在要好。但是事实真的是这样吗?IBM和阿里巴巴真的有这样的能力吗?我们来看看知乎用户王强给我们做出的解答吧。
12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案,给出的条件是资金管够但是问题得解决。几大企业最后都拒绝了。12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方案都不足以应付春运购票负载,所以只能自己改进已有的数据库以前12306用的是小型机,发现性能严重不足,遂改用x86系统+linux平台(原平台为HP Superdome小型机,UNIX系统,Sybase ASE数据库)。最后他们的核心系统用了十几个节点(现在应该是17节点)的多路Xeon E7(具体几路待考),每个节点配1TB内存,数据库全部在内存中运行。2013年春运,12306系统峰值负载11万tps,与2012年淘宝双11活动峰值负载相当,新的系统基本经受住了考验。
补充:以上内容是我在2013年7月得知的信息,彼时没有任何公开来源提到过12306新系统的技术细节。甚至,当时局外人没人知道12306已经在2012年开始做了技术改造。直到数日之前,铁总首次向媒体公开了技术改造的详情:分布式集群内存数据技术引领12306技术革命。这篇文章给出的细节,与我之前看到的内容完全一致。由此我可以确信信息来源是此次技术升级的核心人士。
另外,关于第三方合作对方给出的信息是IBM、Oracle、Sybase全部不能满足要求,主要是这些厂商的方案部署以后,要升级时不能做到不停机灵活扩展。也就是说,IBM没有做到是他们技术不足“搞不定”。阿里巴巴参与了改造,负责了排队系统。此外,虽然后端经受住了压力,前端却如大家所看到的那样还是频频卡死。到底卡死的原因是前端水平太低还是访问压力太大,暂时没有可靠的信息供判断。
淘宝的问题是其系统架构是分散度较高的,各个订单之间关联度不大;而12306每出一张票都要对全线路做数据更新(因为一条线路存在多个站点),因此系统负载相较淘宝来说集中很多,直接搬淘宝的方案也无法解决问题。淘宝的应用类型决定了阿里巴巴可以通过部署大量的服务器来分散压力,但12306就不行。其实他们的核心系统的硬件成本不过数百万,不是他们不想采购更多服务器,而是买更多的服务器也没什么用途。最后,在经过软件层面的优化之后,12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情,而是受限于摩尔定律,基本上每两年才能翻一倍多些。(这段话是我自己的分析,不过现在12306的后端数据库系统应付现有需求已经够用了)
补充:关于座位实时复用,我看到的信息明确表明12306出票时,每出一张区间票都要实时调整该线路其他受影响区间段的余票数量,且这是很大的压力来源;另外,对方表示所使用的GemFire数据库与简单的memcache/redis数据缓冲不同,有着本质区别。
然后我说点对铁路系统购票困难现象的看法:
一种商品只要出现供不应求现象,那么结果只有两种:大家排队购买;出现黑市,变相提高商品的流通价格并抑制需求。
12306这个事情,就是标准的限价商品供不应求之后出现排队与黑市现象的例子。因为供不应求,所以有了黄牛、抢票软件与秒杀。如果供应充足,一个车次直到发车前都有一两张余票,那么黄牛、抢票就毫无存在价值,旅客也用不着守在电脑前和其他人比拼手速和网速以及电脑性能网络性能了。
现在供应不足的前提下,12306就算把系统做的性能再高,也只是会加快热门车次票务秒杀的速度而已——而这更会刺激抢票软件,大家为了在更短的时间里成功抢到队列名额就会不断提升自己的抢票性能。打个比方说就是一个店门前排队,消费者为了增加买到商品的概率去雇人代排,每个消费者都雇了好多人,造成店门口的通道拥挤不堪。为了减缓拥堵,商家不断拓宽通道,但每次一拓宽消费者们就会增加雇佣的排队劳力把新增的通道空间占满,形成恶性循环。这样下去,只要还存在供不应求的现象,这种循环就不会有终止的时候。也就是说,12306的问题主要不是出在网站本身。
那么怎样解决供应不足的问题?这么多年来铁路不断升级运力修建新线,已经建成全球最庞大的铁路运输系统,可是到了春运还是只能勉强应付。从这个角度来说铁路部门在供应不足的问题上也不该承担太大责任,他们已经做得很不错了。
那么问题的根源就出在不断增加的需求上了。为什么我国铁路系统需要承担如此庞大的客运流量需求?很显然,是因为全国范围的人口流动。大量务工上学人员过节要返乡,节后回驻地,这个刚性需求是合理的。可是为什么他们必须要到外地去打工上学?为什么数以亿计的人员要远离家乡去谋生求学?
最后我们会发现,区域发展不平衡才是罪魁祸首。正因为多少人在家乡无法得到足够的机会与资源,他们必须到发达地区奋斗和实现自己的价值。只要这种不平衡现象还在继续,每年春节前后就不可避免地出现大批人员全国范围流动的情况,就不可避免地出现运输能力不足的尴尬。改进12306也好,增加铁路网投资也好,最终都只是治标不治本。如果这个社会不去直面根本问题,那么这些表象的症结永无解开的时候。
说起来,有几个人愿意背井离乡呢?
然后这个问题争了几天,我实在忍不住要吐槽一下了:
12306这个事情,网上有多少网友从一开始就献计献策了,也有不少网友提供了很不错的建议。但不得不说,很多网友在提建议时完全就是一种居高临下、自以为是的态度,上来就先认定需求简单可以轻松应付,随便有点经验的工程师就能搞定,12306出问题全怪体制太烂,国企效率低下,一帮人光拿钱不做事,技术水平太低……
淘宝2013年双11活动,峰值流量是一秒钟完成1.3万笔订单。12306在2014年1月6日全天网络出票400万张。看起来双11流量完爆12306是吧?等等!别忘了12306这400万张票可不是全天悠悠闲闲平均地卖出去的,而是分成10个时段集中被抢走的。每个时段开始放票后数分钟之内大部分票就已经被抢光了。以每个时段40万票,峰值持续三分钟估算,高峰期一分钟出票在10万张以上毫不夸张。诚然,一分钟10万订单还比不上淘宝2013双11,但别忘了一年以前阿里巴巴也只是达到了一分钟15万订单的水平而已(并且在高峰期一样卡爆)。而且一分钟10万出票还满足不了需求的,以旅客购票的热情来看,达到一分钟50万票都不一定能让所有旅客满意。
淘宝在2012年双11时已经是业界顶尖水平了,其软硬件技术皆为自主研发,既便如此面对一分钟十几万的订单量都会卡死。请问,觉得12306“需求简单,问题可以轻松解决”的,是不是水平已经高到了阿里巴巴都要请你们去领导整个技术团队的级别呢?是不是你们的方案可以轻松应付每分钟数十万笔订单,达到全球一流水平了?
淘宝面临的需求是业界从未有过的,所以淘宝的路很艰难。12306面临的需求是其他人遇到过的么?全世界哪个国家、哪种客运票务系统敢说自己的负载达到12306三分之一的水平?面对空前庞大的压力,诸位“技术高手”只是凭着自己一点程序员的经验,在电脑前一个人思考上一会儿就给出个“简单、实用、省钱、轻松应付”的解决方案——你们知不知道“自大”这两个字怎么写啊?
作为局外人,本来就难以了解铁路售票系统内部的业务逻辑。想出建议可以,那么是不是先收集些信息,了解下背景?是不是先拉出一份需求清单来,把客户的想法搞明白搞清楚了,然后再考虑技术实现?能不能不要上来就想着技术上怎么方便怎么做,把客户需求随意地简化?好多人提的方案在票务供应不足的情况下直接就超售了,难道你要让旅客前一分钟还为订到票高兴,下一分钟对着“您的票被取消”的提示破口大骂么?或者订票延迟确认——知不知道旅客看到选择的车次没能买到票后会做什么?马上去看其他车次有没有票啊!你延迟确认几分钟,然后对排队的账户做抽签,多少旅客会觉得自己被耽误了啊!旅客的要求就是速度越快越好,最好是下订单后一秒钟出结果才安心哩。这还仅仅是简单想一下就能知道的问题,局外人不了解或不能轻易想到的问题又有多少?诸位高谈阔论时,有没有虚心地去找找内部人士了解或者搜索类似的票务系统的研究论文?真觉得自己的头脑聪明绝顶,连背景调查都不做就可以轻松把握所有细节?还有,你们想出来的方案做没做过实验啊?考虑没考虑过硬件适配性啊?你们了解现在市面上能买到的硬件系统,什么样级别的能满足可靠性、性能和可扩展性、可维护性的需求么?你们在多路服务器平台上验证过你们的分布式数据库构想么?哦原来你们什么都没做过,怕是连多节点集群互联该用什么连接方式都不知道,你们拍下脑瓜,一句“那些问题都好解决”就完事儿了?就算你们自己没做过,找找类似的案例会累死么?研究下别人做过的经验就不够高贵冷艳么?就贬低自己技术水平了么?连类似的案例研究都没有,随口就是别人做得到我做得到,真觉得自己写过几行代码就多么伟大了么?
还有一些人,看说IBM没做就一口认定是12306故意排挤IBM,认定IBM解决这问题肯定没压力。好嘛,IBM什么时候做过如此规模的票务系统了?你细节什么都不知就预设结论了?为啥淘宝当年没选择IBM作为方案提供商而是自主研发?IBM的大数据业务主要集中在金融领域,这不代表它在其他领域就样样精通好不好?它能拿出的方案无非是Power7小型机平台,Power7在数据库性能上又比Xeon E7强多点?然后Power7系统卖多少钱了解么?后续维护难度多大了解么?把适合银行金融行业的平台放到12306来真的合适么?说起来,不就是因为“12306”和“IBM”这俩名字放一起,诸位内心里首先就给前者打了负分对后者仰视么?要是把“12306”换成“nasdaq”,那结论就又是一回事儿了——哦正好nasdaq没用IBM方案,可见nasdaq是排挤IBM内部人赚黑心钱是吧?不过2013年工商银行系统升级故障,应该是和方案提供商IBM无关的,肯定是国企的体制问题无误!
评价一个事物,首先不是了解背景、研究问题产生的原因,首先是看被评价者处于什么立场,打着什么标签。如果是“敌对阵营”那就毫不犹豫地踩上一脚再说话,接下来就算研究也只研究“它的错误在哪儿”,不考虑“它也有对的可能性”。在12306这个问题上就是:12306是国企,是铁总下属机构,所以它出了问题一定是自身原因。票务系统做不好一定是铁路方面不懂技术,把该用来请大企业做方案的钱自己贪掉了,一定不可能是大企业都没信心解决这问题。旅客普遍使用抢票软件也是12306的责任,不是供应不足的原因……
最后呢?12306还是做到了全球最强的客运票务系统。一贯被认为是因循守旧的国企,在选择技术方案时放弃沿用多年的小型机/UNIX平台去拥抱业界还是新鲜事物的基于x86/linux的大规模分布内存数据库系统,承受住了堪比2012年淘宝双11的压力。在这个领域,12306可以自豪地说自己是做的最好的案例。它还在卡,还是偶尔崩溃,页面还是难看,可是这些迟早会改进。这个过程中也还是会有冷嘲热讽,还是会有所谓的大牛指点江山,但最终解决春运高峰期一天数百万张秒杀售票的,还是12306自己。
所以,走自己的路,让别人去说吧。
http://news.mydrivers.com/1/289/289332.htm

春运开始以后12306免不了要罢工几次,毕竟人民群众买票回家的热情实在是高涨,12306很难承受如此大的压力。每次12306网站罢工以后都会有人忍不住对其进行吐槽,而还有人认为如果把12306外包给IBM或者阿里巴巴来做的话效果一定会比现在要好。但是事实真的是这样吗?IBM和阿里巴巴真的有这样的能力吗?我们来看看知乎用户王强给我们做出的解答吧。
12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案,给出的条件是资金管够但是问题得解决。几大企业最后都拒绝了。12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方案都不足以应付春运购票负载,所以只能自己改进已有的数据库以前12306用的是小型机,发现性能严重不足,遂改用x86系统+linux平台(原平台为HP Superdome小型机,UNIX系统,Sybase ASE数据库)。最后他们的核心系统用了十几个节点(现在应该是17节点)的多路Xeon E7(具体几路待考),每个节点配1TB内存,数据库全部在内存中运行。2013年春运,12306系统峰值负载11万tps,与2012年淘宝双11活动峰值负载相当,新的系统基本经受住了考验。
补充:以上内容是我在2013年7月得知的信息,彼时没有任何公开来源提到过12306新系统的技术细节。甚至,当时局外人没人知道12306已经在2012年开始做了技术改造。直到数日之前,铁总首次向媒体公开了技术改造的详情:分布式集群内存数据技术引领12306技术革命。这篇文章给出的细节,与我之前看到的内容完全一致。由此我可以确信信息来源是此次技术升级的核心人士。
另外,关于第三方合作对方给出的信息是IBM、Oracle、Sybase全部不能满足要求,主要是这些厂商的方案部署以后,要升级时不能做到不停机灵活扩展。也就是说,IBM没有做到是他们技术不足“搞不定”。阿里巴巴参与了改造,负责了排队系统。此外,虽然后端经受住了压力,前端却如大家所看到的那样还是频频卡死。到底卡死的原因是前端水平太低还是访问压力太大,暂时没有可靠的信息供判断。
淘宝的问题是其系统架构是分散度较高的,各个订单之间关联度不大;而12306每出一张票都要对全线路做数据更新(因为一条线路存在多个站点),因此系统负载相较淘宝来说集中很多,直接搬淘宝的方案也无法解决问题。淘宝的应用类型决定了阿里巴巴可以通过部署大量的服务器来分散压力,但12306就不行。其实他们的核心系统的硬件成本不过数百万,不是他们不想采购更多服务器,而是买更多的服务器也没什么用途。最后,在经过软件层面的优化之后,12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情,而是受限于摩尔定律,基本上每两年才能翻一倍多些。(这段话是我自己的分析,不过现在12306的后端数据库系统应付现有需求已经够用了)
补充:关于座位实时复用,我看到的信息明确表明12306出票时,每出一张区间票都要实时调整该线路其他受影响区间段的余票数量,且这是很大的压力来源;另外,对方表示所使用的GemFire数据库与简单的memcache/redis数据缓冲不同,有着本质区别。
然后我说点对铁路系统购票困难现象的看法:
一种商品只要出现供不应求现象,那么结果只有两种:大家排队购买;出现黑市,变相提高商品的流通价格并抑制需求。
12306这个事情,就是标准的限价商品供不应求之后出现排队与黑市现象的例子。因为供不应求,所以有了黄牛、抢票软件与秒杀。如果供应充足,一个车次直到发车前都有一两张余票,那么黄牛、抢票就毫无存在价值,旅客也用不着守在电脑前和其他人比拼手速和网速以及电脑性能网络性能了。
现在供应不足的前提下,12306就算把系统做的性能再高,也只是会加快热门车次票务秒杀的速度而已——而这更会刺激抢票软件,大家为了在更短的时间里成功抢到队列名额就会不断提升自己的抢票性能。打个比方说就是一个店门前排队,消费者为了增加买到商品的概率去雇人代排,每个消费者都雇了好多人,造成店门口的通道拥挤不堪。为了减缓拥堵,商家不断拓宽通道,但每次一拓宽消费者们就会增加雇佣的排队劳力把新增的通道空间占满,形成恶性循环。这样下去,只要还存在供不应求的现象,这种循环就不会有终止的时候。也就是说,12306的问题主要不是出在网站本身。
那么怎样解决供应不足的问题?这么多年来铁路不断升级运力修建新线,已经建成全球最庞大的铁路运输系统,可是到了春运还是只能勉强应付。从这个角度来说铁路部门在供应不足的问题上也不该承担太大责任,他们已经做得很不错了。
那么问题的根源就出在不断增加的需求上了。为什么我国铁路系统需要承担如此庞大的客运流量需求?很显然,是因为全国范围的人口流动。大量务工上学人员过节要返乡,节后回驻地,这个刚性需求是合理的。可是为什么他们必须要到外地去打工上学?为什么数以亿计的人员要远离家乡去谋生求学?
最后我们会发现,区域发展不平衡才是罪魁祸首。正因为多少人在家乡无法得到足够的机会与资源,他们必须到发达地区奋斗和实现自己的价值。只要这种不平衡现象还在继续,每年春节前后就不可避免地出现大批人员全国范围流动的情况,就不可避免地出现运输能力不足的尴尬。改进12306也好,增加铁路网投资也好,最终都只是治标不治本。如果这个社会不去直面根本问题,那么这些表象的症结永无解开的时候。
说起来,有几个人愿意背井离乡呢?
然后这个问题争了几天,我实在忍不住要吐槽一下了:
12306这个事情,网上有多少网友从一开始就献计献策了,也有不少网友提供了很不错的建议。但不得不说,很多网友在提建议时完全就是一种居高临下、自以为是的态度,上来就先认定需求简单可以轻松应付,随便有点经验的工程师就能搞定,12306出问题全怪体制太烂,国企效率低下,一帮人光拿钱不做事,技术水平太低……
淘宝2013年双11活动,峰值流量是一秒钟完成1.3万笔订单。12306在2014年1月6日全天网络出票400万张。看起来双11流量完爆12306是吧?等等!别忘了12306这400万张票可不是全天悠悠闲闲平均地卖出去的,而是分成10个时段集中被抢走的。每个时段开始放票后数分钟之内大部分票就已经被抢光了。以每个时段40万票,峰值持续三分钟估算,高峰期一分钟出票在10万张以上毫不夸张。诚然,一分钟10万订单还比不上淘宝2013双11,但别忘了一年以前阿里巴巴也只是达到了一分钟15万订单的水平而已(并且在高峰期一样卡爆)。而且一分钟10万出票还满足不了需求的,以旅客购票的热情来看,达到一分钟50万票都不一定能让所有旅客满意。
淘宝在2012年双11时已经是业界顶尖水平了,其软硬件技术皆为自主研发,既便如此面对一分钟十几万的订单量都会卡死。请问,觉得12306“需求简单,问题可以轻松解决”的,是不是水平已经高到了阿里巴巴都要请你们去领导整个技术团队的级别呢?是不是你们的方案可以轻松应付每分钟数十万笔订单,达到全球一流水平了?
淘宝面临的需求是业界从未有过的,所以淘宝的路很艰难。12306面临的需求是其他人遇到过的么?全世界哪个国家、哪种客运票务系统敢说自己的负载达到12306三分之一的水平?面对空前庞大的压力,诸位“技术高手”只是凭着自己一点程序员的经验,在电脑前一个人思考上一会儿就给出个“简单、实用、省钱、轻松应付”的解决方案——你们知不知道“自大”这两个字怎么写啊?
作为局外人,本来就难以了解铁路售票系统内部的业务逻辑。想出建议可以,那么是不是先收集些信息,了解下背景?是不是先拉出一份需求清单来,把客户的想法搞明白搞清楚了,然后再考虑技术实现?能不能不要上来就想着技术上怎么方便怎么做,把客户需求随意地简化?好多人提的方案在票务供应不足的情况下直接就超售了,难道你要让旅客前一分钟还为订到票高兴,下一分钟对着“您的票被取消”的提示破口大骂么?或者订票延迟确认——知不知道旅客看到选择的车次没能买到票后会做什么?马上去看其他车次有没有票啊!你延迟确认几分钟,然后对排队的账户做抽签,多少旅客会觉得自己被耽误了啊!旅客的要求就是速度越快越好,最好是下订单后一秒钟出结果才安心哩。这还仅仅是简单想一下就能知道的问题,局外人不了解或不能轻易想到的问题又有多少?诸位高谈阔论时,有没有虚心地去找找内部人士了解或者搜索类似的票务系统的研究论文?真觉得自己的头脑聪明绝顶,连背景调查都不做就可以轻松把握所有细节?还有,你们想出来的方案做没做过实验啊?考虑没考虑过硬件适配性啊?你们了解现在市面上能买到的硬件系统,什么样级别的能满足可靠性、性能和可扩展性、可维护性的需求么?你们在多路服务器平台上验证过你们的分布式数据库构想么?哦原来你们什么都没做过,怕是连多节点集群互联该用什么连接方式都不知道,你们拍下脑瓜,一句“那些问题都好解决”就完事儿了?就算你们自己没做过,找找类似的案例会累死么?研究下别人做过的经验就不够高贵冷艳么?就贬低自己技术水平了么?连类似的案例研究都没有,随口就是别人做得到我做得到,真觉得自己写过几行代码就多么伟大了么?
还有一些人,看说IBM没做就一口认定是12306故意排挤IBM,认定IBM解决这问题肯定没压力。好嘛,IBM什么时候做过如此规模的票务系统了?你细节什么都不知就预设结论了?为啥淘宝当年没选择IBM作为方案提供商而是自主研发?IBM的大数据业务主要集中在金融领域,这不代表它在其他领域就样样精通好不好?它能拿出的方案无非是Power7小型机平台,Power7在数据库性能上又比Xeon E7强多点?然后Power7系统卖多少钱了解么?后续维护难度多大了解么?把适合银行金融行业的平台放到12306来真的合适么?说起来,不就是因为“12306”和“IBM”这俩名字放一起,诸位内心里首先就给前者打了负分对后者仰视么?要是把“12306”换成“nasdaq”,那结论就又是一回事儿了——哦正好nasdaq没用IBM方案,可见nasdaq是排挤IBM内部人赚黑心钱是吧?不过2013年工商银行系统升级故障,应该是和方案提供商IBM无关的,肯定是国企的体制问题无误!
评价一个事物,首先不是了解背景、研究问题产生的原因,首先是看被评价者处于什么立场,打着什么标签。如果是“敌对阵营”那就毫不犹豫地踩上一脚再说话,接下来就算研究也只研究“它的错误在哪儿”,不考虑“它也有对的可能性”。在12306这个问题上就是:12306是国企,是铁总下属机构,所以它出了问题一定是自身原因。票务系统做不好一定是铁路方面不懂技术,把该用来请大企业做方案的钱自己贪掉了,一定不可能是大企业都没信心解决这问题。旅客普遍使用抢票软件也是12306的责任,不是供应不足的原因……
最后呢?12306还是做到了全球最强的客运票务系统。一贯被认为是因循守旧的国企,在选择技术方案时放弃沿用多年的小型机/UNIX平台去拥抱业界还是新鲜事物的基于x86/linux的大规模分布内存数据库系统,承受住了堪比2012年淘宝双11的压力。在这个领域,12306可以自豪地说自己是做的最好的案例。它还在卡,还是偶尔崩溃,页面还是难看,可是这些迟早会改进。这个过程中也还是会有冷嘲热讽,还是会有所谓的大牛指点江山,但最终解决春运高峰期一天数百万张秒杀售票的,还是12306自己。
所以,走自己的路,让别人去说吧。
http://news.mydrivers.com/1/289/289332.htm
12306做的还是不错的!很多人把网络售票想的太简单了!
复杂无比的系统,要和电话,窗口售票联动!麻烦!
其实可以退票必须窗口实名退,看黄牛玩啥?
12306做的很不错了,每每见到关于12306新闻的评论,都不由的想说,中国人就不适合有言论自由
淘宝哪年的秒杀活动能顺顺利利了?还不是好几个小时无法付款?

对于抢票这种集中突发的访问,还真是难以招架。何况有大量的刷票软件在增加服务器的负担。
想解决有个好办法,学印度提前半年售票……
想解决有个好办法,学印度提前半年售票……
不过这样12306是压力小了,黄牛高兴死了……
10个人只有一张票的情况下

任何售票系统都解决不了这个问题

当然还是要吐槽一下12306的界面UI以及各种毛病
最大侠 发表于 2014-1-10 12:00
10个人只有一张票的情况下

任何售票系统都解决不了这个问题
12306有新版界面,似乎改善很多,在火狐中可以使用,linux上也没碰到问题。
老版界面确实问题多多,我觉得主要有2个:
1、IE Only,那个证书毫无意义。
2、网页有低级漏洞,比如把生成的座位号码简单地隐藏了一下传回浏览器,再提交回去,而不是用服务端会话,很容易让人随意选位。
“火车票票价过低导致黄牛党盛行”

你看,汽车就没有黄牛党。
想解决有个好办法,学印度提前半年售票……
看来印度铁路新建的几乎没有啊。
10个人只有一张票的情况下

任何售票系统都解决不了这个问题

kyfw.12306.cn 很不错的。
虽然我今年抢票比较失败,但就12306网站而言,比往年进步了,如果能马上连接公安部及检验恶意ip炒票,那就更好了
就怕光棍节火车票五折。来自: iPhone客户端
想解决有个好办法,学印度提前半年售票……
现在比较重要的新线投入使用,铁路的运行图都会调整一次。
关于座位实时复用,我看到的信息明确表明12306出票时,每出一张区间票都要实时调整该线路其他受影响区间段的余票数量,且这是很大的压力来源;另外,对方表示所使用的GemFire数据库与简单的memcache/redis数据缓冲不同,有着本质区别。............. 这段话是重点
说一千道一万, 还是太烂, 无论怎么洗地, 都逃不了一个烂字.    流量大, 并发高, 都有N种方法可以解决的. 一开始选择自己建设, 就是错中错.

难道一下子购置海量的机器就为春运这一段时间?  无论带宽还是硬件资源利用率极低.  

还有若干可以大批特批的东西就懒得吐槽了.
说一千道一万, 还是太烂, 无论怎么洗地, 都逃不了一个烂字.    流量大, 并发高, 都有N种方法可以解决的. 一 ...
来,吐几个点让大家看看吧?
说一千道一万, 还是太烂, 无论怎么洗地, 都逃不了一个烂字.    流量大, 并发高, 都有N种方法可以解决的. 一 ...
不要无聊乱吐!药能治病,出了问题后才知道不是什么人都能用。微软的系统都还要更新,你怎么还去用?
12306的问题压根就不是系统问题,而是思路问题

从经济学的角度来说,黄牛恰恰在行政管制之下起到了难得的价格发现作用;价格回归均衡了,抢票神马的自然也就木有了
哪里看过这篇,楼主是知乎摘来的么?
我对这篇文章的批驳写在这个帖子里面的,我构想的算法也写在这个帖子里了。
在重复一遍,这个网站的问题,真的不是 TPS 的问题。

http://bbs.9ifly.cn/forum.php?mod=viewthread&tid=13028
暗夜流星 发表于 2014-1-10 16:29
我对这篇文章的批驳写在这个帖子里面的,我构想的算法也写在这个帖子里了。
在重复一遍,这个网站的问题, ...
你设想的就是排队网络化,基本上互联网的方便丧失殆尽,而且估计他们早就想过了。
TPS是一个计量标准,跟你说的无效流量什么的不矛盾。

醉后一支舞 发表于 2014-1-10 15:20
不要无聊乱吐!药能治病,出了问题后才知道不是什么人都能用。微软的系统都还要更新,你怎么还去用?


就最初版本的网页UI, 也就做网站中的小学生水平吧. 虽然说经过若干改版, 现在好点了, 但是几年了? 就这改版的速度, 如果不骂他们, 不知猴年马月才能改成这模样.

这么大流量是有难度. 但具体到工程上, 就是个问题拆解的问题.

说个最笨的方法吧, 既然网站被人刷爆了, 为啥不用传统的cs结构呢? 至少不会让人直接解析html代码, 去刷你的服务器. 也可以很方便控制各种节奏, 服务器压力一下子可以下几个量级.



如果还为这几年12306的低劣的表现去洗地, 实在不知该说什么了.


醉后一支舞 发表于 2014-1-10 15:20
不要无聊乱吐!药能治病,出了问题后才知道不是什么人都能用。微软的系统都还要更新,你怎么还去用?


就最初版本的网页UI, 也就做网站中的小学生水平吧. 虽然说经过若干改版, 现在好点了, 但是几年了? 就这改版的速度, 如果不骂他们, 不知猴年马月才能改成这模样.

这么大流量是有难度. 但具体到工程上, 就是个问题拆解的问题.

说个最笨的方法吧, 既然网站被人刷爆了, 为啥不用传统的cs结构呢? 至少不会让人直接解析html代码, 去刷你的服务器. 也可以很方便控制各种节奏, 服务器压力一下子可以下几个量级.



如果还为这几年12306的低劣的表现去洗地, 实在不知该说什么了.

壮东风 发表于 2014-1-10 16:40
你设想的就是排队网络化,基本上互联网的方便丧失殆尽,而且估计他们早就想过了。
TPS是一个计量标准, ...
这是一个公平可行的方法。
而且很方便。
如果某条线路运力空闲,排队速度可以加快。
如果运力吃紧,排队是很好的。
银行医院都在用,我不认为有什么 “丧失殆尽”。
所谓 TPS,只有在有效流量的时候,谈 TP
netxiao1 发表于 2014-1-10 16:41
就最初版本的网页UI, 也就做网站中的小学生水平吧. 虽然说经过若干改版, 现在好点了, 但是几年了? 就这改 ...
前端和后端不是一回事,前端确实做得不怎么样,后端现在看来水平还不低。
只有在有效流量的时候,谈 TPS 才有意义,否则就是傻干,白跑路很有意思?
壮东风 发表于 2014-1-10 16:44
前端和后端不是一回事,前端确实做得不怎么样,后端现在看来水平还不低。
这种东西,清华这种的随便找几个本科生就干了。
其他好点的,研究生吧。
我对这篇文章的批驳写在这个帖子里面的,我构想的算法也写在这个帖子里了。
在重复一遍,这个网站的问题, ...
凡是想用排队系统降低流量的都是未能全面考虑问题的。
deam 发表于 2014-1-10 16:46
凡是想用排队系统降低流量的都是未能全面考虑问题的。
敬请指教。

壮东风 发表于 2014-1-10 16:44
前端和后端不是一回事,前端确实做得不怎么样,后端现在看来水平还不低。


我觉得用cs客户端更好, 那样可以选择用长连接, 模拟电路交换的方式, 订票可靠性高很多, web服务的短连接方式, 往往登录进去系统了, 也不见得能定成功, 导致用户不断刷页面, 凭白增加N多垃圾流量,让系统忙坏, 大家都挤在一块, 都抢不到票.

而且还可以避免现在那帮用chrome内核的浏览器刷票.
壮东风 发表于 2014-1-10 16:44
前端和后端不是一回事,前端确实做得不怎么样,后端现在看来水平还不低。


我觉得用cs客户端更好, 那样可以选择用长连接, 模拟电路交换的方式, 订票可靠性高很多, web服务的短连接方式, 往往登录进去系统了, 也不见得能定成功, 导致用户不断刷页面, 凭白增加N多垃圾流量,让系统忙坏, 大家都挤在一块, 都抢不到票.

而且还可以避免现在那帮用chrome内核的浏览器刷票.
敬请指教。
你可以去看知乎答案更新后下面的说明。
netxiao1 发表于 2014-1-10 16:47
我觉得用cs客户端更好, 那样可以选择用长连接, 模拟电路交换的方式, 订票可靠性高很多, web服务的短连 ...
客户端要考虑用户适应的问题,而且更容易被抢票软件利用。
deam 发表于 2014-1-10 16:48
你可以去看知乎答案更新后下面的说明。
我觉得这个网站水平很低。
呃,俺从来没用过12306的算什么捏……
这种烂文章居然有 5000 多个赞
deam 发表于 2014-1-10 16:46
凡是想用排队系统降低流量的都是未能全面考虑问题的。
排队还是不可避免的. 狼多肉少, 资源紧缺没办法, 还有很多tq票源,我经历买不到票, 上车一看, 一堆空座位, 到开车, 座位还空着
我觉得这个网站水平很低。
你是说知乎?

水平另说,今天答案更新后针对排队方案做了分析。
deam 发表于 2014-1-10 16:51
你是说知乎?

水平另说,今天答案更新后针对排队方案做了分析。
贴上来我看看,或者给个连接。
这种烂文章居然有 5000 多个赞
嘛,你可以说说烂在哪儿呗。
贴上来我看看,或者给个连接。

本帖首楼就有。第一段末尾。