分类： 云计算
2015-02-05 18:23:57
前淘宝工程师：12306没那么简单
今年用12306抢票是不是没有遇到登不进去、系统崩溃？每年春运期间，12306就像个没人爱的孩子，遭遇各种吐槽。年投入那么多还做不好，不如让淘宝来做，淘宝双11秒杀抢购，从来不会崩溃。这曾经是不少人吐槽12306的最强利器。
于是，今年真的淘宝来做了！
12306真的让淘宝来做？
1月15日下午，自称为阿里云程序员，同时参与了今年 12306 春运项目的知乎用户首次披露 ，阿里自从去年年初就已经开始和铁路订票网站 12306 合作，到今年春运，12306 已经将 758的余票查询业务交由阿里云托管。
该程序员表示，2014 年初阿里和 12306 的技术团队开始讨论如何将余票查询系统放到云上，十一黄金周做了测试，并且“效果不错”。目前，阿里云方面尚未证实这一说法。
今年春运期间，网友普遍反映 12306 的抢票和出票的效率比往年大大加快。加上预售期改为 60 天，给了大家足够的缓冲时间，以及一些新的规则制定，使得抢票的密度不如以前那样集中。种种措施多管齐下，让大家觉得今年的回家似乎不再如往年那样让人怨声载道，12306 的表现也得到了大家的肯定。
淘宝如何帮助12306
12306 的确是在举全国之力，并不排斥官方之外的民间力量，这也体现了商业和市场的强大威力。
该程序员还披露说，12306 的用户需求和双 11 期间的服务器需求是不一样的。而且他也破除了人们的迷思，他表示 12306 影响抢票效率和服务器运行的关键因素，并不是购票流程，而是余票查询的环节。其实这也是非常符合逻辑的，我们都是在刷票的过程当中发现刷不到，刷到票的人坐位都会被锁定，接下来的 45 分钟内他们可以随意选择时间付款。所以我们觉得票买不到，并不是票都被人买走了，而是票都被查询到了。
具体来说，让阿里云分担 12306 压力的做法步骤是：
1. 把余票查询模块和 12306 现有系统做分离，具备独立部署的能力；
2. 在云上独立部署一套余票查询系统。这样子 12306 和云上都有了一套余票查询系统，调度更为灵活；
3. 一些安全措施；
4. 根据运行情况，云上的余票查询与 12306 原来的余票查询可以互相补位，根据实时的负载情况，来调配不同的访问比例，充分利用云的弹性。
在完成了查询以后，用户信息和购票过程目前依然在 12306 自己的服务器上完成。对云和已有系统的对接，以及其中可能的安全隐患，阿里云也做了一些安全措施来配合防范。
2014 年 1 月，有一篇来自“前淘宝工程师”的文章为当时遭遇批评的 12306 辩护，通过自己了解的技术瓶颈证明 12306 已经做的足够好了。目前在网上能看到很多类似的，有服务器运维经验的人对 12306 的辩护和称赞。该程序员也引用了这篇文章，并且评论道：
做这个项目一晃有小半年了，感触很多。大家知道双 11 对阿里技术团队是一个不小的挑战，我参加了 4 年，其中有两年过的尤为艰苦。当时技术团队经常被业务方指责，就像现在大家对待 12306 的态度一样。但客观说，双 11 大促推动了阿里的技术成熟，春运也推动了 12306 采用更多面向未来的技术。
前淘宝工程师：12306没那么简单
淘宝秒杀天猫魔盒的时候，只有一个商品（行话叫做sku），它的库存是15000个。有一个人秒杀到了，库存就减1，19秒卖完的，一秒要成功产生789个订单。想象一下，你在广场上卖火车票，一秒钟有8万人举着钱对你喊：卖给我!
而12306呢？
以北京西到深圳北的g71次高铁为例，它有17个站，3种座位。表面看起来，这不就是3个商品吗?g71商务座、g71一等座、g71二等座。大部分轻易喷12306的技术人员就是在这里栽第一个跟头的。
实际上，g71有136H3 =408种商品（408个sku），怎么算来的？请看：
如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳……都是一个个独立的商品，
同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136种票：16+15+14…+2+1=136。每种票都有3种座位，一共是408个商品。
旅客a买了一张北京西（01号站）到保定东（02号站）的，那【北京西到保定东】这个商品的库存就要减一，同时，北京西到石家庄、郑州、武汉、长沙、广州、虎门、深圳等15个站台的商品库存也要减一，也就是说，出一张北京到保定东的票，实际上要减16个商品的库存!
这还不是最复杂的，如果旅客b买了一张北京西（01号站）到深圳北（17号站）的票，除了【北京西到深圳北】这个商品的库存要减一，北京西到保定东、石家庄、郑州、武汉、长沙、广州、虎门等15个站台的商品库存也要减1，保定东到石家庄、郑州、武汉、长沙、广州、虎门、深圳北等15个站台的商品库存要减1……总计要减库存的商品数是16+15+14+…+1=120个。
想象一下，8万人举着钱对你高喊：卖给我。你好不容易在钱堆里找到一只手，拿了他的钱，转身找120个同事，告诉他们减库存，而这120个同事也和你一样被8万人围着；也和你一样，每卖出一个商品要找几十个人减库存……这就是12306动态库存的变态之处。比你平时买东西的任何网站的库存机制都复杂几十上百倍。
网上关于12306好或差的争论非常多，上面这部分也只是一家之言，形象的解释12306的困难之处。程序员们在争论着12306的前端好不好，技术有多大问题。但对更多人来说，我们只是12306的使用者。能够顺利的买到票，在使用网站购票时有一个好的用户体验就够了。现在前者已经实现，12306在进步，未来期待更好的改变。
