12306的码农没有你想的那么弱(转blogjava)

12306的码农没有你想的那么弱
摩尼 http://moni.iteye.com/blog/2001610
从知乎上转来的，讨论还在继续。 http://www.zhihu.com/question/22451397/answer/21426532

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 辩解了
IT精读 http://netcome.iteye.com/blog/2002923

看到有同学转发了知乎上的讨论12306的码农没有你想的那么弱，争论的非常激烈，各种观点都有，老牌技术专家冯大辉fengg，也在自己的微信上发表了文章——别给12306洗地了。反驳了这些帖子，个人觉得很有见地。以下是摘录的原文：

看到各种给 12306 跪舔的洗地贴让我有些看不过去了。虽然已经说过不再为这垃圾话题写东西，再次破例说一下，尽管觉得挺恶心的。

在这篇文章开写之前，我先说一下我的几个观点，如果你你不认同这几点，就没必要浪费时间继续往下看了。

1.公众服务，做得好是应该的，做不好活该挨骂，花了人民的钱不把事情做好，骂你，一点都不冤枉。只有你做到超出用户期望才有资格受到赞扬。

2.人多，票少，肯定会有人买不到票，这是客观前提，这的的确确是 12306 解决不了的问题。作为铁路 12306 系统的用户，我(或是大多数人)的期待只是购票服务要可靠、稳定还要好用，还有，不要乱浪费钱。

3.有一种很愚蠢的评论叫「你行你上」「你牛你去做」「就你牛? 装什么大尾巴狼」，为什么说这种评论愚蠢? 因为你让批评者去做也没问题，可你到时候能给发工资么? 给顾问费么? 你做得了主么?

4.为什么要质疑? 要批评? 吃饱了没事儿干么? 当然不是，简单的说，这是我们每个人权利的一种。你不行使你的权利是你的自由，有人质疑，是质疑者的自由。无论是质疑还是批评，都是想让这个系统变得更好。

5.让一些借机揩油的商业公司滚一边去，我建议最好警惕这些商业公司，包括 IBM 这样的公司，还有一些所谓的体制内专家，也要警惕他们，为什么? 没有利害关系这些人能站出来么? 另外，如果你发现我跟 12306 有利害关系，让我也滚一边去。

6.12306 内部业务对我们还是黑盒子，既然是黑盒子，那就没办法也没必要讨论细节，否则的话，你绞尽脑汁累折裤衩带儿之后给出再详尽的方案，最后还是会被说你的方案不行，不能用。

7.12306 只有更加开放，充分引入技术服务商的竞争，才有可能做得更好。

这些算是前提。

我们首先说说知乎上那个洗地贴。我之所以说这个贴是洗地贴，并不是说那个排名最高的回答者就是洗地党，而是这个贴着实起到了洗地作用。

排名最高的那个回答开头说「12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案，给出的条件是资金管够但是问题得解决。几大企业最后都拒绝了…」这篇回答最开始的版本不是这么写的，最初的帖子开头是一句「听我的同学说」或是类似的一句话，我记不清了，但知乎应该有记录。简而言之，开始的版本就是路边社一类的消息。去掉了这句话，不少傻瓜还以为真是这么回事了。

我们先想一下：12306 有可能给出「资金管够」这种条件么? 不可能的事情。之前花费的巨额资金已经被骂出了翔，谁有胆子敢喊出来「资金管够」? 请问哪位敢负责? 不是意淫是什么? 另外，12306 的态度是很明确的，早在 2012 年九月就有媒体报道 12036 对外的态度「我们12306网站是非营利性质的，不会和商业企业合作，而且我们对自己的技术有信心。」

再说说「几大企业拒绝了」，这个又是胡扯。客观上说一句，IBM 这种公司根本就搞不定 12306，因为 IBM 连苏宁易购都做的不怎么样，能搞定 12306 么? 我觉得难度很大。对于 IBM 这种公司来说，只要有钱赚，不可能会拒绝。有人说你这是臆断，请问有谁听说过 IBM 会主动拒绝用户大单的么?

再说说阿里巴巴，前面已经说了，12306 不可能跟你们这些公司搞商业合作。我了解的情况是，不搞商业合作，但是可以搞搞其他方面的「合作」，比如，技术支持。阿里巴巴的确派出了一只专家团队进场了，这是事实。阿里技术团队帮助他们解决了一些关键问题，也肯定提供了一些宝贵的思路和经验。但同时，我认识的一位参与者也承认，业务的确复杂，牵扯到很多东西，短时间内不好解决。

写到这里，我想诸位基本上就看明白了。知乎上那个回答基本就是在那里瞎掰。

再说说知乎回答里面提到的「分布式集群内存数据技术引领12306技术革命」这个事儿。其实最近 12306 的底气有一大部分是来自这篇公关稿。找到这篇稿件看一下，会发现这就是某商业公司在宣传他们的产品。而且，分布式内存数据技术产品并不只是这一家。如果换用其他同类型产品也能起到同样效果，我不知道是否有人同意这一点?

这篇稿件的亮点在什么地方呢? 亮点在于「技术改造之后，在只采用 10 几台 x86 服务器实现了以前数十台小型机的余票计算和查询能力」，看到没? 这恰恰说明以前的解决方案蠢到家，并不能证明现在的方案屌到爆。12306 也不应该因为做到了及格就出来厚着脸皮邀功请赏。

同时这个事实也打了很多专家的脸，因为当时有不少所谓的专家站出来说「你看电信系统每年都是投入多少钱，12306 投入这么一点怎么能够呢?」蠢货，蠢话。

知乎那个帖子下面又写了一大堆东西，包括提到「全球最强的客运票务系统…12306可以自豪地说自己是做的最好的案例」，说实话，我看不出浪费那么多钱之后做出来这个样子有什么可以「自豪」的，换了别人恐怕找地缝钻进去也差不多。

客观的事实是 12306 的确有进步。这当然值得肯定。这个进步是多少时间多少代价换来的? 别有点进步之后就说「全球最强」好不好? 真的好意思么? 洗地洗到这个份儿上也的确卖力。

对于帖子中一大堆技术性的描述，我建议直接忽略好了。为什么? 前面提到，对于一个黑盒子，你描述太多也无法精准，最后别人稍微揭开一点盖头，就会说「你看，你错了吧?」

作为对这个帖子的陈述，我最后再说一个客观事实：12306 这个项目开始就已经是外包的了。只是外包给所谓「有资质」的单位而已。网上公开新闻写着呢「中国铁路客户服务中心、也是火车票唯一网购网站12306的设计招投标，申报方案仅有中国铁道科学研究院电子计算技术研究所和易程科技股份有限公司两家。最终，在业界眼里实力雄厚的易程科技未能中选。作为铁道部下属机构，招标变得更像走形式，铁科院的中标犹如从左手到右手…」我只是引用媒体内容啊，请勿跨省。

回到开头，我说这个帖子客观上起到洗地的作用。不知道诸位是否认同?

再说第二篇洗地文章。这篇文章来自「西西河」社区。作者号称是「前淘宝工程师，后来在一家电商公司做技术副总」，洋洋洒洒写了一大堆。此人在西西河上从2011 年注册至今只发了一贴，并且当初是他提出做开源订票系统的人，我了解的是，当初牵头做 12306 开源系统的人是京东副总裁李大学先生。请问这位作者能公开一下自己的身份么?

此篇文章的一个重点是说：你看百度淘宝每年也投入那么多钱，每家都几千个工程师，百度一年的研发费用 10 亿什么的，还有携程之类的公司技术还比不上 12306 呢。我估计很多人一想，「好像也对啊，百度淘宝每年花那么多钱，12306 花虽说花了不少，可也做到了，12306 挺了不起啊」。这种说法混淆了一个事实：百度淘宝都不是单一服务应用，而是由多个应用服务组成，比如淘宝，简单的不那么科学的划分一下起码要有：Web 系统(你访问淘宝看到的那一堆东西)、搜索系统(你要搜索产品)、交易系统(下订单购买的过程)、后台支撑系统(物流风控安全)…如果要比较的话，那也是比较整个中国铁路的 IT 系统成本才行，或者应该只比较交易系统成本才好吧?

除此之外，除去外包成本之外，我们也不知道 12306 的人力成本和维护成本到底是怎样的，因为什么都不透明，甚至我们也不知道采购商业公司「分布式集群内存数据技术系统」到底又花了多少钱。

别跟我们偷换概念。

另外，我有个建议: 既然说到了百度的研发投入能公开查到，那不妨不涉及机密的情况下呼吁 12306 也把研发费用具体是怎么花掉的公开一下好了。这样，群众也放心一些。当然，这实际上是不可能的。别着急，淘宝目前还不是上市公司，等到上市了，淘宝乃至阿里的研发成本大家自然也会知晓。

洗地贴一般到了中后部分，又会加上一堆技术细节或是伪技术细节的讨论，这些内容也最唬人，看不懂的一下子就被镇住了，我也在想要不要我也加上一堆，不过这个文章已经够长了… 我前面说过，对于一个「黑盒子」，无论你怎么去反驳，最后还会陷入困境。这跟江湖把戏「红蓝铅笔三张牌」差不多，会被稍微知道黑盒子里面构造的人说你「Too Simple . Sometimes Naive」，我的一位好友就是这么中招的，很早他就说几十台服务器如果设计好的话，应该就够了，这是他那篇文章的核心观点。结果被无数马后炮指出各种细节缺陷，问题是，能没缺陷吗? 不少做技术的人，脑子真是秀逗了。

对于本文中提到的两篇文章的原作者，我不知道你们是出于什么目的写这两篇文章，或许你自己并不是洗地党，我也无意冒犯你们。我很好奇你们的自豪感来自哪里，另外，这两篇文章客观造成了洗地效果，让人非常遗憾。

最后，我想说的是，能看到我这篇文章的人，应该大部分都是这个国家的年轻人吧，别因为一张车票而搞得心烦意乱，更长远的解决之道是：努力工作，努力赚钱，争取以后买机票回家。尽管这句话听起来挺无厘头的。

前淘宝工程师谈12306：曾嗤之以鼻，现在认为几乎是奇迹
http://www.guancha.cn/Science/2014_01_11_199046_s.shtml

1月11日起，12306网站开始销售除夕当日火车票。每到此时，铁路系统唯一的官方购票网站12306就会成为众矢之的。今年也不例外，12306再次被淹没在一片埋怨声中。

1月5日，观察者网刊登了问答网站“知乎”上的用户王强的解答，回答“如果把12306外包给IBM或者阿里巴巴来做的话，能不能比现在做得好？”这一问题。

1月10日，一位ID名为“代码狗”的前淘宝工程师，后来在一家电商公司做技术副总的IT业内人士也在著名论坛“西西河”上发文，表达了他自己对12306系统的看法。

值得注意的是，“代码狗”在12306系统刚上线时也有过不少微词为了证明12306系统很容易搭建，“代码狗”甚至曾经发起过一个名为“替12306设计系统”的开源项目。通过工作中的实践，“代码狗”对于12306系统也有了新的认识。

观察者网转载此文，供读者参考。

全文如下：

官方订票网站12306崩溃时的页面（资料图）

本人淘宝技术专家，2012年在一家百强民企做电商副总，当时在极为艰苦的条件下带队开发了一个B2C（企业针对个人开展的电子商务活动——观察者网注）网站，走支付宝和银联支付通道，年营业额千万级（作者注：当然实在太少了，我只是说这个网站投入了实际的运营）。

也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足12306的需求。

在平时，12306也就是个正常的电商网站。但一到黄金周，12306就是一个全站所有商品都秒杀，所有SKU都是动态库存的变态。

即使不考虑线下既有的电话、代售点等渠道，要实现一个12306，最少最少也是千万级别的硬件投入（作者注：这是当时的估算，没有精算，可能与实际相差较大，总之，我说得不一定对，12306的业务也许没我说的那么复杂，但也绝不是某些人喷的那么简单），软件和人力另算。那些叫嚣只要40台服务器、只要2个架构师4个程序员、大谈分库分表和前端CDN的人们，只是纸上谈兵罢了。所谓初生牛犊不怕虎，做了三年CMS和BBS，就以这个经验来喷12306，未免太天真了。

媒体人喷12306，是他们不懂技术，没有能力和耐心来分析背后的难度。技术人员喷，则是因为大部分的技术人员在短时间思考时，容易陷入过于乐观的误区，经典的例子就是估算工作量，程序员们往往容易估算出一个超短的工期，把写程序的工作乐观地想象成了打字员照稿敲键盘的工作。

知乎那篇文章，我觉得不是洗地。排名第一和第二的答案都说得很客观。淘宝技术是比12306强大很多倍，淘宝现在的系统也是花了10倍于12306的钱、时间和人才做起来的。根本原因还是铁路运力不能满足春运需求，淘宝也解决不了这个问题。

12306这一年来进步非常大。从前段动画验证码、分时段抢票，到后端去小型机、虚拟化、内存数据库的运用。可以说，12306是中国政府机关做的最强大的网站（电商系统），能在短短一两年内做出这样的改变，几乎是个奇迹，就连一些市场化的民企都望尘莫及，甚至一些上市公司都比不上它！（比如51job和ctrip）。

事非经过不知难，在网上批判12306的人，大部分还是形成了【国企=垄断+腐败+低效】的思维定势。小部分是真的轻视了它的难度。

至于12306一期工程3个亿（含硬件）贵不贵我不评价，我只提供一个数字供参考，百度一年的研发费用（不含硬件）是10亿，这个数字来自百度财报。网上能查到。3亿看起来好大一个数字，真用到超大型的电商系统、搜索引擎系统里面，其实也不算什么天文数字了。
（黑一下： 百度研发的产品单一吗?
除了搜索, 知道,贴吧,文库,云... 等等不要研发吗?
单就一个搜索不比12306复杂?
百度投在搜索一期的研发费用能赶上12306?
所以拿一个12306系统跟整个百度有可比性么？）

再解释一下，为什么秒杀压力大，以及为什么12306的动态库存很复杂。

先说秒杀。

2013年12月25日前后，天猫搞了一个圣诞季积分兑换活动，持续几天。25号上午10点12分，放出了15000个天猫魔盒（淘宝集市有人卖，大概190-230块），从成交记录上看，是19秒内全部抢完。

实际上，我也参加秒杀了，那天的题目特别简单（请输入xxx汉字的拼音首字母），我应该是5秒内答题完成并提交订单，结果告诉我排队的人太多，挤不进去，并提示14秒以后重试。人太多就是因为题目太简单了，门槛越低，5秒内挤进去的人也越多嘛，如果题目换成【2克浓度为3%的U235在大亚湾核电站能发多少KW的电】，5分钟之内也不会有1万5千人跟我竞争。

我想，14秒以后哪还有我的事情呀，于是重新答题秒杀，结果出现了服务器错误的页面。反复刷新几次，就告诉秒杀结束了。

在群里问了一下同事，有不到10个人回答我，都说没秒到（也可能秒到的人闷声发大财，不回复我）。

淘宝是什么技术水平呢，淘宝有至少4000技术人员，至少4万台服务器（这都是两年前的公开数据了，按规定可以谈论），2013年11月11日成交额351亿，2012年全年成交额超过1万亿。

淘宝拥有各种自主研发团队：服务器、交换机（网上可以搜索到淘宝公开的绿色服务器开放标准）；操作系统（LinuxKerneltaobao版，yunos手机操作系统是阿里云的，暂时不计入）、Web服务器（Tengine）、Java语言虚拟机（JVMtaobao版）、数据库（MySQL内核taobao版，google和facebook也有自己的版本，HBase淘宝版、还有自己全部从头开发的OceanBase）、负载均衡器（LVS，LVS始创人就在淘宝，担任研究员）、Java运行容器（Jboss，其创始人之一，王文彬，也在淘宝，担任副总裁）。

淘宝还有数不清的开源项目和中间件，如高性能Java通信中间件HSF、分布式数据库中间件TDDL、异步消息系统notify等等等等。

以淘宝这样的技术水平，也不能做到秒杀时让每个用户都没有拥挤感，为什么呢？

一是要尊重物理原理，一台服务器一秒钟能承受的计算量是有极限的，任你怎么优化，采用多高效的算法和编程语言，都突破不了某个极限，比方说汽车发动机驱动的F1赛车至今也不能突破400公里的时速（超音速推进号那个1千多公里的时速不能算，那是飞机引擎驱动的）。再往深了说，就不容易懂了。感兴趣的可以从著名的C10K问题开始看起。

二是要考虑经济效益，十一黄金周的时候，北京主城区到八达岭长城的路堵得严严实实，但不能因为黄金周的高峰，就把这段路修成长安街那样10车道的高速公路。否则的话，花费天文数字（真的是天文数字，12306那3个亿大概只够修1-3公里）。修了一段路，黄金周是可以飙到80公里/小时了，可平时呢，拿来给两边的居民晒谷子？

淘宝目前的硬件和带宽数量，已经超出日常运营的需求了，就是留了相当大的余量给大促销（众所周知的是双十一，双十二，其实基本每个季度都有大促销，每个月都有促销，甚至天天都在促销——聚划算）。amazon当年就是为了应对黑色星期五的大促销购置了大量的服务器，平时订单量没那么大了，amazon就把富余的服务器拿来搞云计算了。顺便说一下，阿里云是当今中国第一世界数一数二的云计算服务商，和amazon走的路也有点像。

再说动态库存。

翻页继续看

淘宝秒杀天猫魔盒的时候，只有一个商品（行话叫做SKU），它的库存是15000个。有一个人秒杀到了，库存就减1，19秒卖完的，一秒要成功产生789个订单（下订单的请求可能是8万个，只是可能啊，非实际数字，也可能是1万个，用于说明一下壮观程度）。想象一下，你在广场上卖火车票，一秒钟有8万人举着钱对你喊：卖给我！

上过大学的人都知道，比秒小的时间单位还有毫秒、皮秒、飞秒。但交易系统登记一个交易可不像原子绕着原子核跑一圈那么简单，它要做这些事：检查是否恶意访问、取到系统时间、取到顾客默认收货地址、核对顾客秒杀资格（当时的规定是天猫T2.T3达人）、生成订单号、把顾客ID系统时间订单号收货地址写入订单系统、扣除顾客天猫积分、商品库存减一、给顾客打标记（每人只能秒一个，下次不能秒了）等等，这每一件事都要花费毫秒级别的时间，这些操作加起来的时间可能是接近1秒级别的，但由于淘宝的服务器比较强悍，而且采用了分布式和集群技术，结果比1秒理想一点。但即使有1万台服务器，也不能把这个时间稀释成万分之一秒，因为，商品只有一种，它有15000个库存，对应的数据库记录只有一行，所有的交易请求都要到这里来处理。

能不能把这15000个拆分成5000个商品并分配到5000台服务器上呢？那样不就可以5000台服务器同时处理了吗？答案是不能，首先，5000个商品，意味着有5000个商品详情页，5000个购买按钮，这对前期的营销、引流是个灾难。基本上就没法做引流入口了，显然这违背了商业管理原则，人为增加了信息混乱程度。其次，天猫魔盒秒杀也不是啥大事，即使按官方标价399元来计算，也就6百万的交易。如果6百万的交易要花费那么大的配套成本，那就太不划算了。再次，淘宝有十几亿商品，这十几亿商品的展示交易和管理，本来就是分布到上万台服务器上去了。没有必要再把每个商品按库存拆成多个商品了。

这789人抢到了，还不一定会付款（99积分换天猫魔盒还好一点，不需要去网银，成本也极低，大部分是会付款的，3999秒杀iPhone5S就不一定，有人可能网银有问题，有人可能改变主意不想要了），所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们，会认为还有机会，继续在前台刷一会儿，最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。

一分钟过去了，服务器终于可以喘口气了吧？等等，还有超卖，原来，某两台服务器在同一毫秒都拿到了锁，都去减了库存，15000个库存，被下了15500个订单，又得取消一部分订单。。。如果采用单线程独占锁，是可以做到同时只有一个服务器线程减库存的，但那样就对并发高峰的能力就差了好多了。8万人举着钱，可能只有8个人能下单成功，这个拥挤狂热的抢购就要持续10分钟以上。平时秒个天猫魔盒，10分钟也就10分钟吧，双十一就惨了，收银台一下子减少了90%，还想做到350亿，要么做梦，要么再加10倍服务器和带宽。所以，商业是不完美的，要在绝对正确和绝对的快速之间做个取舍，保证相对快速又极为正确，允许一定的库存错误和超卖（具体允许多少我也不知道）。

好了，讲了这半天淘宝，可以说12306了吧？

我以北京西到深圳北的G71次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫G72），它有17个站（北京西是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员（包括某些中等规模公司的专家、CTO）就是在这里栽第一个跟头的。

实际上，G71有136*3=408种商品（408个SKU），怎么算来的？请看：

如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品，

同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136种票：16+15+14....+2+1=136。每种票都有3种座位，一共是408个商品。

好了，再看出票时怎么减库存，由于商务、一等、二等三种座位数是独立的，库存操作也是一样的，下文我就不再提座位的差别的，只讨论出发与到达站。另外，下文说的是理论世界的模型，不是说12306的数据库就是这么设计的。

旅客A买了一张北京西（01号站）到保定东（02号站）的，那【北京西到保定东】这个商品的库存就要减一，同时，北京西到石家庄、郑州、武汉、长沙、广州、虎门、深圳等15个站台的商品库存也要减一，也就是说，出一张北京到保定东的票，实际上要减16个商品的库存！

这还不是最复杂的，如果旅客B买了一张北京西（01号站）到深圳北（17号站）的票，除了【北京西到深圳北】这个商品的库存要减一，北京西到保定东、石家庄、郑州、武汉、长沙、广州、虎门等15个站台的商品库存也要减1，保定东到石家庄、郑州、武汉、长沙、广州、虎门、深圳北等15个站台的商品库存要减1。。。总计要减库存的商品数是16+15+14+……+1=120个。

当然，也不是每一张票都的库存都完全这样实时计算，可以根据往年的运营情况，在黄金周这样的高峰时段，预先对票做一些分配，比如北京到武汉的长途多一点，保定到石家庄的短途少一点。我没有证据证实铁道部这样做了，但我相信，在还没有12306网站的时候，铁道部就有这种人工预分配的策略了。
（问：卖票的规则确实如此？）
（网友理解：
如：福州开往福鼎（福州->连江->宁德->霞浦->福鼎）

分站编号: 福州->连江 1->2
分站编号: 福州->宁德 1->3
分站编号: 福州->霞浦 1->4
分站编号: 福州->福鼎 1->5
分站编号: 连江->宁德 2->3
分站编号: 连江->霞浦 2->4
分站编号: 连江->福鼎 2->5
分站编号: 宁德->霞浦 3->4
分站编号: 宁德->福鼎 3->5
分站编号: 霞浦->福鼎 4->5

分站总数: 10
如：购买福州->霞浦 1->4
根据下标过滤，将定义好的序列载入缓存操作，将日志推送数据库。
）

（作者果然只是个工程师，
12306如果只存在妙杀问题，也就不会让人异议了，就像没人异议淘宝的秒杀一样。
12306真正的问题是处理请求慢，响应慢，无论怎么狡辩都是技术问题。

技术问题分析：
全国一共有几条主干火车线，也就20条左右，最多50条，我这是按照20年前的地理课本估算的，因为从我记事起中国就没新增什么铁路，很多路都是建国前修的，非常非常悲哀的事。
一条干线一天也就500次列车，一次列车也就2000来个坐位。一次列车的数据都弄到内存里，也没多少，2000个数据在内存里处理起来也不复杂。一天全线数据也就20*500*2000=20,000,000这个2000万数据在这个云计算时代怎么也算不上大数据吧。

再说压力问题：
就算全国有12亿*30%=3.6亿人回家。就算他们要在5天内回家，每天为0.6亿，平均分配到20个干线，每干线为0.03亿人，分配到500次列车，每次列车为0.00006亿人，也就是6000人。也就是最多只有6000人要坐同一车次。三个人抢一个坐位。这个数量的竞争也算高并发吗，可笑之至。

就算12306处理不了，这些所谓的高难问题，那么已暴露的那些低级可笑的幼稚问题，还少吗？
这也算是技强悍吗。
）
(
楼主的思路有问题，这样算当然会疯掉，需要变个思路！
假设一列车从 A站驶往Z站，列车可同时容纳2000名乘客
　　途径站点示意图如下：（用专业的话说，一个长度26的数组）
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

　　有乘客甲购买了从 C --》 R 站的车票，则在本列车对应站点的数组位置 +1，这里注意R站下车，R站不加1
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
　　0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0

　　乘客乙购买了从 H--》V 的车票，同样在本列车对应站点的数组位置再 +1
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
　　0 0 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 1 1 1 0 0 0 0 0

　　乘客丙购买了从 U--》Y 的车票，同样在U,V,W,X上站点的数组位置 +1
　　A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
　　0 0 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 1 1 2 1 1 1 0 0

　　那么当乘客丁要购买从 A --》 P 站的票时，系统只要计算，从A站 --> P站位置上乘客，是否每个站点的乘客总数都小于2000即可。
小于2000，就说明有票可出售，车上有空位，至于另一些同学提出的位置问题，完全用另一张的表记录票与座位的关系即可。
)
(票是区段方式出的，算法必须靠近区段，层主算法思路基本是靠谱的)

想象一下，8万人举着钱对你高喊：卖给我。你好不容易在钱堆里找到一只手，拿了他的钱，转身找120个同事，告诉他们减库存，而这120个同事也和你一样被8万人围着；也和你一样，每卖出一个商品要找几十个人减库存……这就是12306动态库存的变态之处。比你平时买东西的任何网站的库存机制都复杂几十上百倍。

再说一下抢票插件，机器永远比人快，当你好不容易从8万人里突出重围，来到了柜台前，你发现，我操，来了10万根绑着钱的竹竿，而且当有退票出来的时候，你要闯过3层人肉才能接近柜台，竹竿在8个人身后一伸，钱就到了柜台前。你低头看了一眼手机，票就没了，竹竿却永远在那里伸着，永不低头，永不眨眼。如果没有这10万根竹竿，虽然你很可能还是抢不到票，但不至于沮丧成这样：我TM为什么总是手最慢的一个？！！

防机器人抢票，也不是加个图片验证码那么简单。我写过文章系统性分析过，图片验证码有6种机器暴力破解的办法，抢票插件用的是我说的第三种，OCR识别（光学字符识别——观察者网注）。Google采用的Wave波形字母已经能比较好地防住机器OCR了，ems.com.cn上的验证码就是反面教材，机器OCR成功率接近100%，12306的比ems的图片验证码强一点。不过，验证码设置得复杂一点吧，人们要喷：这只是便宜大学生和办公室白领，农民工连26个字母都认不齐，怎么搞？搞动画验证码吧，也有人喷，视力不好的人怎么办？最后验证码搞得太简单了，皆大欢喜了，其实最高兴的是开发抢票插件的公司。

就算采用了机器完全不可能识别的验证码，也防不住社会工程学的破解办法。招募一堆网吧打游戏的青少年朋友，每成功输入50个验证码给1块钱，或者等值的虚拟货币、游戏装备，我保证想赚这个钱的人数不胜数。这点钱对转卖车票的利润而言，是可以接受的成本。有没有什么技术可以防住社会工程学的破解办法呢？能防住网吧青少年的验证码只有【2克浓度为3%的U235在大亚湾核电站能发多少KW的电】。

以上讨论只是把12306当成和淘宝一样没有历史包袱从零起步的交易系统，实际上，它不是，它后面的票池，还有电话售票、火车站售票、代售点售票等多个传统渠道要服务。除了客运服务，12306还有全国最大（很可能也是全球最大）的大宗物资货运系统。

架空政策（包括定价政策、警方打击黄牛政策、身份验证政策）谈技术，是不可能解决春运抢票困局的，要想让春运的时候每个人在12306抢票都毫无拥挤感（但不一定能抢到票，铁路运力摆在那），那就是逼着12306买一大堆服务器对付春运，春运过去后，成为跟amazon一样牛逼的云计算服务商。和逼北京修一条10车道的高速公路去八达岭长城一个道理。

目前的12306技术上是还有问题，比如，抢票高峰，输入个身份证号和图片验证码都卡得要死（本人亲测），服务器端繁忙，你浏览器端卡什么呀。

但人家在进步。相信2014年春运的时候，技术已经不再是一票难求的主要问题。在铁路运力不可能神速增加的情况下，要做到春运更公平地买票，需要停靠政策调整。

下文针对的是春节国庆这种非常暑期。其它时期，大部分线路保持现状就行了，问题不大，极少部分票源紧张的线路可以按春运处理：

1、拍卖法，价高者得之

当硬座票拍出飞机票价格的时候，相信票就不难买了（可惜就是贵了），也没有那么多黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的，淘宝的拍卖系统可以帮忙，浙江省高院在淘宝拍卖一年多，成交26亿。

可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了，何况是拍卖。再说，火车票毕竟是生存之刚需，票价20年来不涨本来就有照顾补贴的成分在里面，全拍卖可能也是不妥当。

2、抽签法，运气好者得之

开车前2个月开放报名，开车前7天抽签，中途可取消。预存票款，抽不中退款。上传身份证和正脸自拍照，机器核对。

这样的话，拦截黄牛的成功率就高很多了，黄牛可以预存票款，可以找到大量真实身份证号，你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给你试试？即使有人真想找黄牛，给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多，黄牛成本提高，还不一定搞得到票。反正都是碰运气，我想真正的消费者还是会选择自己先去碰运气吧。

这个方法实施难度也大，无论怎么设计抽签规则，必然有人大叫“有黑幕，不要相信政府”。

开车前7天出抽签结果，改变行程的人应该在7天前就能决定改还是不改了。没抽到的也还有时间想别的办法。当然不一定是7天，15天，10天也可以，具体几天要有数据模型来算。

3、拍卖+抽签

软卧、高铁商务座等高价位的，拍卖，反正买这个的是经济能力相对较强的。那就拼谁经济能力更强吧。

硬座、站票抽签。

4、凭身份证进站，车票跟发票一样，是报销凭证，不是进站凭证；退票后钱进入12306账户，不可提现，只可该乘客下次乘车用；黄金周期间，个人账号最多订购10张票

这个办法可以打击黄牛囤票再转卖；运行一段时间后，按账户余额弄个排行榜就知道谁是黄牛，可惜这个需要车站设备改造配合。

12306的码农没有你想的那么弱(转blogjava)相关推荐

也说春运网络购票：12306的码农没有你想的那么弱 [转]
12306首秀被骂的狗血喷头后铁道部找来IBM.阿里巴巴等大企业要解决方案,给出的条件是资金管够但是问题得解决.几大企业最后都拒绝了.12306开始自己尝试解决问题.他们发现市面上可以买到的成套解决方 ...
28岁学python转行_28岁转行程序员，学Java还是Python？码农：想快点月薪过万就选它...
为什么要学Java? Python给人的印象简单是因为我们在用Python的时候,可以直接调用别人已经写好的代码接口就可以,相对于傻瓜模式,Java的许多处理都要原生很多,写的代码可能会多一些,但一旦 ...
阿里云喻义：十年牧码，从码农走向工程师的进化之路
有人会问,码农和工程师有区别吗?有什么区别?相信每个人都有不同的理解. "你敲下的每一行代码,你想过他会如何在计算机上运行吗?你想过你的这一行代码会产生多少cache miss吗?你想过你的 ...
为什么很多大学生甚至研究生抛弃专业去做码农呢？
作者:Marisa Hakurei 广州市对2017年全市劳动者工资统计中,互联网制造业从业者与化工类制造业从业者的工资对比如下: 绘制成图表,更加明显: 看到了吗,什么叫做差距?这就叫差距. 图中蓝 ...
国外发达国家码农是真混得好么?
链接:https://www.zhihu.com/question/38972340 编辑:深度学习与计算机视觉声明:仅做学术分享,侵删好多万众瞩目粉丝众多的知名海外码农的真实生活是怎样的?海外工 ...
湾区和西雅图的码农，谁过得更爽？
西雅图最近有点火呀!? 在美国求职网站Hired发布的2019全球程序员薪资报告中,西雅图被评为:码农最想relocate的城市TOP2! 而在想要逃离湾区的码农心中,西雅图则是首选! 前阵子,就有年 ...
为什么硅谷码农们越来越不待见亚马逊
本文转载自硅星人如果要把硅谷的科技公司按照名气和规模来划分个三六九等,市值过万亿.员工超百万的亚马逊无疑是属于金字塔塔尖的那一小部分. 但如果你让一个硅谷程序员按照入职意愿来把科技公司们进行排序,那 ...
解放码农，飞算全自动软件工程平台的创新“套路”
一个普通IT工程师凭借飞算全自动软件工程平台,毫不费力地仅用28分钟轻松挑战三个资深IT工程师近两个小时才能完成的开发工作成功.11月17日这样一个现场PK活动环节,引发了业内众多的讨论. 不敲入任何 ...
Python为什么这么厉害? 不想成为专业码农? 来学习Python吧!
2019独角兽企业重金招聘Python工程师标准>>> 什么是码农? 什么是码农,大家用它来自娱自乐,然而,其中的辛酸只有程序员自己知道.程序员冲锋在第一线,各个人都在盯着你的结果, ...

12306的码农没有你想的那么弱(转blogjava)

12306的码农没有你想的那么弱(转blogjava)相关推荐

最新文章

热门文章