[ZT]12306的码农貌似也挺厉害啊

从知乎上转来的。
  

  
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自己。
  
所以，走自己的路，让别人去说吧。

baolongeri

其实我也认为12306确实很难做，买不到票根子在于铁路部门腐败，不管是怎么卖票，票还是被黄牛买走了。和网站的关系有，但是不大。

xiaosage

淘宝的问题是其系统架构是分散度较高的，各个订单之间关联度不大；而12306每出一张票都要对全线路做数据更新（因为一条线路存在多个站点），因此系统负载相较淘宝来说集中很多，直接搬淘宝的方案也无法解决问题。淘宝的应用类型决定了阿里巴巴可以通过部署大量的服务器来分散压力，但12306就不行。其实他们的核心系统的硬件成本不过数百万，不是他们不想采购更多服务器，而是买更多的服务器也没什么用途。最后，在经过软件层面的优化之后，12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情，而是受限于摩尔定律，基本上每两年才能翻一倍多些。（这段话是我自己的分析，不过现在12306的后端数据库系统应付现有需求已经够用了）

关于这一点，铁道部最早的在站点买票的网络系统就已经实现了实时刷新票据数据，这个算不是技术难点了吧。
防黄牛最简单的方式就是采用真正的实名购票，网上购票系统把公安部的身份信息导入核实，每个真实的姓名及身份证号码核对正确后才能买票，再增加手机动态码验证，这样黄牛就没法通过假身份刷票了，哪怕用这前保存的真实身份刷到票了，也无法验证每一个手机动态码，而真实身份证号所有者可以通过查询自己身份证号上是否有购票信息。
楼主应该是铁道部码农。