|
|---|
|
|
|
|
|
|
g*********e
发帖数: 14401 | 1 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包给知名大企业是否会更好？答案是，无论谁来做，最终结
果都是一样。
2014-01-10 | n****1
发帖数: 1136 | 2 TL;DR
高度耦合是铁道部业务逻辑的一部分. 在非春运时用低耦合, 不卖联程之类的, 一定会
被骂死.
至少现在订票后端没大问题了, 好好优化中间件就可以了. |
|
|
|
|
|
|
