12306 外包给阿里巴巴、IBM 等大企业做是否可行?

如果 12306 项目外包给阿里巴巴或 IBM 等大企业,会不会更好
按票数排序 按时间排序

348 个回答

12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案,给出的条件是资金管够但是问题得解决。几大企业最后都拒绝了(其中阿里巴巴最后负责了排队系统的建设)。12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方案都不足以应付春运购票负载,所以只能自己改进已有的数据库(注:其实是改用VMware SQLFire/GemFire,这里我之前理解错误)。以前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自己。


所以,走自己的路,让别人去说吧。

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

下面我说说12306系统改进面临的一些问题,一些网友提出的解决方案的可行性。


1.“超级计算机能不能用于12306?”——不能,详情见这个页面


2.“能不能用一个服务器甚至一个集群处理一个车次来加快速度?”——没有意义,处理速度在硬件上主要受限于每个CPU线程获得的内存带宽与延迟,其中内存延迟更重要一些。一个核心处理还是一台服务器处理,内存延迟这个参数是没什么区别的;


3.“能不能在多地建立集群,分别处理某地的车次?”——道理同上;


4.“能不能取消座位实时复用,降低处理压力?”——如果所有区间站的票数都是预先确定的,那么到最后必然会出现有的冷门区间座位空置的情况,这是旅客不希望看到的;


5.“能不能把座位实时复用改为延时复用,热门车次第一次放票后,根据区间之间的情况在下一个放票点调整各区间票额?”——这样做可以减轻计算压力,但是会让大量旅客在第一次订票失败后等待下一次放票,增加下一次放票的负载。而且这会干扰旅客的抢票计划,原来是一个车次没票后就去找下一个车次,现在是一个车次要抢两次甚至更多,反而让旅客更累;


6.“能不能改成预先排队抽签,放票前订票旅客在网上选择进入队列,放票后抽签决定,避免争抢”——很多人提出类似这样的主意。注意热门车次放票被抢光后,没买到票的旅客会立刻去找其他车次是否有票。也就是说即便有这个预排队功能,也不能阻止没去排队的旅客在放票开始之后去买票。对于热门车次而言,参与预排队的旅客抽签失败的概率非常高,而他们抽签失败后多数会失去对这个功能的信任,转而继续选择抢票的方式,于是很快大多数人都会放弃抽签。如果设定为只有参与预排队的旅客才能买到票,那么抽签失败的旅客就失去了对其他车次的选择权,结果更是一场灾难。希望提出类似方案的网友好好思考我上面这些内容。


7.“12306的负载不是比淘宝小很多么?”——淘宝2013年双11峰值订单数量一分钟79万笔,12306每次放票按500热门车次算,根据央视直播春运火车票抢票 这篇报道,热门车次峰值抢票速度在每分钟500票左右。很容易算出现在12306的峰值订单量在一分钟10万-30万的级别,与淘宝双11峰值是相同数量级。


我在前面提过供求关系是12306面临的核心问题,可能很多没有经济学基础的网友不太明白,我这里再详细解释下。


任何限价商品出现供不应求情况时,最终获得商品的大多数消费者支付的成本都是要超出商品本身的标价的。一个简单的例子,超市限量出售半价鸡蛋,大批顾客去抢购,虽然排队买到的顾客为鸡蛋本身花的钱少了,但是这些顾客付出了在那里排队的时间和人力成本。排了很久队才买到鸡蛋的顾客,为鸡蛋支付的时间与人力成本甚至可能超过了他买半价鸡蛋省下的金额。于此同时,限量供应的条件下必然有一些排队者最终没能买到鸡蛋。之所以有人买到鸡蛋有人没买到,大多数情况下是因为前者比后者付出了更多的成本;排队者是在跟其他排队者竞争,那些看到长长的队伍就放弃的潜在消费者就是竞争的失败者。


12306的情况也是如此。在现有的车票限价限量供应体系下,在某些高峰期有乘车需求的旅客数量大大超过了铁路系统在这些时间段的运输能力。在这个前提下,必然会有大量旅客无法在这些时间段买到车票,被迫改变出行计划或者出行方式;而买到票的旅客为车票支付的成本,大多数情况下都是高于甚至远高于车票本身的标价的。超出的这一部分成本,可以体现为向黄牛买票支付的溢价,可以体现为在车站售票口排队付出的时间精力,而到了12306的时代,就可以体现为为了抢到票而付出的等待成本。


因此,12306无论怎么改进,都不可能降低因为供求关系而产生的旅客获得车票的额外成本。12306改进的结果只是会改变这种额外成本的形式。以前没有网络订票,大家去售票厅排队或者一次又一次打电话;现在有了网络订票,大家在网上卡到骂娘。但大家吐槽12306的种种缺陷时,其实原因并不是旅客真的特别重视网站的美观程度、重视网页的代码是不是高水平,而是还有很多人没能按自己的心意买到车票。旅客对12306的需求只有一条——买到旅客需要的车票;可是12306无法解决这个需求。对于旅客来说,卡三个小时但买到了票的体验是60分,三次放票时每次都一秒钟就被告知票已售完的体验是0分。


于是12306的未来就会很麻烦。随着系统的改进升级,整套系统的负载能力会越来越强大。可是性能的提升意味着热门车次放票后售空的速度越来越快。上面引据的例子里,一个车次一分钟就卖掉500张票;性能改进后,最终达到的效果可能是5秒钟就卖掉全部票额。而对于旅客来说,卖票速度提升并不会减少他们为了获得车票而付出的额外成本——以前是买一张票卡10分钟半小时,现在一个订单几秒钟就确认了,但是为了能在几秒钟里抢过其他旅客,你需要提升你的电脑性能,增加你的网络带宽,降低你的网络延迟;你需要更强大的抢票软件,一秒钟内发起更多的请求……最后,你在硬件设备上增加的投入就是你付出的额外成本,相比之前你在等待网页响应时付出的时间成本来说只是换了形式。以前售票厅时代大家比拼谁去排队排的早,以后大家比拼谁的网络性能好。而且,12306的响应速度越快,旅客之间的设备军备竞赛也就会越激烈。最后,大家会为了降低几十毫秒的延迟购买国内的vpn通道,改用表现更好的网卡,跑到号称能提供更高抢票性能的网吧去抢票……然后还是会有大量用户因为竞争不过其他旅客而被迫改变出行计划或出行方式。而且当旅客纷纷提升自己设备的性能时,对12306的压力也会越来越大,12306自己也必须同步增加性能,投入越来越高的成本。从技术的角度讲,12306面对的是一个随着它自身性能增长而同步甚至更快提升的需求,具有这样残酷要求的类似案例就只有股票、期货电子交易市场而已。甚至,12306最终的压力可能会超过这些市场。


回到最开始的问题:12306包给知名大企业是否会更好?答案是,无论谁来做,最终结果都是一样。

显示全部
后面的答案是午休前躺床上手机敲的,可能有诸多观点模糊不清,承蒙各位厚爱,已经好几百赞了,那就来多说点所谓的“技术”原因。
1.先说结论。12306外包给阿里巴巴和IBM都是不可行的。
2.许多人拿淘宝双11说话。别的都不扯,只说系统需求。用最外行的视角来揣测,淘宝双11最大的难点在于支付宝,当然这是我自己揣摩的。淘宝的商品数据更接近分布式仓储仿真,而12306的数据关联性要大的多。
3.客票库不只有12306访问,还有全路过万的车站售票窗口和过万的代售点,以及电话订票系统。因为客观原因,既有的票据库是分布式的,采用的票额计划制。简单来说,北京到广州的车,分给保定站多少张车票就是多少张,分给石家庄站多少张就是多少张,不能实现复用(复用就是北京到广州的车,有旅客购买了北京到郑州段,郑州到广州站生成一张新的车票)。
4.即便是现在,也不可能放弃计划式票务管理。运力紧张是客观存在的,不同地域铁路发展水平是千差万别的。这也是为什么北京到上海的车票好买,但北京到某些西部地区的票很抢手,而春运期间后者的需求是矛盾的根本。
5.12306的车票预定界面,查询之后需要执行的命令要远远复杂于淘宝商品查询、购买、支付任何一个环节。查询北京到昆明,不是到简单地到库里select T61、T239和K471三趟车的数据,需要访问北京局、郑州局、武汉局、广铁集团、成都局、昆明局的数据库,每个库都会有自己的队列。实事求是地讲,12306的数据和车站窗口的数据是没办法同步的,既有库和12306的库完全同步在目前的客观条件下是不可能实现的。
6.其实解决方案也没有想象得那么复杂,和那些技术性的答案一样,推倒重来构建一套新的客票发售系统,把所有的资源都集中到总公司,不管采用分布式或是其它系统架构,12306访问遇到的前台问题都能解决。老调重弹,如果你觉得在实用性都不能保证的时候,用户体验也很重要,请你去投奔注明的3某0来一起毁灭信息技术行业吧。
7.哪家公司能给出可行的过渡方案我们姑且不说,这就只说更深层次的问题。这个方案和大同世界某产主义一样,就是个屁。心细的旅客估计留意过,乘坐火车时经常会看到“北客”“南客”“西客”之类的字样。每趟列车都是有担当局的,比如北京到上海的列车,可能是北京局担当,也可能是上海局担当。
8.你把北京局出机车出车辆出司机出列车员出跟车检车员的列车车票拿到网上大家随便抢?苏南地区往返上海旅客较多,就让北京的旅客都坐到南京,换乘南京到上海的车?
9.不要觉得这几个问题出来,就可以扣大帽子给铁路说,这是你们内部管理和协调机制的问题了,和技术有什么关系。除了华北华东华南个别铁路建设程度不错的地区,多数地区在春运期间必须优先保证长途旅客发送。这和B格高党们可以选择坐飞机的道理是一样的,短途旅客的选择更多。
10.退一万步讲,所有车票都拿出来全程复用,其结果就是铁路倒退回计划经济时代,高度中央集权,这种情况没有腐败,没有黄牛,没有条子票你相信吗?这种情形你还想买到火车票?省省吧,到时候手里有资源的人恨不得把12306关了呢。
11.另外老有人说民营资本进入铁路,破除垄断之类的。我一般都只是骂几句不当回事,今天就跟那些自由民主人士说说铁路民营是怎么个情况。很多无良媒体采访些莫名其妙的神经病人士,他们都会有些很奇葩的想法,更可恶的是许多人深以为然。关于铁路优质资产打包上市,这种措施除了融资,还有什么别的意义。能赚钱的线路让民资外资进来,西部铁路边远山区由国家或铁总自己掏钱?上升到意识形态上来说,舍弃后者将前者上市的行为,是卖国。让前者上缴利润反哺后者的屁话就不要说了,我们自己不会做啊,要你来干嘛。
12.多少年的春运苦难,多少年的艰苦探索,得出的结论是:除了增加运力,别无他法。七年便能进入世界领先水准(那些喷子们,你们到现在还有国产的CPU芯片和操作系统呢,COS什么的就别拿出来BB了,贴近题目来说,也别再意淫淘宝和IBM大神有多牛逼了)的大概只有高铁吧。因为723,因为所谓的舆论,因为那位四万亿影帝,也可能因为交通运输业其它几位从不居安思危到了跟前才开始恐惧的恶心同仁,高铁降速了,不管是列车运营还是铁路建设。
13.说多了都是眼泪。李少泉的北洋水师全军覆没时的心境,常人难以理解。国家兴亡,匹夫有责,却不是让大家都指点江山。周树人比不上孙逸仙的最浅显原因就是他除了胡BB什么都不做,后世已经用近百年的血泪证明了那些所谓国民性的理论真得真得很搞笑。用那些东西来指导自己的生活工作,大概就只能成为后面回复里那些“技术帝”,也大概正是因为我们的父辈都浸淫在里面,才造就这个物欲横流道德丧失(此处省略一百个四字短语)的局面。
14.今年春运的目标是安全出行、方便出行、温馨出行,不是温馨出行、安全出行、方便出行,也不是方便出行、安全出行、温馨出行。客票安全是铁路信息技术工作最大的风险源。
15.我们20岁时在知乎一起胡BB。祈望我们50岁时,能再来这个问题看看。希望那时的国家昌盛富强,没有巨大的贫富差距, 没有巨大的地域差别,多数人都能在家乡工作。即便春节需要回家,超过六百公里我们都能掏得起机场建设费和燃油附加,不足四百公里我们都能交得起高速过路费和路政交警高速城管的罚款。
16.全国办理铁路客运业务的城镇,百分之九十以上都能通过飞机和汽车(或“或”)达成运输。
----------------------------------------以下是原答案----------------------------------------------------
作为一名铁路系统内的IT人士,我想说几点我个人的看法,与单位无关,也没有什么层次和逻辑。
1.我们不讲客观主观原因,不提历史遗留问题,只说现在的运力条件下,铁路旅客运输的重中之重是保障更多人—尤其是弱势群体,比如学生、进城务工人员等—的基本需求,而非部分人的更多需求。
2.某60在12306改动态验证码时官微发布的东西大家可以去了解一下。那代表了某些所谓IT人的自私、狂妄、虚伪和无知。你不是淘宝的运维人员,那350亿数字背后的惊心动魄里,你只是个参与者或是旁观者,而不是枪林弹雨里的将士。无论胜败荣辱,都与你无干。
3.我们有两百多万职工。你们加班加点熬夜做设计写标书赶程序,他们已经经历几十年昼夜颠倒的生活;你们抱怨亚历山大突发疾病亚健康过劳死,他们有许多人还没退休已是一身病;你们平日忙他们也忙,你们节假日回家他们更忙。
4.标榜什么无意,只是在这九百六十万热土的角角落落,有许多人在默默地奉献着,就为了你在下班之后洗把热水澡,煮一壶咖啡,躺到温暖的被窝里,拿起平板电脑,打开知乎,指责谩骂侮辱他们,或是他们的劳动成果。
12306只是售票的一部分,甚至是可有可无的一部分。我们是企业,背着2.6万亿的负债。不要认为这种说法无赖,无赖的是你们这些便宜占习惯了变欲求不满变本加厉蹬鼻子上脸的人。我们的建设,我们的运营,用的是我们的贷款,别张口闭口纳税人的钱。
5.世间总不能事事如意,遇到不顺利的事,先想想自己能做什么,别一味地要求别人。知乎里那些B格远高于常人的朋友,请你们把车票让给农民朋友学生兄弟。你们觉得苹果比诺基亚牛逼太多的时候,他们只能在给老家的父母妻儿汇款剩下的生活费里抠出几百块把自己那部屏幕破碎的手机换了。
6.上面一段话有个雷同的比喻是那些所谓的“贫困县”,不要狡辩,你们就是违背社会公义和良心,抢了他们回家的车票。你们乘坐飞机,换来的是明年情人节给女朋友送的礼物比预期差一些;他们乘坐飞机,代价是明年的春耕家里买不起化肥和农药。你们的选择更多,所以有了12306,我们就能送更多的学生更多的农民回家过年,即便是在绿皮车厢连接处的小马扎上坐二十个小时。
7.知乎的技术大牛确实很多,但有谁敢出头立军令状?有人反驳@王强 的段子,说“谣言可耻”,而你们除了意淫些完美的解决方案,还能做什么。IBM的整体解决方案是厉害,但是风险有多大你们了解么?12306可以崩溃可以瘫痪可以拒绝访问,但是为了效率影响安全,它IBM能承担得起?
8.这才说到离题目最近的东西。效率与安全不可兼得,这是铁路运输目前最大的难题之一。然而,安全是生命,效率是蛋糕。蛋糕可以不吃,命却不能不保。你们有几个知道京沪线陇海线列车晚点一分钟值多少钱吗?
9.你们总是揶揄我们从来不正点,晚点三个小时以内不算晚点。然而你们觉得我们晚点无所谓么?列车上有孕妇临盆大出血有病人病危呼吸衰竭,停不停车?股道上有闲杂人员司机下意识判定紧急制动还来得及,停不停车?下雪结冰洪水漫道塌方落石要不要慢行?地质灾害自然灾害抢修完了要不要先跑一趟实验列车?
10.你们留过洋觉得自己学习过更先进的技术接触过更有效的制度感受过更和谐的文化,只是你们知道那技术那制度那文化怎么来的么?乔布斯放到中国来能成就苹果么?知乎日报里也总有鼓吹苹果如何如何乔布斯如何如何的,我总忍不住连编辑跟着一起骂。
11.任何问题都有背景和上下文,抛开约束条件,问一只狮子竟然直接就被牛顶飞到四五米高(请谷歌有关视频查看),它们怎么能成为万兽之王,就是耍流氓。不要总是觉得政府怎么怎么样体制怎么怎么样垄断怎么怎么样。你们还听信那些误人子弟的专家学者无良媒体的说法,觉得铁路还停留在远古时代计划经济,还是庞然大物转身困难,那我只能呵呵,然后告诉你。其实有时候,可怕的不是落伍于时代,而是乌龟已经完成比赛了,兔子还在意淫自己甩开人家多少圈。
12.铁路旅客运输另一个巨大难题,是无知而浮躁的舆论叫嚣和实干的鸿沟,需要我们舍弃进步与发展的机遇来填。先说舆论。看过《走向GH》的同志都应该能感触到,李中堂袁大头和太后背着千古骂名,却是为江山社稷黎民百姓做了许多事情的。康有为谭嗣同之流包括后来的周树人,除了空想,他们还能做什么。最近知乎有人比较二战后的德日和某朝,主流的观点是他们二战前就有固定的工业基础、技术能力和教育体系。那我们的国力在一百二十年前比东临强胜很多倍,一样被打败又作何解释。当然,这又是知乎的另一个问题。
13.上面长篇累牍一大段,要说明的问题是什么呢,知乎实在是个鱼龙混杂的地方。太多的人拿着些哗众取宠的逻辑和观点,用许多脑残赞,来毁掉有求知欲的人思考辨析的可能。
14.扯得有点远,但实在不吐不快。热血上头,也不讲什么严密不严密,也有许多文辞句法标点错误,那些反对者们尽管找个茬子来放大了喷,最好能证明楼主逻辑混乱文盲在世神经不正常。
15.最后插个题外话。如果你是一个有想法有追求有忧国忧民情怀而心怀天下的人,第一步是充实自己,学贯中西,通晓古今;第二步是强大自己,看遍众生,历尽山河;第三步就是静待时机,卧薪尝胆,韬光养晦。
16.路,是一步一步走出来的;经济,是一砖一瓦构建起来的;国家,是你、我、他,一点一滴做出来的。
最后送给大家几句B格甚高的话。
一是实干兴邦,空谈误国。
二是宽以待人,严于律己。
三是取舍之间,必有得失。
四是如鱼饮水,冷暖自知。 显示全部

林布攒钱买玛莎

收起
张三、知乎用户、严凌清 等人赞同
看了几个高票答案,有点着急。

12306最让人诟病的是频繁崩溃,而洗地的人讨论的是票够不够卖。

话放在这里,12306根本没有用心在做。

我以前是干前端的,sever端很多东西我不懂,也知道难度极大。我无意于评论后端的水平,但是我们可以通过看得见的东西来讨论太极是用什么人,什么态度去做这个网站。

简单的说:无论数据库那边有多难,至少前端都不应该做成这么落后,混乱,业余的样子。


数据库上面的问题讨论的很多了,我不搀和。最差的情况下,哪怕数据库方面直接挂掉了,至少页面也应该是活着的啊。
这里我负责任的说一句,12306的前端,到目前为止依旧是一滩狗屎(目前:2014.8.25默认使用的版本)
你可以说IBM和阿里解决不了所有的问题,起码他们不能帮你造铁路。不过就12306前端体现出的本科毕设水平,也好意思这么说吗?
「挟太山以超北海,语人曰『我不能』,是诚不能也。为长者折枝,语人曰『我不能』,是不为也,非不能也。
算了先不吐槽,上点啥内容
我为什么说,12306的前端是落后过时的



----------郑重声明:我欢迎任何形式的讨论,但是认为我在讨论外观/体验,UI/UE的请回去重新学习中学语文再来评论--------------

很多细节,我随便列举
  • 页内js写的到处都是,东一片西一片,很难维护

  • css技术落后,多个icon图片分开加载,完全可以用css切割来减少请求次数,提高效率

  • js技术老旧且极不成熟:使用jquery 1.4.2也就罢了,页内有大量字符串拼接html然后用$jq.html()方法写入的语句,很难维护,可读性低。
  • 许多本应私有方法暴露在window对象下,比如getQueryParamValue这种,对安全性和可维护性都十分不利

  • 资源加载未优化:除了现成的控件以外,js没有经过压缩和混淆,不过比我上一次看(12年底)的时候,大段大段的注释要好一些。此外资源加载次序没有优化调整,一些不重要的js文件在head处加载,没必要

  • 前端技术不但落后,而且混乱,没有统一。在选取dom元素方面,一个页面里同时存在jQuery的选择器以及document.getElementById的方法。同时Jquery控件和接近被淘汰的flash控件混用来呈现了一个很混乱的前端代码
  • html的命名简直不知所谓,indexLeft下面是newLeft,newRight...谁知道这是什么跟什么啊。对后来的维护势必造成困扰。相比之下二维码的div叫做erweima还算比较萌
  • @stone moai 同学在评论里提及,打开这个页面kyfw.12306.cn/otn/query,结果发现head里加载了这样一个js文件kyfw.12306.cn/otn/resou。请求大小是1.7M。存储的是全国所有车次的 ([车次号(路线],[对应数据库ID])。为了完成一个输入框自动完成的功能。
    简直不可思议!
    这就是一个小型的静态数据表,完全可以存放在数据库中用ajax来查询。如果担心请求次数对服务器的压力的话,可以租用一个第三方的服务器来解决。但是他们的做法是,把这个丢在了JS里。
    丢在JS里不是不可以,但是这种巨大的非必须文件本应在document.load事件里来异步加载。但是他们的做法是,把这个丢在了head下面。我...一口老血


UI设计过时丑陋那真的不用我多说了,设计问题我也管不着。不过这分明就是5000块钱的外包模板而已啊。


总体来说,以12306前端技术的落后,业余,低效,混乱。以此来看,我很难相信他们的在数据库方面能够有多么好的表现。我还是得说,这就是一帮子大学生现学现卖的毕设水平,作为这个级别的网站而言,就是一滩屎,连个坨都没有——好歹一坨屎也是成形的屎。


说起来我之前看到他们的大段注释的时候,还看的出来他们在规章制度上挺严格,注释写的一板一眼的。但是实际上也就是制度上严格而已,管理上十分混乱,连一个统一前端技术方案都没有,才会闹getElementById和jQuery选择器大规模混用的笑话。

至于其他一些不利于快速加载,不利于减少请求,减少响应时间的小毛病,不是大问题,对于学生毕设来说可以接受。但是连这些很低级很基础的举手之劳都做不好或者不想做的,你网站崩溃确实是有客观的原因,但是就这样还好意思说什么客观条件?



项羽说天要亡我非战之罪情有可原,你一马谡自己不好好做事把自己弄死了,还怪王平不给力,好意思吗。




几点说明

  1. 前端的代码浏览器里都能看到,写的好坏大家一看便知。至于后台,不了解,不多说。对于某些对技术一无所知还来摆酸话的,我希望知乎能出一个自定义评论验证码。比如现在我就想弄一个"写一个超链接"的验证码,能过滤到很多没有价值的评论。
  2. 重复:我真的没有在讨论任何和外观体验有关的话题
  3. 针对“虽然前端硬伤但是不影响整体,后台多努力你造吗”——或者根本选择无视前端硬伤的:
    我更关注的是开发团队的技术实力,而就其前端而言,选用的技术古旧体现出的落后,基本优化缺失体现出的毛糙业余,同一个页面使用不同技术方案体现出的毫无管理,都是伴随团队的整个开发过程的。
    做出这样一个落后业余混乱前端的团队,是绝对没有实力做出一套好的解决方案的。
    前端的性能问题或者别的问题相对于其数据问题确实不是一个大问题,但是前端落后业余混乱的硬伤表现出的开发者团队能力的问题,则比起数据来说是一个更具体更现实的问题了,除非有证据能证明后台开发的团队是另一个技术实力远强于前端的团队。
    更何况以前端的业余程度来说,他们负责代码审查和白盒测试的团队恐怕也....
  4. 竟然真的看到了类似于,出于高并发系统的难度,前端代码质量和水平要为其让路这样的神论断。我希望持有这个论断的知友能够把他的理论依据就事论事的和目前我们能看到的前端代码结合在一起。
    简单的说,就是指出某一段具体的代码”为什么不能写成更高质量,而只能以目前这种水平完成“。talk is cheap
显示全部

Bill Cheng是一只死掉的考拉,大家不用在意

收起
  1. 放淘宝做依旧会卡死,不过是以不同的方式,比如说502界面更好看,等待的时候给你玩玩Flash游戏(多年以来的旧数据库可不是说优化就优化的,更不是说换就换的)
  2. 就算是让淘宝来做,铁路运力不增加,票也不会增加,买不到票的还是会有很多
  3. 在铁路运输不能完全市场化的情况下(票价上升,让某些人被迫选择其他出行方式),大家买票都是看脸的;淘宝不绕过发改委来弄拍卖,也拯救不了这一点
  4. 票就那么多,瞬间就被买完了,没买到的人照样会骂的,让淘宝来做,只是让那帮人骂的人从骂铁路总公司转移到骂铁路总公司和淘宝,对于淘宝来说这完全属于吃力不讨好(当然政府的回扣还是很可观的)
  5. 购买者个人隐私的问题。(参考支付宝这几天出的大新闻 支付宝回应前员工盗数据事件:未涉及核心信息)(铁路总公司的员工可不会为了这么点钱放弃仕途,你懂得)
  6. 防止支付宝金融体系的一家独大和脱离监管
  7. 让淘宝来做,黄牛的日子应该会更好过吧,贿赂铁路员工算是贿赂政府公务人员,贿赂淘宝员工总不算吧,呵呵……

关于@李东

淘宝应该可以做好的

但是,像淘宝这样的互联网公司,极有可能把所有的进度和方案公布出来,太透明了,好吗?好吗?

这样的言论,我想问:阿里有哪个项目的进度是透明的?你这盲目极端天真的想法是哪里来的?作政府项目还项目全部透明?!你当阿里的公关部门都是傻子么?
支付宝出了资料泄露的这种事情,有第一时间通知用户么?还不是在被媒体曝光之后才说的!
搞不懂你们这帮人对于商业公司的信任来自于何处……被这帮公司控制的网络媒体洗脑了么?
现有的部分讨论,双方缺少对基本事实的共识。

在下转一篇文章,给诸位提供一些材料,不管是支持还是反对,至少可以指出支持反对哪一点,免得鸡同鸭讲。文章是两年前的,欢迎知情人士指出两年来是否有什么变化。

文章主要说了12306这个网站有多独特,技术难点在哪里,有什么可能的改善方法。

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

由http://12306.cn谈谈网站性能技术


2012年1月16日 陈皓

12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西)



业务

任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。

  • 其一有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的,网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
  • 其二有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样。火车票这个事,还有很多查询操作,查时间,查座位,查铺位,一个车次不 行,又查另一个车次,其伴随着大量的查询操作,下单的时候需要对数据库操作。而秒杀,直接杀就好了。另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只需要在内存cache中放好可秒杀的数量,还可以把数据分布开来放,100商品,10台服务器一台放10个,无需在当时操作任何数据库。可以订单数够后,停止秒杀,然后批量写数据库。而且秒杀的商品不多。火车票这个不是像秒杀那么简单的,春运时间,几乎所有的票都是热门票,而且几乎是全国人民都来了。(淘宝的双十一也就3百万用户,而火车票瞬时有千万级别甚至是亿级别的)
  • 其三有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式,也就是说不存在先来先得的抢的方式,而且,是事后抽奖,事前只需要收信息,事前不需要保证数据一致性,没有锁,很容易水平扩展。
  • 其四订票系统应该和电子商务的订单系统很相似,都是需要对库存进行:1)占住库存,2)支付(可选),3)扣除库存的操作。这个是需要有一致性的检查的,也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的,也就是说,你下的订单并不是马上处理的,而是延时处理的,只有成功处理了,系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说,数据一致性在并发下是一个瓶颈
  • 其五铁路的票务业务很变态,其采用的是突然放票,而有的票又远远不够大家分,所以,大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候,就会有几百万人甚至上千万人杀上去,查询,下单。几十分钟内,一个网站能接受几千万的访问量,这个是很恐怖的事情。据说12306的高峰访问是10亿PV,集中在早8点到10点,每秒PV在高峰时上千万。

多说几句:

  • 库存是B2C的恶梦,库存管理相当的复杂。不信,你可以问问所有传统和电务零售业的企业,看看他们管理库存是多么难的一件事。不然,就不会有那么多人在问凡客的库存问题了。(你还可以看看《乔布斯传》,你就知道为什么Tim会接任Apple的CEO了,最主要的原因是他搞定了苹果的库存周期问题)
  • 对于一个网站来说,浏览网页的高负载很容易搞定,查询的负载有一定的难度去处理,不过还是可以通过缓存查询结果来搞定,最难的就是下单的负载。因为要访问库存啊,对于下单,基本上是用异步来搞定的。去年双11节,淘宝的每小时的订单数大约在60万左右,京东一天也才能支持40万(居然比12306还差),亚马逊5年前一小时可支持70万订单量。可见,下订单的操作并没有我们相像的那么性能高。
  • 淘宝要比B2C的网站要简单得多,因为没有仓库,所以,不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候,B2C的 网站要去找一个仓库,又要离用户近,又要有库存,这需要很多计算。试想,你在北京买了一本书,北京的仓库没货了,就要从周边的仓库调,那就要去看看沈阳或 是西安的仓库有没有货,如果没有,又得看看江苏的仓库,等等。淘宝的就没有那么多事了,每个商户有自己的库存,库存就是一个数字,并且库存分到商户头上了,反而有利于性能扩展。
  • 数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求,我不怀疑。但这只是静态请求,理论值,只要带宽、I/O够强,服务器计算能力够,并支持的并发连接数顶得住10万TCP链接的建立 的话,那没有问题。但在数据一致性面前,这10万就完完全全成了一个可望不可及的理论值了。

我说那么多,我只是想从业务上告诉大家,我们需要从业务上真正了解春运铁路订票这样业务的变态之处。



前端性能优化技术

要解决性能的问题,有很多种常用的方法,我在下面列举一下,我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。


一、前端负载均衡

通过DNS的负载均衡器(一般在路由器上根据路由的负载重定向)可以把用户的访问均匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都是短作业,所以,可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让用户连接与其最近的服务器(CDN通常伴随着分布式存储)。(关于负载均衡更为详细的说明见“后端的负载均衡”)


二、减少前端链接数

我看了一下12306.cn,打开主页需要建60多个HTTP连接,车票预订页面则有70多个HTTP请求,现在的浏览器都是并发请求的(当然,浏览器的一个页面的并发数是有限的,但是你挡不住用户开多个页面,而且,后端服务器TCP链接在前端断开始,还不会马上释放或重要)。所以,只要有100万个用户,就有可能会有6000万个链接(访问第一次后有了浏览器端的cache,这个数会下来,就算只有20%也是百万级的链接数),太多了。一个登录查询页面就好了。把js打成一个文件,把css也打成一个文件,把图标也打成一个文件,用css分块展示。把链接数减到最低。


三、减少网页大小增加带宽

这个世界不是哪个公司都敢做图片服务的,因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形(现在在手机端浏览也是这个情形)。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右,如果你访问过了,浏览器会帮你缓存很多,只需下载10K左右的文件。但是我们可以想像一个极端一点的案例,1百万用户同时访问,且都是第一次访问,每人下载量需要1M,如果需要在120秒内返回,那么就需要,1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以,我估计在当天,12306的阻塞基本上应该是网络带宽,所以,你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用,于是负载一下就到了后端,后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明后端服务器垮了。


四、前端页面静态化

静态化一些不常变的页面和数据,并gzip一下。还有一个变态的方法是把这些静态页面放在/dev/shm下,这个目录就是内存,直接从内存中把文件读出来返回,这样可以减少昂贵的磁盘I/O。使用nginx的sendfile功能可以让这些静态文件直接在内核心态交换,可以极大增加性能。


五、优化查询

很多人查询都是在查一样的,完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现,第一次查询走数据库获得数据,并把数据放到缓存,后面的查询统统直接访问高速缓存。为每个查询做Hash,使用NoSQL的技术可以完成这个优化。(这个技术也可以用做静态页面)

对于火车票量的查询,个人觉得不要显示数字,就显示一个“有”或“无”就好了,这样可以大大简化系统复杂度,并提升性能。把查询对数据库的负载分出去,从而让数据库可以更好地为下单的人服务。


六、缓存的问题

缓存可以用来缓存动态页面,也可以用来缓存查询的数据。缓存通常有那么几个问题:

1)缓存的更新。也叫缓存和数据库的同步。有这么几种方法,一是缓存time out,让缓存失效,重查,二是,由后端通知更新,一量后端发生变化,通知前端更新。前者实现起来比较简单,但实时性不高,后者实现起来比较复杂 ,但实时性高。

2)缓存的换页。内存可能不够,所以,需要把一些不活跃的数据换出内存,这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法

3)缓存的重建和持久化。缓存在内存,系统总要维护,所以,缓存就会丢失,如果缓存没了,就需要重建,如果数据量很大,缓存重建的过程会很慢,这会影响生产环境,所以,缓存的持久化也是需要考虑的。

诸多强大的NoSQL都很好支持了上述三大缓存的问题。



后端性能优化技术

前面讨论了前端性能的优化技术,于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。


一、数据冗余

关于数据冗余,也就是说,把我们的数据库的数据冗余处理,也就是减少表连接这样的开销比较大的操作,但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据,快是快了,因为数据冗余了,但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。(注意:用关系型数据库很容易移植到NoSQL上,但是反过来从NoSQL到关系型就难了)


二、数据镜像

几乎所有主流的数据库都支持镜像,也就是replication。数据库的镜像带来的好处就是可以做负载均衡。把一台数据库的负载均分到多台上,同时又保证了数据一致性(Oracle的SCN)。最重要的是,这样还可以有高可用性,一台废了,还有另一台在服务。

数据镜像的数据一致性可能是个复杂的问题,所以我们要在单条数据上进行数据分区,也就是说,把一个畅销商品的库存均分到不同的服务器上,如,一个畅销商品有1万的库存,我们可以设置10台服务器,每台服务器上有1000个库存,这就好像B2C的仓库一样。


三、数据分区

数据镜像不能解决的一个问题就是数据表里的记录太多,导致数据库操作太慢。所以,把数据分区。数据分区有很多种做法,一般来说有下面这几种:

1)把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分,可按各种车型分,可以按始发站分,可以按目的地分……,反正就是把一张表拆成多张有一样的字段但是不同种类的表,这样,这些表就可以存在不同的机器上以达到分担负载的目的。

2)把数据按字段分,也就是竖着分表。比如把一些不经常改的数据放在一个表里,经常改的数据放在另外多个表里。把一张表变成1对1的关系,这样,你可以减少表的字段个数,同样可以提升一定的性能。另外,字段多会造成一条记录的存储会被放到不同的页表里,这对于读写性能都有问题。但这样一来会有很多复杂的控制。

3)平均分表。因为第一种方法是并不一定平均分均,可能某个种类的数据还是很多。所以,也有采用平均分配的方式,通过主键ID的范围来分表。

4)同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上,比如有10000个库存,可以分到10台服务器上,一台上有1000个库存。然后负载均衡。

这三种分区都有好有坏。最常用的还是第一种。数据一旦分区,你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区,并放在各个省市,会对12306这个系统有非常有意义的质的性能的提高


四、后端系统负载均衡

前面说了数据分区,数据分区可以在一定程度上减轻负载,但是无法减轻热销商品的负载,对于火车票来说,可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像,你必然要使用负载均衡,在后端,我们可能很难使用像路由器上的负载均衡器,因为那是均衡流量的,因为流量并不代表服务器的繁忙程度。因此,我们需要一个任务分配系统,其还能监控各个服务器的负载情况。

任务分配服务器有一些难点:

  • 负载情况比较复杂。什么叫忙?是CPU高?还是磁盘I/O高?还是内存使用高?还是并发高?还是内存换页率高?你可能需要全部都要考虑。这些信息要发送给那个任务分配器上,由任务分配器挑选一台负载最轻的服务器来处理。
  • 任务分配服务器上需要对任务队列,不能丢任务啊,所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。
  • 任务分配服务器死了怎么办?这里需要一些如Live-Standby或是failover等高可用性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。

我看到有很多系统都用静态的方式来分配,有的用hash,有的就简单地轮流分析。这些都不够好,一个是不能完美地负载均衡,另一个静态的方法的致命缺陷是,如果有一台计算服务器死机了,或是我们需要加入新的服务器,对于我们的分配器来说,都需要知道的。另外,还要重算哈希(一致性hash可以部分解决这个问题)。

还有一种方法是使用抢占式的方式进行负载均衡,由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度,而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是,如果有一些任务只能在某种服务器上处理,这可能会引入一些复杂度。不过总体来说,这种方法可能是比较好的负载均衡。


五、异步、 throttle 和 批量处理

异步、throttle(节流阀) 和批量处理都需要对并发请求数做队列处理的。

  • 异步在业务上一般来说就是收集请求,然后延时处理。在技术上就是可以把各个处理程序做成并行的,也就可以水平扩展了。但是异步的技术问题大概有这些,a)被调用方的结果返回,会涉及进程线程间通信的问题。b)如果程序需要回滚,回滚会有点复杂。c)异步通常都会伴随多线程多进程,并发的控制也相对麻烦一些。d)很多异步系统都用消息机制,消息的丢失和乱序也会是比较复杂的问题。
  • throttle 技术其实并不提升性能,这个技术主要是防止系统被超过自己不能处理的流量给搞垮了,这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控制的系统,比如,和你网站对接的银行系统。
  • 批量处理的技术,是把一堆基本相同的请求批量处理。比如,大家同时购买同一个商品,没有必要你买一个我就写一次数据库,完全可以收集到一定数量的请求,一次操作。这个技术可以用作很多方面。比如节省网络带宽,我们都知道网络上的MTU(最大传输单元),以态网是1500字节,光纤可以达到4000多个字节,如果你的一个网络包没有放满这个MTU,那就是在浪费网络带宽,因为网卡的驱动程序只有一块一块地读效率才会高。因此,网络发包时,我们需要收集到足够多的信息后再做网络I/O,这也是一种批量处理的方式。批量处理的敌人是流量低,所以,批量处理的系统一般都会设置上两个阀值,一个是作业量,另一个是timeout,只要有一个条件满足,就会开始提交处理。

所以,只要是异步,一般都会有throttle机制,一般都会有队列来排队,有队列,就会有持久化,而系统一般都会使用批量的方式来处理


云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似,就是说,我的系统收到了你的购票下单请求,但是我还没有真正处理,我的系统会跟据我自己的处理能力来throttle住这些大量的请求,并一点一点地处理。一旦处理完成,我就可以发邮件或短信告诉用户你来可以真正购票了。


在这里,我想通过业务和用户需求方面讨论一下云风同学的这个排队系统,因为其从技术上看似解决了这个问题,但是从业务和用户需求上来说可能还是有一些值得我们去深入思考的地方:


1)队列的DoS攻击。首先,我们思考一下,这个队是个单纯地排队的吗?这样做还不够好,因为这样我们不能杜绝黄牛,而且单纯的ticket_id很容易发生DoS攻击,比如,我发起N个 ticket_id,进入购票流程后,我不买,我就耗你半个小时,很容易我就可以让想买票的人几天都买不到票。有人说,用户应该要用身份证来排队, 这样在购买里就必需要用这个身份证来买,但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队,但就是不买。黄牛这些人这个时候只需要干一个事,把网站搞得正常人不能访问,让用户只能通过他们来买。


2)对列的一致性?对这个队列的操作是不是需要锁?只要有锁,性能一定上不去。试想,100万个人同时要求你来分配位置号,这个队列将会成为性能瓶颈。你一定没有数据库实现得性能好,所以,可能比现在还差。抢数据库和抢队列本质上是一样的


3)队列的等待时间。购票时间半小时够不够?多不多?要是那时用户正好不能上网呢?如果时间短了,用户不够时间操作也会抱怨,如果时间长了,后面在排队的那些人也会抱怨。这个方法可能在实际操作上会有很多问题。另外,半个小时太长了,这完全不现实,我们用15分钟来举例:有1千万用户,每一个时刻只能放进去1万个,这1万个用户需要15分钟完成所有操作,那么,这1千万用户全部处理完,需要1000*15m = 250小时,10天半,火车早开了。(我并非信口开河,根据铁道部专家的说明:这几天,平均一天下单100万,所以,处理1000万的用户需要十天。这个计算可能有点简单了,我只是想说,在这样低负载的系统下用排队可能都不能解决业务问题


4)队列的分布式。这个排队系统只有一个队列好吗?还不足够好。因为,如果你放进去的可以购票的人如果在买同一个车次的同样的类型的票(比如某动车卧铺),还是等于在抢票,也就是说系统的负载还是会有可能集中到其中某台服务器上。因此,最好的方法是根据用户的需求——提供出发地和目的地,来对用户进行排队。而这样一来,队列也就可以是多个,只要是多个队列,就可以水平扩展了。这样可以解决性能问题,但是没有解决用户长时间排队的问题。


我觉得完全可以向网上购物学习。在排队(下单)的时候,收集好用户的信息和想要买的票,并允许用户设置购票的优先级,比如,A车次卧铺买 不到就买 B车次的卧铺,如果还买不到就买硬座等等,然后用户把所需的钱先充值好,接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户。这样,系统不仅可以省去那半个小时的用户交互时间,自动化加快处理,还可以合并相同购票请求的人,进行批处理(减少数据库的操作次数)。这种方法最妙的事是可以知道这些排队用户的需求,不但可以优化用户的队列,把用户分布到不同的队列,还可以像亚马逊的心愿单一样,通过一些计算就可以让铁道部做车次统筹安排和调整(最后,排队系统(下单系统)还是要保存在数据库里的或做持久化,不能只放在内存中,不然机器一down,就等着被骂吧)。



小结

写了那么多,我小结一下:


0)无论你怎么设计,你的系统一定要能容易地水平扩展。也就是说,你的整个数据流中,所有的环节都要能够水平扩展。这样,当你的系统有性能问题时,“加30倍的服务器”才不会被人讥笑。


1)上述的技术不是一朝一夕能搞定的,没有长期的积累,基本无望。我们可以看到,无论你用哪种都会引发一些复杂性,设计总是在做一种权衡。


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


3)春运前夕抢票且票量供远小于求这种业务模式是相当变态的,让几千万甚至上亿的人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的变态决定了无论他们怎么办干一定会被骂。


4)为了那么一两个星期而搞那么大的系统,而其它时间都在闲着,有些可惜了,这也就是铁路才干得出来这样的事了。


更新2012年9月27日

Alexa 统计的12306的PV (注:Alexa的PV定义是:一个用户在一天内对一个页面的多次点击只算一次)


本文转载时请注明作者和出处,请勿于记商业目的

(转载本站文章请注明作者和出处 酷 壳 – CoolShell.cn ,请勿用于任何商业用途)


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



注:有个地方要更新一下。文中在比较 12306 和淘宝时提到:
「去年(2011年)双11节,淘宝的每小时的订单数大约在60万左右。」
淘宝的双十一也就3百万用户,而火车票瞬时有千万级别甚至是亿级别的。
文中这个数字现在已经不适用。淘宝的容量两年来有了巨大的提升。
2013 年淘宝双11的第一分钟,产生 33.9 万笔交易,有 1370 万人次同时在线。第二分钟和第三分钟成交笔数分别为 111 万笔和 190 万笔。交易峰值出现在 1 分 27 秒,1 秒钟内,13637 人同时成功付款。数据来源:双11当天6小时内支付宝交易额突破百亿_TechWeb 显示全部
=~~~~=
更新内容:
=~~~~=
王强已经对那个段子做了一些修改,但问题依然存在:
  1. 段子之后的描述混淆了「买票难」和「12306网站做的烂」两个概念,前者是票难买,后者是12306难用。对于前者我非常理解,但后者才是本题的重点;
  2. 尽管还是不咋地,但12306的改善有目共睹,这点无可否认,我也从未否认。
    可12306是否改善了并不能说明任何问题。雷军说的好,台风口上猪都会飞,2011年6月上线到现在几年时间加重金投入都没改善的话,真当科研人员是猪?
  3. 12306遇到的问题前所未有,12306是最大的订票系统,除了中国人口多,这不能说明什么,想论证题目还请参照第四点。
    某个问题别人没遇到过,不代表不能解决,现在的承包公司显然也没遇到过,而且比起其他的大公司资历更浅,于此讨论没有任何意义;
  4. 讨论的重点在于,如果此任务外包给更有实力的公司,是否会更好(现在承包12306的是太极控股)。到目前为止王强答案能论证这点的只有「第二次招标钱管够但是别的公司技术不够不敢做」,关于这次招标王强仍未提供任何可查证的出处,只是声称12306的技术披露连带证明了整个段子的真实性;
  5. 王强的补充内容已经开始玩弄诛心论动机揣测那一套了,我对这道题本无兴趣,只是碰巧看过IBM方案被毙掉的新闻,对王强的小段子忍不住吐槽而已。
    碰巧我上一次回答关于12306的问题还是在帮铁道部说话(如何评价 12306 火车票订票网站的手机客户端?
    屁股不正看世界,永远是歪的。
  6. 正如第五点,我对此题没兴趣,所以直接匿名取关。现在也厌烦了评论区五毛美分的口水仗,更新到此为止,关闭评论,有意见投票表达,亦可另开答案。

另外我帮王强确认了第二次招标的存在:
铁道部改造12306遭疑:通过太极股份买自家产品|12306|铁道部
太极计算机股份有限公司关于铁道部新一代客票系统一期工程项目中标公告
(证明这次改造早就有公开资料,所谓「局外人没人知道12306已经在2012年开始做了技术改造」证伪,至于他说的那几个技术细节是不是机密到「此次技术升级的核心人士」才知道,这点存疑)

基于现有资料,保留对于所谓「钱管够但是别的公司技术不够不敢做」的质疑,互联网大鳄阿里巴巴吓尿了,号称「智慧地球」的百年老店IBM吓尿了,结果在一期工程还是一坨屎的太极控股一拍脑袋提出了方案(引用来源提到,二期工程开头仍然是一坨屎,直到最近才有所改善),并且铁道部英明的预见了这次拍脑袋——你说这是神话,但我认为是童话。

除了王强的段子,其他的新闻都指向一个信息:铁道部利用太极控股自买自卖,然后太极控股做了一坨渣,尽管这坨渣最近已经没那么烂了。
=~~~~~=
原始答案:
=~~~~~=
我是来反对排名第一@王强 答案的。

所谓「真假自辩」还真是一个有趣的托词,没任何引用来源和辅证途径,几近不可证伪。

我Google了一下 12306+IBM 搜索结果如下:Google 搜索结果
12306招标:铁道部公司中标 IBM方案被毙
太极中标铁道部12306网 IBM提1.9亿成熟方案被拒
12306故障频发 铁道部舍本逐末淘汰IBM遭抱怨|12306 IBM 网上订票
假如IBM成为12306的中标承建者?

12306的中标机构为「太极控股」,这是个什么玩意?

12306采购自循环:通过太极股份采购自家产品|12306|通过太极
铁道部再次拒绝公开12306网站招标信息
12306招标信息公开案久拖未决 爆料人催促开审

铁道部弄了一个马甲公司然后自己投标给自己,这就是所谓的「资金管够但是问题得解决」?

再说铁道部好歹是国家机构,预算如何有管够一说?商业公司的胃口岂是只占点小便宜就走?预算管够的话商业公司真会放弃这个项目?

「如果有10%的利润,资本就会保证到处被使用;有20%的利润,资本就能活跃起来;有50%的利润,资本就会铤而走险;为了100%的利润,资本就敢践踏一切人间法律;有300%以上的利润,资本就敢犯任何罪行,甚至去冒绞首的危险」——马克思

如果商业公司真的放弃这个项目,只能说明预期收益和成本的比例无法让人满意。

IBM是整套解决方案公司,只要你肯出钱,从芯片设计制造到软件开发维护都能做,大不了专门为12306设计一个芯片方案,这样的利润大到难以想象,就算做不出来,捞一笔还是没问题的,真是钱管够怎么可能放弃?

至于如@陈涛所说,「是不是地球上的技术已经不能解决12306了?」,我个人无法回答,现在只能肯定12306的情况确实特殊,但仅此而已,更多的猜测请从技术出发,不要摆这些乱七八糟的段子误导大众。

造谣可耻。 显示全部

李爱吉自由主义者,装逼犯请拉黑

收起
实在是看不下去了,现在都是些什么答案在被狂赞啊

先明确反对王强的答案,就这就能混k级以上的赞

12306的问题很简单,就是前端承载力的问题,taobao如果不行,那才见鬼了
至于排名第一的王强说的后台服务器的问题,简直是太太太简单了,还在回复中用“一秒钟几百万次的数据库写入”来唬人,好像这个值真的很大似的。

其实技术问题早就像与王强辩论的徐峰说的一样,大牛们早就讨论过了,现在已经没有大牛有兴趣再说这个了
--------------------------------以下是关于技术的严肃回复-----------------------------

王强的回答包括他与其他人的辩论,通篇重要的就这么几点:

1,商业公司不行的论点之一:这件事儿其实很复杂,铁道部下属公司已经很牛了,谁都解决不了
2,商业公司不行的论点之二:12306其实和taobao不一样,难点不一样
3,不满意是因为买不到票,这要靠铁路运力解决
4,任何公开渠道都查不到的内幕消息(但是王强 神通广大有来源有渠道,并且就不告诉你渠道是什么)称,铁道部招标,商业公司技术不行,都不敢上。

关于1:对于技术问题,它复杂不复杂是一回事儿,能不能解决是另一回事儿,复杂的技术被解决掉的多了去了
关于2:世界是没有两个需求完全相同的网站项目,12306存在taobao不同的技术难点,不代表12306的技术难点就是无解的,更不代表taobao或其它商业公司的专业技术团队解决不了
关于3:逻辑不清或者故意混淆视听。不满意买不到票,和不满意网站的体验,是两个问题。 用户对12306不满的,不是买不到票,而是在使用12306时的体验。12306购票的核心步骤就是查询,下单,返回购买是否成功。 而这几步操作经常卡死,无响应,结果错误,甚至整站崩溃。 拿铁道部自己举例子,12306存在之前,也买不到票,没有人骂排队3天是窗口的问题;拿同是网站的举例子,小米也是大多数人抢不到,但没人去骂小米网站做的sb。
关于4:如果您一直相信阴谋论,或者您有丁点兴趣,去查一下什么叫招标,还信这个,呵呵,我的答案您不必再看下去了,赶快 反对+没帮助+拉黑,我怕和你产生任何需要正常逻辑思维能力的交流

关于技术细节:
前端无响应,卡死,网站崩溃,这个taobao轻松解决,没有必要着这里跑题去解释什么是cdn,什么是前端设计准则了
至于王强说的后端技术难点,真正有点料的,就以下两点:
1,每秒上百万的数据库写入(不知道这个是怎么统计得到的),必须卡;
2,同一线路,因为出发到达的站点有各种组合,造成余票数据之间有依赖,座位要复用;

徐峰已经给出了很好地解决方案,12306刚推出的那个春节,专业技术论坛中就有人分析过这个解决方案:就是 每个车次一台专用服务器(或者一个集群,总够了吧),部署在不同的机房,这样数据库压力,流量压力自然就分开了。
王强竟然在给徐峰的回复中,说这个方案的问题在于,计算座位复用时,只能用到一个线程,无法并发,而单cpu核心的算力不够!!算力不够啊啊啊啊,本人必须承认,刚在看到这个说法时,有种被雷焦的感觉,实在是哭笑不得啊,挖哈哈哈哈哈呜呜呜呜呜

本来觉得笑尿了,完全不值一驳,连写答案的兴趣都没了。谁知道吃个午饭,那个答案被赞了那么多次,过k了啊
本人就耐着性子来帮众无脑盲从之辈算个排列组合问题:

假设某车次,有n个停靠站点,把这n个站点编号为s1, s2, s3, . . ., sn
在s1上车的乘客,可能在s2, s3, s4, s5, s6 . . . sn下车。那么就是说,从s1出发的票,可能有种到s(n-1)种到达。

以此类推,从sx站出发的票,共有n - x种到达,那么,有n站停靠的线路,共有 (n-1) + (n -2)... + (n - n)种票,很简单的等差数列,高一数学知识,和为 :
n(n-1) / 2
(这里我本来思维惯性,从0开始算车站编号了,第一次算成了n(n+1),以至于下面的100站的例子,票的种类多算了100种。谢谢h.b soap指出,这更说明了这个算量实在是太不值一提啦)

用[x,y)表示从sx出发,sy到达的票,
用N(x,y)表示该种类票的余量
那么,[x,y)发生了1张退票,会且只会引发的,无非就是[x,y)沿线相关站点的票随之变动(可能增加1)
很明显,这里y越大,x越小,那么变动的票的种类就越多,最极限情况就是x == 1,y == n,这时所有种类的票都会+1

现实中,最复杂的最长的线路,能有多少个停靠站?就假设它有100个站点,足够了吧(感觉不够的举例反驳我,请告诉我哪趟车超过了100站,我给你重来一遍下面的计算)
那就是说,一次座位复用计算,最多涉及到100 * (100 - 1) / 2 = 4950种不同的票。
就用最笨的最笨的穷举法,就是把每种票都遍历一遍,看是否受到了影响(这个判断也异常简单,和上面一样,比较一下个各个站点的编号就行了,核心逻辑一个if语句,整数比下大小就基本解决),也就5050次循环(即5050次比大小和加减法),依据徐峰的“非公开来源消息”,用上了至强集群这种高大上的硬件的系统,1s内能做多少次处理?

这还是全部按最复杂的情况并故意按最笨的方法处理的。

你告诉我,按车次分布这种做法IBM和taobao的团队想不到搞不出来,或者一个没有图片,没有音视频,只有几个干巴巴的数据的网站,前端的压力cdn解决不行???
至于后端的并发数量, server按车次分布后,每个server的并发一点都不大,谁没事儿老去刷自己不坐的车次(并且还可以设置刷新频率,现在就有)。
还嫌大,至强集群都搞不定,来找我,我用我的pc给你搞。数据库也已经自然分布了,并且,就算是王强所谓的每秒百万级的数据库访问的,我能告诉你这在业内根本不是个事儿么。

上面还没提,其实现实压力比上述还小的多得多。因为各个运行区间的票,不完全是即时动态算的,很多运行区间就是事先规划好票的预留量,这样座位复用需要的计算会少很多
------------------------------------------
以上,技术部分完毕,想提出各种12306现在根本不提供的变态功能需求说明这系统还有很多难题的,先去让12306把这些功能做出来再说。现在我们就只说12306的现有功能,能不能做好,我的回答是,能,并且交给专业的商业团队,很容易的事情。

再吐槽一下,包括王强在内的很多人的逻辑,其实还是那个经典奴才思维模式: “ 肉食者确实在努力为屁民服务,且智商很高,人家在下一盘很大的棋,复杂到你都不懂,并且你根本连棋盘是怎么回事儿都不知道(但是王强却因为不知何故能获取正常人都获取不到的“非公开来源消息”,王强却知道)所以你上你也不行,所以都老老实实用着12306,万一没崩溃,快去喊谢恩万岁吧

关于很多看起来是做程序的人赞的原因:合格程序员太少了,大多数赞的所谓的“从业人士”,自己觉得自己没自信解决,听到人说这东西谁都解决不了,自然很是高兴,哈哈
哪个自称懂技术且赞同王强的人具体分析出难点在哪里了么,说来说去就是没法分布,你没法分布就知道别人没法分布?稍专业点的技术群技术论坛中,12306技术上到底是不是没治了,从来都没见过争论

-----------------------------------
以下是回复中写的,觉得有必要提出到答案里,没料的回复,一律不再理:

然后,再说一遍,我回答的重点,不是在写一套12306的技术解决方案,只是在说,那个无脑答案中说的困难理由,是多么的荒谬。还是那句话,如果真的要我 提供全套的解决方案,那就请把做12306的钱给我,我来做个给你看。否则,一味的使劲找细节来说我解决方案(它本就不是个解决方案)不完善,那就是耍流 氓 显示全部

知乎用户,......

收起
我怎么感觉包给小米更合适呢?
今天发十万张票,大家抢啊,明天十万张……
到了淡季,那里到那里的票开放购买了……
在 12306 上抢「同一时间同一车次」车票的有多少人?

问题真是很复杂。洗地党很累。

莫莫缘为冰,我将冰拥入怀里,冰化了,缘没了!

收起
雪霁王一、知乎用户 等人赞同
一看题主就是被买票气的不行的,你是有多憎恨12306(开个玩笑)。那我就扯远点。
买票这个事给淘宝也没用,核心矛盾是票不够,而不是12306网站速度慢,如果票能满足所有人的需求,你就算刷了几个小时才买到了回家了票 也不会这样憎恨12306吧,作为屁民大部分还会感恩戴德吧。说白了还是供需矛盾,铁道部不可能为了春运这一个月,平常就上大量的空车在线路上跑,IT企业可以通过租用云服务器解决瞬时流量问题,但是铁道部不行,就算租用了大量的服务器,并且解决了@王强提到的cpu性能瓶颈,所有人都能很流畅的买票,但是你发现瞬间票就售完了,我相信题主不会赞扬12306这次买票流畅,不卡顿,而是会继续骂娘。
每年双11淘宝上都会有抢购比如2999的iphone,1999的ipad当然数量极少。一般都是开抢后几秒钟瞬间售光,也经常出现验证码刷不出来,小米的抢购大家也懂得,其实本质上跟12306抢不到票都一样。但是没抢到的大多就是呵呵一笑,最多骂两句就没了,有多少人就冲这恨上了淘宝、小米?那为啥这么多人没抢到票就愿12306呢?无非就是iphone,ipad,小米等不是必需品,抢不到了我可以等下次,甚至我用其他手机也行,但是每年春运的火车票对广大期盼回乡的游子来说决定了能否回家,能否见到自己的父母,妻子,儿女。
12306这个问题的再NB的IT企业也无法从根源上解决,你让铁路再发展个5年也没用(还是不可能为了春运平时上大量的空车)归根结底是个社会问题,解决问题的方法就是发展落后地区的经济,如果你在西安,郑州,武汉,长沙,成都,这些中东部省会城市拿的工资跟北京上海比差不了多少,我想大部分还人是愿意留在离父母,离家近的地方打工吧,少数有闯劲的去北上广就行了,到时候买票难还是问题吗?
很多问题的解决不是因为想到了解决问题的方法,而是问题本身消失了。经济发展平衡了,大家都在家门口打工,每年春运还用愁那一张回乡的票吗?

知乎用户,MMORPG 服务器程序猿

收起
yyy www、知乎用户、知乎用户 等人赞同
--------2014-1-10 14:26更新-----------------------------------------------------------------------
刚才又有点想法,铁路系统对于春运期间的车票应该是有一定的分配的,比如一趟 上海 - 汉口 的火车,铁路局对几个大站之间的车票应该会有一定的配额,否则一开抢上海到南京的车票卖出2000张,到合肥和汉口的同学就干瞪眼了。所以实际上铁路局可能会事先分配好,上海到汉口的车票最少要保证200张 南京到汉口的最少要保证200张,上海到合肥的200张..... 诸如此类。

既然如此,这些车票也就都是可以预先在数据库中分配出来,把这些车票分布到其他线程去出票,而不用全部挤到核心的出票线程,这些车票如果卖完了再将请求发到核心出票线程来,如果逾时还没卖完(比如开售30分钟后)就把票退回核心线程再次入库。

--------2014-1-9 10:17更新-----------------------------------------------------------------------
早上起来,突然想到还有优化的空间。

--------2014-1-8 22:21更新-----------------------------------------------------------------------
晚上优化了下,现在这速度怎么也该够了

-----------------------------------------------------------------------------------------------------------------------------------------
如果是说技术角度,给淘宝做是不是会比目前的12036更好,答案是肯定的。目前赞同最多的答案对于购票难的分析是中肯的,但是前半段所谓12306不能通过布署大量服务器来分散压力提高负载则不敢苟同。

首先,每一个火车车次之间是完全不关联的,每一个车次的购票事务都可以分配到不同的物理服务器,或者说处理器核心上去处理,这就是最简单的分布式方案了。

考虑到春运期间每一班火车可能同时都有几十万人甚至几百万人去抢,对于热门车次还可以进一步拆分,比如硬卧车厢的车票和硬座车厢的车票就可以分开来,同理动车和高铁的一等座,二等座也可以分开来。

到了这一步,就很难再拆分下去了,一个车次的同一席别的座位,很难再分布到不同的处理器核心上去了,但我们还可以把余票查询事务再拆分出来,同时余票查询因为不涉及到数据的写入,也不需要一致性的强保证,这个事务完全可以通过缓存的方式分散到数个数十个乃至数百个处理器核心上去处理。

所以,在我看来,在目前的硬件条件下,技术上要提高12306的负载到满足春运购票需求是没有什么问题的。但是要做到这样可能会面临其他的问题,比如这样的系统造价高昂,却只有春运这一个月用得上,存在巨大的浪费;又比如这样的系统可能和铁路的旧有系统不兼容,对旧有系统的升级和改造又是一项巨大的工程;再比如铁路局没这么多资金做这个系统(不要笑,铁路现在很穷的)。

所以,如果你问我12306交给淘宝做,能不能做得比现在好,我觉得是可以的。但是淘宝会接这个单子吗? 我觉得悬。

首先这个项目收益低,基本是一次性的收入,再多也多不到哪去;其次铁路旧有系统的升级改造很可能会有很大的阻力和困难;其次万一没做好,面子丢了不说,可能还要承担很大的责任。

这么个鸡肋的项目,我想淘宝才不会接呢。

最后,昨天写的个单车次放票模拟,2000个座位,30个站,随机起点终点出票并且座位复用,共4个线程,线程1出票,线程2检查票是否放完,线程34随机起点终点查询余票,结果如下:
显示全部

知乎用户,招码农,工作地点杭州半年欧洲半年,熬几…

收起
很好奇,难道12306也会雇水军洗白自己嘛,否则漏洞百出的技术解释,居然也会被转来转去的。估计是12306系统承包商雇的?这样可能性更高。

上面所谓的技术分析文章,反而就是完全没有大规模并发架构经验的人YY之作。思考方式完全不入门。

简单说,要处理这种瞬间峰值,基本原则是接受这不能用平常方法堆叠性能去解决,要设计专门的系统方案去处理。第一要做的是在系统关键点上做降能、限流方案,动态页面降级静态,实时请求转成队列等,不能把压力都压到最脆弱点上形成死节点;第二是要转实时在线计算为预先离线计算,把数据库写/锁操作变成顺序索引;第三是要有预警和触发机制,性能超限就主动拒绝部分请求,不能把所有进程都拖死;

这些方法自然不是写一般商业软件的公司所理解的,更别说大学生了,不过也不至于高大上到国家机密。实际原因嘛,估计是甲方(铁道部)没人愿意出头来承担春运高峰系统宕机的解决之责吧,注定吃力不讨好没有收益大有风险,和治理城郊结合部一样;乙方自然不能说:为每年一次大姨妈,我还需要搭建额外系统,一年只用几个小时,而且又贵又必然表现不如平常。项目经理说出来不是让甲方乙方所有人跳火坑嘛,必须连夜fire的节奏。这种时候,大家默契的装傻,才是商道政道呀。

最后发现跑题了,回到原问题,这是典型的结构性障碍,看似天灾实为人祸,不是乙方不给力,而是甲方难担当。换个乙方没戏,换甲方有可能。

吐槽几句,虽然这个网站活糙价高必然有奸情,但从实际效果说,票最后不还是全卖掉了吗,网站宕机又怎么了,干嘛要做那么好,浪费资源。无非就是你以为上个网站就能获得公平机会结果连形式上的快感都没享受到,又体会到习惯的无力悲催感嘛。网站多宕机一会儿,最好宕个8小时,让连夜排队的民工兄弟们多买几张票,不是更好嘛。

崔钊痛恨道德审判,鄙视道德标榜

收起
看了那么多体谅"政府"苦衷的答案,有点怒了,一方面他们经常混淆“铁路运力紧张”和“12306这个网站是不是很差(能不能做得更好)”,而问题显然是针对后者的。令一方面在不清楚12306网站真正难点的情况下,凭空“体谅”其难处。排名第三的匿名答案还是基本上聚焦在技术上的,确实技术上完美的做到你所说的各种指标有点困难,但是在非关键指标上稍微降低点要求,总是能做的比现在好一些的(有舍才有得嘛),我也在做跟性能很攸关的行业(性能在GB/s的SSD)明白各方面做到完美的方案有时候是不能能的,但是比方说(也许这是个不恰当的比方,见谅),我损失一些数据一致性(也就是允许一定程度的“超售”),但通过一个延迟的订单最终确认环节来补救(最终发现确实超售的在若干分钟/小时内给用户反馈),这样总比让大家都面对一个卡死的网站要好得多。我是典型的工程师思维,有问题我们就想办法解决,实在不行降低要求来解决,但是你不解决问题而是搞推诿(xxx来了也搞不好),搞政治(xxx是关系国计民生/国家安全的重要行业,必须政府来搞),我只能....算了忍了:(

//修改1
真要讲技术,请打开排名第一答案的所有评论,搜@徐峰@王强 的评论,就可以看到技术牛人和铁道部的技术牛人是什么区别了,基本上这也就是12306自己做和请淘宝/IBM/其他大型商业公司做的区别了。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
顺便贴出我在前面的一个回复供喷
抢一天抢不到与抢一秒抢不到之间我还是愿意抢一秒,毕竟省了时间。铁道部自己做做不好和请商业公司做不好,我还是愿意请公司做,其一,淘宝(或其他任何应 付海量访问的顶尖公司)和铁道部谁更专业不是明摆着么(不要说淘宝和12306的业务有多大差别,应为这根本就不是问题点,真正的问题是“请外行做还是请 内行做的问题”,别跟我说铁道部也不"完全"是外行,跟淘宝比起来一个没做过类似业务的单位显然就是外行).其二,放在公司,就算做不成,钱好歹增加了良性GDP,花在铁道部里,天晓得!!!!不要纠结于买不买得到票,因为大家都知道短时间内不可能解决运力问题,所以目前的问题很简单,就是“是不是应该找最专业的人做最困难的事”,答案也很清楚“铁道部里绝对没有最专业的人(团队)

老师说:“大雄,给你90元,你再去跟胖虎借10元,这样你总共有多少钱?” 大雄说:“0元。” 老师说:“你根本不懂数学!” 大雄说:“你根本不懂胖虎!!
技术就是毒品,技术控就是瘾君子,你能在里面找到极度快感,但终究你会死在技术上。自始至终技术以外的世界是和你无关的。

这道‘12306 为什么不外包给淘宝做’题目像极了一大包白色的粉沫状物体从天而降,然后就是捎带血丝的壮观场面,再就是各种

发泄后的快感。
言归正传我们用最最基础论证思维框架‘是什么 为什么 怎么办’来解答这道题。


1.12306网站是什么?
答:是中国铁路系统卖火车票的网站
2.中国的火车票又不愁卖为什么还要建设12306网站呢?
答:为了迎合时代发展呀,现在的人们已经渐渐习惯了在互联网上买内裤、买手纸了,铁老大的车票不能买岂不是为社会主义抹黑吗?那好吧建12306.cn站吧!
3.下属请示领导怎么建设呢?
答:还是老一套呗搞个方案找几个砖家论证一下,申请点资金,大家内部操作一下走个招标的形式,下属单位的业绩要有,兄弟单位的产值也不能少,最好拉个I*M什么的来陪衬一下就更好了,于公于私大家面子上都能过去就行了,毕竟信息化不是修铁路挖隧道没有人命问题,顶多买不到票,我不建站你不照样买不到票,至于技术嘛!!!最好也扔给系统内科研院所,搞得好还可以当自主创新典型嘛!搞得不好也是下属单位好支会好处理。

事实上如果你相信12306网站建立的初衷是为了解决供求的问题,那么请你转到题首研读大雄借钱的故事。
既然精美的UI、优秀的架构、流畅的访问速度解决不了供需的问题那么铁老大为什么要让淘宝建站内?

PS:
关于以上提到的什么内幕呀关联 交易呀什么的请自行度娘,关于太极股份,同方股份背景的请自行挖掘,最重要的是要熟悉国家体制下央企的行事作风,铁老大的老大风格实在是太鲜明了。
至于12306能不能做到精美的UI、优秀的架构、流畅的访问速度呢,答案是肯定的,理由有二
1.从网站上线到如今,铁老大摒弃了I*M清华的Z/TPF,闭门造车自己摸索到2012年能抗11WTPS了,说明他们还是有人才和实力的再搞搞还是大有希望滴。
2.活生生的例子盯着12306的大牛太多了,所以愿意尝试解决的人也多,问题被解决的几率也大,况且现在公认的瓶颈在于集群架构问题,放眼全球能抗20wTPS的系统还是大有人在的。

我们都是技术控,但是我们不是外星人,用技术的眼光看社会,有时还得用社会的心态对待技术。
沒科學的人文是軟弱的、沒人文的科學是麻木的,二樣全沒真就是就是愚昧了

嘿嘿,一直以来知乎都算是一个优雅的地方,当我们在讨论知乎时,我们在讨论什么?

Arron Leung和公众打交道是门学问啊!!!!

收起
知乎用户、余彪、知乎用户 等人赞同
这根本不是一个技术问题。其实12306是可以做的非常流畅,但是,有两个问题;

1,没买到票的人的抱怨该如何解决?

2,购买非常顺畅导致的秒杀,如何解释“内部早就分配好了”的质疑?

前几年,有很多人在网上发帖,说他们搬着小板凳,提前等了大半夜,排窗口第一个,票刚放出来,他/她排第一个都没抢到票,于是在网上大骂“火车票早就内部分配好了”,早就黑心卖给黄牛党了。可是,全国那么多窗口,票只有那么多,就算排第一个也买不到票,这是完全有可能的啊。可是,怎么回应他们的质疑呢?

现在分配方式换成网络。还是那么多人,只有那么多票,不会增加一张火车票的供给。

假如12306购买非常流畅,淘宝上午11点钟放票,大家都苦苦守着,准备11:00可以动手抢票,结果你11:00点击下去没抢到票,再点击,还没到11;01就显示票已经卖完了。你会不会痛骂淘宝?会不会觉得这他妈的就是坑爹的玩意?

这时候汹涌的民意,又该如何对待呢?

至于社会公平问题就更严重了,我用IE浏览器,你用chrome,我电脑2000块钱,慢如蜗牛,你电脑7000,快如猎狗。如果12306购买非常流畅,公平又怎么解决?要知道,用ie,廉价电脑的人数非常庞大,就像不会用电脑,只知道去排队的农民工大叔一样,这部分人也绝不是少数。

这也是为什么12306设计动态验证码的原因,打击那些更熟练使用电脑的人,阻止360等抢票软件,没有一张火车票得来是容易的。在网络层面,把所有人都放在同一条起跑线上,让每个人都必须老老实实来参与抢票这个行为。
呵呵,去年有人在知乎问,如果你是12306.cn网站技术总监,你会如何架构?

我回答,我会直接外包给淘宝去做,省钱省心。

不过老实说,虽然我很希望12306这个网站外包给淘宝去做,却不是因为淘宝的技术力量可以让这个网站解决售票难的问题。


因为火车票的问题的根本还是在于严重的供需矛盾,春运期间火车票太紧俏了,需求量太大了,这个矛盾短时间内几乎没有缓解的可能,而这也就决定了,不论是谁来做这个网站,我们买到票的概率并不会提升,买到票的难度并不会下降除非是我来做,可能会提升我买到票的概率XD

这个供需矛盾的症结则是在于火车票定价是脱离市场的,是被发改委物价局神马的卡死的。别说在春运期间,就是在平日里,几乎都没有什么比火车更为价廉物美的运输方式可以选择,而在春运期间,火车票就像是国家送温暖啊,买到就是赚到啊。

换言之,即使交给淘宝、京东、亚马逊去做,12306可能可以在用户体验,购票流程,或是稳定性方面(其实现在12306的稳定性已经不错了)得到加强,却不可能让大家都满意(因为没票才是硬道理么)。


事实上我很希望12306交由淘宝去做,更多的是为了让12306这个网站洪水般的流量发挥出更大的价值出来,这才是国有垄断企业的糟糕之处。一个中国流量排名Top10的网站,竟然让这些流量成为了服务器的累赘,重资购入大量硬件设备,且完全看不到任何收回成本的希望,这是很大的浪费啊。

铁道部,银行提醒你要还钱了,,,,

刘君臣程序猿、美剧控、历史爱好者、单身待解救

收起
代码优化不出来火车票好伐!!!!!
对于春节一票难求的问题,12306被国人吐槽的体无完肤,我曾今也是其中的一员,但是冷静的考虑后,我对12306表示同情!我表示今年我也没有买到回家的火车票,但是这不能怪12306,请先不要喷,先耐着性子往下看。
第一:公共资源有限
首先,一票难求由中国铁路的运力决定的,只有这么多火车,只有这么多座位,却有好几亿人在这几天同时需要这个资源,光想想就很恐怖。如果保证人人都能买到票,那就只有买更多的火车了,车次增加了就有了足够的座位,那么请试想一下,这么多火车同时在有限的铁路线上跑,你能保证不堵火车?即使调度有方,那节后数量庞大的火车的维护和保养费用谁来买单?平时哪里来的这么庞大的客流量?!
第二:东西部经济差距巨大
试举一例,我是乘坐K529次火车的,这是一列从杭州发往成都东的火车。这列火车要经过浙江省、江西省、湖北省、重庆市、四川省,常规线路连接杭州和成都东就只有这一列火车(临客除外),请再想一下这四省一市有多少人在华东打工赚钱?我想这个数字一定很庞大。平时工作忙很少回家团聚,过年回家更是刚需。真的没有这么多票供应。说到底还是东西部经济发展的剪刀差决定的,如果家乡有很就业机会、有比较好的发展条件、有比较好的薪资待遇,谁跑上千公里去打工?这个是经济问题更是个政治问题,多说无益,希望东西部的经济发展越来越平衡吧。
第三:网站技术架构
在不做技术的人眼中“这不就是买张票付个款吗?这能有多难?”。你不知道隔行如隔山吗?不同的业务场景下的技术实现是不一样的,不要认为你去天猫超市去买包纸巾和去12306买张票是一模一样的。库存不一样好吗?前者是非固定的,后者是固定的;前者只需要写到队列然后闲时更新,后者则需要实时全库查询并执行更新@王强我严重同意楼主举的客户雇人去店面排队的例子各种各样的刷票插件和刷票客户端的出现不仅没有减轻网站压力,反而更加加大了对网站的请求和数据IO,这只会让更多的人买不到票,甚至连网站都上不去。
关于票务系统和其他系统的不可比之处和一些优化方案匿名用户已经做了介绍,我不在赘述。我主要说说12306已经作出的相应调整和优化。
2012年6月选择了Pivotal GemFire分布式内存计较平台(Distributed In-memory computing)革新12306。GemFire分布式内存数据平台的技术原理如上图所示:通过云计较平台虚拟化技术,将若干X86办事器的内存集中起来,组成最高可达数十TB的内存资本池,将全数数据加载到内存中,进行内存计较。计较过程自己不需要读写磁盘,只是按期将数据同步或异步方式写到磁盘。GemFire在分布式集群中保留了多份数据,任何一台机器故障,其它机器上还有备份数据,是以凡是不用担忧数据丢失,而且有磁盘数据作为备份。GemFire撑持把内存数据持久化到各类传统的关系数据库、Hadoop库和其它文件系统中。
当前计较架构的瓶颈在存储,处置器的速度按照摩尔定律翻番增加,而磁盘存储的速度增加很迟缓,由此造成庞大高达10万倍的差距(如上图)当前计较架构的瓶颈在存储,处置器的速度按照摩尔定律翻番增加,而磁盘存储的速度增加很迟缓,由此造成庞大高达10万倍的差距(如上图)。
按照计较与存储的关系,我们可以将计较架构分为四代:
第一代,基于磁盘的单一系统:计较过程中需要从磁盘读取数据。小型机、大型机是其中的佼佼者,将单一系统的机能做到极致。
第二代,基于磁盘的分布式集群系统:计较过程中需要从磁盘读取数据,但通过度布系统将数据分离到分歧的办事器磁盘上,提高整个系统的处置能力。今朝良多大型互联网和电子商务公司采用基于X86办事器的分布式集群系统,依靠海量的X86办事器摆设解决高流量并发的问题。
第三代,基于内存的单一系统:将整个数据库放在内存中,计较过程不需要从磁盘读取数据。整个系统的机能取决于单一系统的机能。传统的内存数据库就是这样的系统,对于企业级的应用可以很好地解决拜候速度的问题,但面临海量数据或是海量并发拜候的扩展性问题就力所不及。
第四代,基于内存的分布式集群系统:GemFire就是这样的系统,并行计较是其关头技术之一,因而可以通过增加办事器摆设规模,在内存计较的根本上,线性扩展机能。


根据系统运行数据记录,技术改造之后,在只采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力,单次查询的最长时间从之前的15秒左右下降到0.2秒以下,缩短了75倍以上。2012年春运的极端高流量并发情况下,系统几近瘫痪。而在改造之后,支持每秒上万次的并发查询,高峰期间达到2.6万个查询/秒吞吐量,整个系统效率显著提高。如上图所示。

订单查询系统改造,在改造之前的系统运行模式下,每秒只能支持300-400个查询/秒的吞吐量,高流量的并发查询只能通过分库来实现。改造之后,可以实现高达上万个查询/秒的吞吐量,而且查询速度可以保障在20毫秒左右。

新的技术架构可以按需弹性动态扩展,并发量增加时,还可以通过动态增加X86服务器来应对,保持毫秒级的响应时间。


结论:
不可否认阿里的技术团队确实很牛X,但是请不要认为除了阿里的技术团队以外就没有优秀的技术团队了好吗?即使阿里来做的话,依然解决不了这个购票难的问题,最多是操作流程和用户体验要好出很多很多!阿里花10年之功才积累到今天这个地步,12306还很年轻。 显示全部

位浩旅游管理学生,正在努力转入会计学

收起

问题真的在网站吗?我买票从没有很困难过,不管用它新上线的app还是电脑,原因是我每次回家有二十多趟车一天,从来就没卖完过,自然就好买,那些买不到票的,主要原因不应该是没有那么多票吗?我个人认为最近几年的铁道部已经发展非常快了,真的不该被这么黑。

Frank高速铁路 CRH380BK

收起
知乎用户、李朋严究 等人赞同
12306外包给淘宝做又能怎么样?

淘宝的优势是什么?
完善的用户体验设计,美观的界面,丰富的高并发处理经验等等,但是把这些优势套到12306上,春运购票体验会有本质变化么?

12306归根结底就是个卖票的网站,虽然她名声在外,万众瞩目,但她在整个铁路系统只是微不足道的一环。12306做的再好,就算并发比现在高一万倍,界面好看一万倍,也不会多制造一张票。

12306不可能承载增加春运运力这么重大的使命。
本人非IT专业出身,有说错的还请见谅指正。

先直接回答题主的问题:票务IT系统和淘宝这样的电商在技术上有很大区别,就像卖包子的在忙不过来的时候不会找卖饼的帮忙做包子一样。

本人给欧美的航空业票务IT系统(简称PSS系统)公司做过项目,从技术上讲跟铁路票务系统是一个性质,就是每当卖出一张票,所有其他销售终端(网站,电话,火车站窗口代销点)正在查票信息的和正在付款买票的顾客都会受到影响,有可能上一秒还有的票下一秒就没了。所以数据在所有终端实时共享更新的要求很高。淘宝和amazon之类的电商就没有这么高的同步要求。

还有一点,每当顾客搜索票务信息时,并不是简单的检索从出发地到目的地的票价和余票数量,全国有这么多火车站,不可能任意两个车站都有直达车,每查询一次服务器要运行一遍路径搜索算法,寻找最快或者最便宜的结果,淘宝的关键词搜索和票务检索的技术区别应该还是比较大的吧。

2010左右年的时候,谷歌开始进入PSS市场,因为这个市场利润丰厚,PSS公司每卖出去一张就能找航空公司收$3-$20左右的费用(廉价航空公司情况不一样),但就算凭借谷歌自己在搜索领域的技术水平,他也没办法直接将技术直接移植使用,而是先收购一个PSS搜索技术公司。全球最大的PSS公司法国amadeus每年光在技术上的投资就不下10亿刀,中铁每年能投入多少?
6986 人关注该问题