[知乎]12306 系统在 2015 年春运高峰期的稳定运行，采用了哪些具体技术？

http://www.zhihu.com/question/27321479/answer/37292320#rd

不邀自来，果断匿名。

利益声明：阿里云程序员，今年12306春运项目幕后码农。

仅代表个人，尝试从技术的角度对12306做一些抽象的归纳，包括12306与云计算的技术相容性，对项目谈一些感受。不涉及具体数字和系统架构细节，对铁路业务运营不做评论。

先亮明基本观点，不喜请绕路：

1、从技术上看，不是说做好了阿里双11就能做好12306

2、12306的亮相是惨了点，但这两年一直在改进

3、12306一直在尝试引入外部技术力量解决问题，租用公有云算其一吧

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

我初次使用12306是到北京旅游，返程票是在12306预定的。当时是拿到一个订票号码之后再去西直门付款取票。客观来说，这两三年12306的便捷程度已经有很大提升。

每年春运，12306都会被推到风口浪尖上，也不断有“高人”放出豪言壮语，可以非常迅速而廉价的开发一个新的 12306出来。我记得大约4年前招聘工程师的时候，也经常遇到有人断言可以3个月内开发一个完整的淘宝系统。对于这种口炮党，我只能说：呵呵。。。

铁路运营是一个庞大的社会工程，每年春运，相当于把全国人口“搓一圈麻将”，如果在这个节点去网点排队买票，相信绝对是一件让所有人头疼的事情，这不仅是用户体验差的问题，同时也是对社会资源的巨大消耗。

收一下，回到技术层面——

在互联网售票之前，网点售票已经实施多年。换句话说，铁路售票实际上一直有一个相当庞大且复杂的、跨多个路局的信息系统在支撑，而且可以追溯到80或90年代，维护至今。这个系统也许不仅支持了售票，可能还包括调度等核心业务。那这里就有一个问题：在做互联网售票的时候，是否要重构一下原有的系统呢？

这个问题值得反复掂量。大家应该知道，彻底重构一个运行数十年的系统的开销和风险吧，粗略一想涉及到各种业务逻辑、软硬件供应商、版本与维护协议等等。

绝大多数的互联网技术同僚应该会倾向于在现有系统上做web前端，先让系统“用起来”，然后再集中技术力量逐步优化整套系统架构。这也是当时12306的选择，这就导致有很多历史的包袱，还要考虑线下售票系统。

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

知乎上很多人拿春运售票和我厂双11比较，究竟哪个牛逼？

个人感觉两者同属于重量级的网站业务，双11在业务规模上更有挑战，而12306则在业务复杂度上更高。

火车票跟很多票（包括淘宝天猫的商品、机票、体育场馆门票等）有不一样的属性。比如，从北京到广州，沿途有多个站点，理论上乘客可以选择任意 一段区间购票，所以每买一张区间票，可能同时裂变出多张区间票。这个逻辑比大多数电子商务系统要复杂的多。关于这一点，这里有一个更夸张的分析，有兴趣请参看：

从嗤之以鼻到“奇迹” 前淘宝工程师详解12306技术。

购票差异还不仅限与此。假如说要再添加一些更人性化的feature，比如根据订票者身份证里的年龄优选上下铺、优选号等，那么查询和出票逻辑就更复杂了。

在一个后端上，setup一个web前端（包括入口、安全、缓存和逻辑，非指web页），这个挑战也是巨大的。因为这个前端很容易瞬间胀大， 甚至被撑爆。“撑爆”的概念不难理解，奥运会的订票高峰，中美海底光缆拥塞，包括杰克逊去世后瞬Google瘫痪，或者DDoS拒绝服务攻击，都是这种现象。

根据官方公布的数字，有人统计了一下：需要数千个pv，才能出一张票。这个说法并不能得出“出票效率低”的结论，但是恰恰很形象的说明了查询量的巨大。

为什么12306查询量会这么大呢？因为淘宝的秒杀抢不到就算了，运气不好下次再来过；火车票的购票心理则不同，“求之不得，梦寐思服”，特别是高峰期的票。而买到票的人也不一定满意现在的车次、时间。总之，就是一个字：刷！刷！刷！

当然各种抢票工具的泛滥，也是让查询量猛增的原因之一。不过，从另一个角度看，能让这些工具都被用户用起来，这也证明了系统处理能力的大幅提升。

===洗====地===结====束=====

上面说了，天量的火车票查询是影响12306性能的重要原因之一，大概占了90%以上的访问流量。更棘手的是：峰谷的查询有天壤之别，几乎没有办法在成本和并发能力之间做一个好的平衡。以往的一个做法是从几个关键入口流量控制，保障系统可用性，但是会影响用户体验。

淘宝/天猫大促的时候，也会增加服务器，阿里的业务盘子大，这些新增的机器很快会被其他业务（包括阿里云）消化掉，可能还不够。但是对于 12306来说，就比较难做到这一点。

这成为今年12306与阿里云合作的一个契机：通过云的弹性和“按量付费”的计量方式，来支持巨量的查询业务，把架构中比较“重”（高消耗、低周转）的部分 放在云上。这是一个充分利用云计算弹性的绝好实例，也是在系统架构上做“轻重分离”的一个典型case，把小而精的核心业务系统保持不动，把 “傻大笨粗”（非贬义）的系统迁移到云计算上。

今年初我们和12306的技术团队开始讨论如何将余票查询系统放到云上，十一黄金周做了测试效果不错，到春运12306决定将75%的余票查询业务放到云上。

同意@xLight 的说法，云计算不是万能的，12306的业务系统很复杂。目前我们能看到的是，在提升余票查询能力方面，云计算可以快速部署应用提供服务，通过分钟级的扩容操作，实现十倍、百倍的服务能力扩展。

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

做这个项目一晃有小半年了，感触很多。大家知道双11对阿里技术团队是一个不小的挑战，我参加了4年，其中有两年过的尤为艰苦。当时技术团队经常被业务方指责，就像现在大家对待12306的态度一样。但客观说，双11大促推动了阿里的技术成熟，春运也推动了12306采用更多面向未来的技术。

最后引述一段12306工程师回顾系统刚上线时说的话：

12306是个互联网新人，又或者被称为“富二代“，它长得很丑，也很傻很瓜，身体还很弱…所以第一次露脸它就演砸了，那天全中国互联网大佬和网民都盯着它看，基本上全中国的网友都涌入它的家。那天它宕机了，同样是那天骂声如潮……其实我们知道，他们骂的不是12306，他们骂的是这个时代。

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

回答几个问题：

l为什么是余票查询？

1. 访问量巨大，占12306整个网站流量的90%以上，业务高峰期并发请求密集，性能要求是整个业务系统中最为重要的一环；

2. 与其他业务在逻辑上相对独立，使用云计算的话不需要对整个网站的业务架构做改造。

l实施过程可否透露？（隐去部分敏感信息，请理解）：

1. 把余票查询模块和12306现有系统做分离，具备独立部署的能力；

2. 在云上独立部署一套余票查询系统。这样子12306和云上都有了一套余票查询系统，，调度更为灵活；

3. 一些安全措施,吧啦吧啦吧啦……

根据运行情况，云上的余票查询与12306原来的余票查询可以互相补位，根据实时的负载情况，来调配不同的访问比例，充分利用云的弹性。

l云计算跟“堆硬件”有什么区别？

这里主要是"春运 vs 平时"、"业务量 vs 成本"的问题：

1． 传统IT方案，为应对春运的业务压力，需要按照峰值采购大量硬件设备，从规划、建设到投产、服务整个供应链条长成本高，capex和opex上的投入都比较大，很难精确把控，而春运后大量设备会处于空闲状态，利用率低，造成巨大的浪费。

2． 还有至关重要一点是，假如按照传统方案，在实际业务峰值超出了初始评估量时，服务将面临无法完全承载而瘫痪，因为为大规模服务器的采购、交付、部署到应用上线所耗费时间以月计，根本无法在业务量激增时"即插即用"。

3． 云本身就比自己买硬件要便宜，另外所有资源都是“按量计费”，从十一黄金周到春运的过程里，12306在云上做了两次大型扩容，每次扩容的资源交付都是在分钟级就完成。业务高峰结束后，可以释放掉不必要的资源，回收成本。

-------------------------

从嗤之以鼻到“奇迹” 前淘宝工程师详解12306技术

2014-01-14 15:26 佚名 博客 字号：T | T

有关12306技术难度和实现水平的又一篇重磅文章。作者是前淘宝工程师，后来在一家电商公司做技术副总。和大多数人一样，12306刚出来时他也骂，甚至为了证明这事儿很容易做，他发起了一个"替12306设计系统"的开源项目，两年后就有了这篇长文。如果你还觉得自己很牛逼，先超越他的思考吧。

AD：

我曾在淘宝写过一段时间代码，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秒杀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网站的时候，铁道部就有这种人工预分配的策略了。

想象一下，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张票

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

-------------------------

http://www.csdn.net/article/2015-02-10/2823900#rd

12306改造的关键技术– 建立可伸缩扩展的云应用平台

为什么选择Pivotal Gemfire构建12306的云应用平台？

要解决12306春运时高流量高并发的问题，如果单靠硬件升级解决的话，可能需要扩充数十倍的硬件服务器。但在春运以后，又该如何解决服务器过剩的问题呢？

要真正解决“高流量，高并发“的难题是需要从软件和应用系统层面出发，唯有实现“可扩展的应用云平台架构”，灵活和快速热部署的机制，才是真正解决高并发访问的根本。

在经过多次论证和POC测试后， 12306 最后选择Pivotal Gemfire作为系统改造的平台

6. 混合云的应用：

• 使用Gemfire改造后的分布式系统，极易分散部署到不同的数据中心
• 例如，余票查询子系统可以独立于原来的大系统部署到公有云上，同时也可以再将此子系统一分为二，将另一部分服务器部署在私有云的数据中心。即按业务需求随时部署所需要的资源，来解决高并发的难题。

6. 阿里云的余票查询业务托管：

在前一节已经详述，考虑个人资料的敏感度和安全性，12306不会将这些资料放在阿里云，但会将需要耗费巨大资源的余票查询业务放在阿里云提供服务。另外符合此条件的有3大服务器集群，Web服务器集群， 应用服务器缓存集群， 和余票查询/计算集群。

12306混合云成功案例给予最大的启发就是打造一个从下到上都可做弹性扩展的“云应用”系统，企业客户可将关键业务的“子系统”部署在资源丰富的云计算数据中心，“云化”后的子系统可“按需”获取所需要的服务器虚机资源和动态调整网络带宽，利用这些资源解决在高流量和高负载情况下，系统无法快速弹性扩展导致的性能瓶颈。

云化后的子系统部署在多数据中心，需要特别注意下列两点建议 ：

1. 如果将子系统部署在公有云提供服务时，数据隐私的保护和安全性应为首要考虑。
2. 如果规划将子系统部署在多数据中心时，在系统框架上必需考虑上下游子系统之间的数据传输或同步/异步的设计。