国际调查记者联盟：瑞银为铁道部官员妻女建离岸公司

UBS（瑞银）最近深陷丑闻，因为该公司被指为原铁道部副总工程师张曙光的妻女在离岸设立秘密公司。去年9月，张曙光承认在2000年至2011年之间受贿4700万元人民币（约合5970万港元），以帮助企业谋取利益，目前正等待审判。
张曙光是原铁道部部长刘志军的得力助手。去年7月，刘志军因受贿和滥用职权罪被判处死缓。
国际调查记者联盟（ICIJ）的资料近日披露，张曙光的妻子王兴和女儿张希希（音译）是英属维尔京群岛（BVI）上一家名为East Asia Group Trading的公司股东。ICIJ的总部位于美国，去年开始披露一些知名度高和人脉宽广的人的秘密账户，其中包括几名中国大陆人士。
ICIJ的资料显示，UBS是East Asia Group Trading的“秘书公司”（master client），即为客户设立离岸公司的中介机构。
UBS最近深陷违规雇佣的丑闻当中。日前，UBS对聘用天和化工董事长魏奇的女儿魏娇（Joyce Wei）一事展开内部调查，随后对两名员工进行停职处理。此前，UBS曾被视为负责天和化工10亿美元的在港上市项目的强力竞争者。
据报道，美国监管机构正在就投资银行违规雇佣一事展开调查。这些银行被指雇佣人脉宽广的内地人作为员工，以为公司获取可能被视为不正当的利益。
“这家位于BVI的公司被‘有政治风险’（politically exposed）的人的妻女所持有，UBS应该对此表现出谨慎的态度，”香港风险顾问公司Pacific Risk的董事Julian Russell。“有政治风险”是风险业内的专用术语，用以描述很可能牵涉腐败的潜在客户。
“UBS帮助（她们）设立了这家BVI离岸公司。帮助设立BVI公司的人们就像枪店的店主一样。他们应该对买枪的人进行背景调查。”
2009年，UBS因为被指为1万7000名美国人提供秘密的逃税服务，被美国政府处以7千800万美元罚款。
Russell表示，虽然一个人拥有离岸公司本质上不是不合法的行为，但这家公司有可能是为收受贿赂而设立的。East Asia Group Trading的经营活动目前尚不清楚，没有证据显示该公司有任何不正当行为。
然而，作为铁道部高官的妻子，王兴持有一家BVI公司，同时，她在为铁道部门提供铁道零件上扮演着中介的角色。Russell表示，这不得不引起人们的疑虑。
据内地媒体财新网报道，在张曙光任职铁道部高官期间，他的妻子向国际公司提供协助，以中介人的身份为这些公司获得为内地铁道项目提供火车零件的合 约。报道称，2004年，铁道零件制造商无锡万里实业发展公司在吴兴的牵线下，和德国品牌Evac达成合作。Evac并没有回应《南华早报》的电邮查询， 无锡万里也没有接听记者的电话。
“当然，如果丈夫在铁道部里工作，妻子卖火车零件给中国的行为会引来质疑。就算这当中没有涉及到贪腐，这样的行为对于公司管治来说也是不好的，”恒生管理学院商学院院长苏伟文表示。
11月，张曙光的情妇罗菲承认，曾帮助张掩盖其收受贿赂的行为。
ICIJ的资料显示，王兴和一个名为王瑞婷（音译）的人在2005年7月4日成为East Asia Group Trading的股东和董事。而在1年前的2004年，张曙光开始参与中国内地投入过千亿元、近年被贪腐丑闻缠绕的高铁项目。
资料显示，张希希在2009年6月17日成为East Asia Group Trading的股东。2008年，她进入摩根大通的香港分公司工作，并在2010年辞职。美国政府现正就雇佣内地高官子女一事对摩根大通进行调查。
苏伟文表示，张希希在摩根大通工作期间持有离岸公司的股份，是引起疑虑的原因之一。
UBS和摩根大通拒绝回应记者的查询。记者亦未能联系到张希希和王兴。

文章来源: http://goo.gl/7HfkKz

12306 春运能否不瘫痪（民生三问）

    一问　为什么抗不住高峰点击量？
　　单日点击量高达144亿次，相当于全国每人点击10次
　　记者：今年春运，通过12306网站售出的火车票已占全路售票总量的50%以上。与去年相比，今年12306网站的购票量增长了多少？
　 　朱建生：今年春运，从网络售出的火车票数量比去年增长了至少50%。购票是旅客出行的第一环节，铁路部门按照让旅客“安全出行、方便出行、温馨出行”的 春运目标，努力让广大旅客方便购票。通过努力，今年铁路春运已彻底改变了以往广大旅客彻夜排长队、长时间辛苦等待购票的场面。
　　记者：今年春运售票期，12306网站曾再度瘫痪，高峰时段的点击量有多高？
　　朱建生：1月9日，当日开始出售1月28日的火车票，是今年的售票高峰日。这一天，12306网页点击量高达144亿次，相当于全中国每人至少在12306网站点击了10次。这一天的网页浏览量高达88亿次，相当于全中国每人都浏览了12306网站6次页面。
　　记者：不少旅客觉得平时通过12306网站订票还是很方便的，但是一到春运，订票的速度就慢了很多，旅客们期待是否能通过不断增加带宽等措施，使春运购票也能畅通起来？
　　朱建生：我觉得网友“代码狗”在西西河论坛中发表的一个帖子里有一段话非常专业：从物理原理讲，服务器每秒钟能承受的计算量是有极限的。从经济角度考虑，一个网站不太可能以最高峰值的承受力为标准来建设。
　 　春运高峰期的点击量、浏览量是平时的几倍，甚至十几倍，我们只能在满足日常需求与高峰期售票需求之间寻求一个最佳点，合理进行硬件配置。打个比方，这就 好比网站的能力是每秒处理几千张票，但是高峰期的需求是每秒几万甚至十几万的购票需求，那么我们只能对需求进行异步化处理，通过有序排队让大家等待一下。 不过我们也在不断完善等待环节的用户体验，尽量缩短等待时间。
　　另外需要说明的是，12306网站仅仅是铁路售票渠道之一，我们还需要通过“排队”这种手段，来协调网络渠道与其它售票渠道之间的平衡，以维护公平售票的原则。
　　二问　怎么才斗得过刷票与黄牛？
　　针对高频访问、恶意囤票等行为，针对性采取封堵措施
　　记者：为了维护购票公平，12306今年针对刷票软件推出了动态验证码，虽然打击了“黄牛”，也伤害了用户体验，最后不得不改成了静态码。与刷票软件的斗智斗勇好像很不顺利？
　　朱建生：刷票软件破坏了购票规则，是有违社会诚信的行为。我们推出动态验证码，就是为了遏制这种行为，但这也影响了用户体验。
　　后来经过改进，我们推出了静态码，既提高刷票软件的自动识别难度，也提高了用户辨识度。
　 　只要存在利益空间，网络“黄牛”就会千方百计来攻击12306网站，这极大地危害了正常的购票秩序和网站运行安全。就像家家有把锁，用斧头就可以破门而 入，可是守法的人都不会这么干。因此，如何约束刷票软件恐怕不是12306网站一家的事儿，这涉及互联网行业自律、网站监管等一系列问题。
　　值得提示旅客的是，去年底上线的新版12306网站已经新增了“刷票”功能，方便旅客购票。
　　记者：自从有了网络购票渠道，炒票的“黄牛”也开始升级换代，不少“黄牛”成了网络高手。在打击“黄牛”炒票行为上，我们有什么行动？
　　朱建生：网络“黄牛”恶意囤票倒票，严重损害了广大旅客的切身利益，也影响了网络运行安全。我们也在不断摸索防范、封堵网络“黄牛”的技术措施。
　　比如，不少“黄牛”利用45分钟的支付期恶意囤票，取消假身份证预订后，再通过真身份证抢刷返票。所以我们现在将取消预订的车票随机延时返回票库，这并不影响普通旅客正常购票，但大大降低了黄牛抢购返票的几率。
　　针对高频访问网站、高频访问余票查询网页、利用45分钟支付期恶意囤票等行为，12306网站仍将继续采取针对性的防范和封堵措施，以维护正常的购票秩序和网站运行安全。
　　三问　能不能向淘宝等网站取经？
　　以学习姿态、开放模式建设网站，欢迎旅客出谋划策
　　记者：很多旅客不明白淘宝“双11”那么大点击量、成交量，用户体验都挺好的，为什么一到春运，12306却总是“卡壳”。网络购火车票和淘宝购物有什么不同？我们不能去取取经吗？
　　朱建生：淘宝是很优秀的网站，也是我们学习的榜样。不过，网售火车票与淘宝这种综合购物确实有很大不同。举个简单的例子，在淘宝出售一件商品，同样的库存只需减数量就可以了。但是车票不一样，它具有不可替代性。
　 　前一段网上有个帖子，例子举得挺对。北京西到深圳北的高铁，它有17个站，3种座位。表面看起来，就是3个产品，即商务座、一等座、二等座。但实际上， 它有408种商品，因为旅客的上车站和下车站都可以是不同的选择，每一张票都是一个相对独立的商品，而且这种产品是动态的。如果售出了一张北京到武汉的二 等座，客票核心系统会立即自动生成一张武汉到深圳北之间的同席位二等座，同时取消北京至石家庄直至武汉之间车站的车票，此外，还需将这些车票数量的变化实 时同步到网站上。因此售票系统是在不停地计算生成新的“商品”。
　　互联网技术是开放的技术，我们也一直以学习的姿态、开放的模式在建设网 站。从12306网站建设之初至今，就邀请了很多互联网技术专家出谋划策。2012年、2013年的“双11”期间，我们特地组团参观了阿里巴巴的运营维 护工作，学习人家的成熟经验。此外，我们也和银联、中航信等企业进行了多次的交流学习。
　　在互联网售票领域，我们还是新兵，今后还将继续以开放的态度建设和运营网站。
　　记者：其实，从去年12月改版以来，12306网站的不少新功能受到了旅客肯定，也出现了不少针对动态验证码之类的“吐槽”，您怎么看待这些“吐槽”？未来12306网站还会有哪些改进？
　　朱建生：我们一直都特别关注用户体验，12306网站上有个用户反馈信箱，我们每天都会收集大家的意见和建议，再由研发团队根据这些意见进行技术改进。
　　去年12月改版的新网站，就是听取了旅客的意见，进一步优化了操作流程，把冗余的流程省略，使旅客能最快地买到车票。
　　新网站推出后，收到了不少用户意见反馈。有一名旅客提出“优先车次”选项不能录入未开售的车次，我们立即就改进了。还有其他意见，我们也都加以改进。我们非常欢迎旅客继续给我们出谋划策，共同把12306网站办得更好。
　　在这里，也告诉旅客一个好消息，现在12306网站也有公众微信账号了，叫“铁路12306”，为大家提供了不少方便、实用的服务信息，更加方便大家的出行。
 

 文章来源: http://goo.gl/BozLzz

别给 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」，我的一位好友就是这么中招的，很早他就说几十台服务器如果设计好的话，应该就够了，这是他那篇文章的核心观点。结果被无数马后炮指出各种细 节缺陷，问题是，能没缺陷吗? 不少做技术的人，脑子真是秀逗了。

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

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

---

文章来源: http://goo.gl/R0DJvN

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

如果 12306 项目外包给阿里巴巴或 IBM 等大企业，会不会更好？
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包给知名大企业是否会更好？答案是，无论谁来做，最终结果都是一样。

匿名用户

胡锦涛、知乎用户、杜屠苏 等人赞同

现有的部分讨论，双方缺少对基本事实的共识。

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

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

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

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

2012年1月16日 陈皓

http://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通常伴随着分布式 存储）。（关于负载均衡更为详细的说明见“后端的负载均衡”）

二、减少前端链接数我看了一下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）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。

更新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




文章来源:  http://goo.gl/47rpZY

身为码农，为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的动态库存很复杂。
先说秒杀。
2013年12月25日前后，天猫搞了一个圣诞季积分兑换活动，持续几天。25号上午10点12分，放出了15000个天猫魔盒（淘宝集市有人卖，大概190-230块），从成交记录上看，是19秒内全部抢完。
实际上，我也参加秒杀了，那天的题目特别简单（请输入xxx汉字的拼音首字母），我应该是5秒内答题完成并提交订单，结果告诉我排队的人太多，挤不 进去，并提示14秒以后重试。人太多就是因为题目太简单了，门槛越低，5秒内挤进去的人也越多嘛，如果题目换成【2克浓度为3%的U235在大亚湾核电站 能发多少度电】，5分钟之内也不会有1万5千人跟我竞争。
我想，14秒以后哪还有我的事情呀，于是重新答题秒杀，结果出现了服务器错误的页面。反复刷新几次，就告诉秒杀结束了。
在群里问了一下同事，有不到10个人回答我，都说没秒到（也可能秒到的人闷声发大财，不回复我）。
淘宝是什么技术水平呢，淘宝有至少4000技术人员，至少4万台服务器（这都是两年前的公开数据了，按规定可以谈论），2013年11月11日成交额351亿，2012年全年成交额超过1万亿。
淘宝拥有各种自主研发团队：服务器、交换机（网上可以搜索到淘宝公开的绿色服务器开放标准）；操作系统（Linux Kernel taobao版，yunos手机操作系统是阿里云的，暂时不计入）、Web服务器（Tengine）、Java语言虚拟机（JVM taobao版）、数据库（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秒杀iPhone 5S就不一定，有人可能网银有问题，有人可能改变主意不想要了），所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们，会认为还有机会，继续在 前台刷一会儿，最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。
（超卖这一部分科普笔法写得有错误，鉴于12306目前全在内存数据库中读写，没有产生超卖问题，先把这个段落删去。感谢@吹西门的雪 指正）
好了，讲了这半天淘宝，可以说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网站的时候，铁道部就有这种人工预分配的策略了。
想象一下，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在大亚湾核电站能发多少度电】。
以上讨论只是把12306当成和淘宝一样没有历史包袱从零起步的交易系统，实际上，它不是，它后面的票池，还有电话售票、火车站售票、代售点售票等多个传统渠道要服务。除了客运服务，12306还有全国最大（很可能也是全球最大）的大宗物资货运系统。
架空政策（包括定价政策、警方打击黄牛政策、身份验证政策）谈技术，是不可能解决春运抢票困局的，要想让春运的时候每个人在12306抢票都毫无拥 挤感（但不一定能抢到票，铁路运力摆在那），那就是逼着12306买一大堆服务器对付春运，春运过去后，成为跟amazon一样牛逼的云计算服务商。和逼 北京修一条10车道的高速公路去八达岭长城一个道理。
目前的12306技术上是还有问题，比如，抢票高峰，输入个身份证号和图片验证码都卡得要死（本人亲测），服务器端繁忙，你浏览器端卡什么呀。
但人家在进步。相信2014年春运的时候，技术已经不再是一票难求的主要问题。在铁路运力不可能神速增加（孙中山先生计划的20万公里铁路，土共修了快70年，才修到10万公里）的情况下，要做到春运更公平地买票，需要停靠政策调整。
下文针对的是春节国庆这种非常暑期。其它时期，大部分线路保持现状就行了，问题不大，极少部分票源紧张的线路可以按春运处理：
1. 拍卖法，价高者得之
当硬座票拍出飞机票价格的时候，相信票就不难买了（可惜就是贵了），也没有那么多黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的，淘宝的拍卖系统可以帮忙，浙江省高院在淘宝拍卖一年多，成交26亿。
可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了，何况是拍卖。再说，火车票毕竟是生存之刚需，票价20年来不涨本来就有照顾补贴的成分在里面，全拍卖可能也是不妥当。
2. 抽签法，运气好者得之
开车前2个月开放报名，开车前7天抽签，中途可取消。预存票款，抽不中退款。上传身份证和正脸自拍照，机器核对。
这样的话，拦截黄牛的成功率就高很多了，黄牛可以预存票款，可以找到大量真实身份证号，你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给 你试试？即使有人真想找黄牛，给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多，黄牛成本提高，还不一定搞得到票。反正都是碰运气，我想真正的消 费者还是会选择自己先去碰运气吧。
这个方法实施难度也大，无论怎么设计抽签规则，必然有人大叫“有黑幕，不要相信政府”。
开车前7天出抽签结果，改变行程的人应该在7天前就能决定改还是不改了。没抽到的也还有时间想别的办法。当然不一定是7天，15天，10天也可以，具体几天要有数据模型来算。
3. 拍卖 + 抽签
软卧、高铁商务座等高价位的，拍卖，反正买这个的是经济能力相对较强的。那就拼谁经济能力更强吧。
硬座、站票抽签。
4. 凭身份证进站，车票跟发票一样，是报销凭证，不是进站凭证；退票后钱进入12306账户，不可提现，只可该乘客下次乘车用；黄金周期间，个人账号最多订购10张票
这个办法可以打击黄牛囤票再转卖
运行一段时间后，按账户余额弄个排行榜就知道谁是黄牛了
可惜这个需要车站设备改造配合。
—–更新—–
收到有同行质疑136个库存的合理性，他提出的方案是：
北京西（01号站）到深圳北（17号站）一共设置16个商品（SKU）：
SKU01：01号站 到 02号站
SKU02：02号站 到 03号站
…
SKU16：16号站 到 17号站
如果出一张01号站到17号站的票，就把SKU01/SKU02….SKU16这16个SKU的库存都减一。
这种做法是可以运行的。我原来参与设计的一个ERP系统就是这样的做的。
16个商品方案的优点是商品数会比较少，缺点在于查询性能较低，要查询16次才能知道【北京西到深圳北】还有没有余票。而136个商品的设计，穷举了所有出发和到达站点的组合，出票前只需要查询1次库存就知道还有没有余票。
大部分面向公众的网站，其业务特点都是读多写少。电商系统的库存查询次数更是远远多于库存修改次数的。在秒杀系统中，可能会出现99%的请求查库存 1%请求改库存的情况。 像12306春运抢票这种场景，在秒杀工具（抢票软件）的推波助澜下，查询1万次库存才成功出一张票也不是没有可能。
还有人说，KFC的食品可以单卖，也可以套餐，为什么没像我一样搞出这么多SKU，那是因为，KFC门店的人肉查询频率非常低，没有必要为了优化查询性能把库存结构设计成那样。

文章来源:  http://goo.gl/JmdXB5