知乎上看到的，转载过来，雅俗共赏
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格甚高的话。
一是实干兴邦，空谈误国。
二是宽以待人，严于律己。
三是取舍之间，必有得失。
四是如鱼饮水，冷暖自知。
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
- 其一，有人可能把这个东西和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通常伴随着分布式存储）。（关于负载均衡更为详细的说明见“后端的负载均衡”）
二、减少前端链接数
我看了一下http://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）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。