主题：【原创】身为码农，为12306说两句公道话 -- 代码狗

我说的是怎么保证买票相对公平一点。

按我的理解，抢票软件是机器人不断发出请求，相当于12306的服务器要承受不知道几百倍还是几千倍的访问量，服务器受到更大的压力了。

抢票软件能抢到票，其实是因为大部分人都还是没有用抢票软件。比如只有一张票，100人抢，每人在一秒钟内都发一次请求，那么每人买到的几率都是1%。但有机器人能在一秒内发出了1000次请求，那抢到票的几率就是91%。

但如果每个人都用了抢票软件，相当于100人在一秒内共发出了10万次请求，每个人抢到票的几率还是1%，但服务器承受了1000倍的压力。

软件是把所有的输入都提前设置好，然后一次或者多次或者定时向服务器发出交易请求。

服务器承受压力的方式可以通过技术手段解决，人工买票的问题和软件碰到的情况是一样的，不过是把时间拉长而已。

也就是说，你们想的是，应该用技术解决的手段却使用给人添麻烦的方法，这就是你们给12306的建议？

你能抢得过黄牛？

那么黄牛就不能使用更厉害的抢票软件？你就能抢的过他们？

不是12306可以解决的，而且12306的技术问题我也不懂。

你所说的其实是使用界面问题。使用界面如果不够人性化，当然12306有改进的空间。但据我所知，12306也可以做到保存信息，多次发出请求，但12306是每5秒申请一次，这就是考虑到了服务器的承受能力。而抢票软件可能是每5微秒申请一次，这就是我所说的问题。为什么无法无限增加服务器的容量，楼主已经说了。而且增加服务器容量不能解决根本问题：根源是没有足够的票。

如果只有1张票而有100个需求，那么无论12306怎么设计，能够买到票的最终也只有1个人。抢票软件无非就是把这一张票抢到了。但是对于12306来说，这张票卖给谁都是卖，把申请频率从5秒改成5微秒，除了增加服务器压力外，并不能帮多一个人买到票。说来说去，你不明白的就是这一点。

这是十分明显的事,那么它应该做到的就是给能买到票的用户好的用户体验.

要公平,相比于大家都不用软件,肯定是大家都用软件更公平.

从技术上来说,在服务器端设置交易频率限制不是件困难的事.

原来买票你必须一直盯着页面,有软件你设置好,哪个对用户更好你还不明白?

你加个验证码?黄牛难道不能破解?

你只需要记住一点,限制越多,寻租空间越大.

比如说有m张票，n个人同时买票，每买一张票数就要减一。这n个买票的人都是独立的，减一这个操作怎么进行呢？当然是把记录锁起来一个个减。一个人买了票之后，票数变为m-1，第二个买票的人就从m-1张票的基础上再减一。不锁的话就乱掉了，不知该从那个基础上减，也没法判断余票（因为不知道同时买票的n是多少）。

需要锁的不止是票数，还有其他东西，这样又会产生“死锁”“活锁”问题，需要一些很耗时间的技术来解决。

以上这些概念，哪怕学过给文科生开的数据库基础的人都了解。您是怎么做到连这都不懂还敢说人家洗地的？就因为它是体制内的项目所以活该被喷？

线下不受影响当然是因为预留车票啊，网上、电话、网点各有配额

加新线路，裁撤线路，调整，提速，这些都怎么办？

让俺这种技术二把刀看得很过瘾！

讨论一下。16种SKU应该是可以的。要照顾到查询的性能，可以把读写数据库分开。每次出票后更新读的数据库（可用消息队列，而且读数据库可以是NoSQL），读数据库里有所有组合和票数。毕竟写数据库造作是瓶颈。

很多经验少的人会估算少工作量，经验是一个很重要的东东

软件其实是很复杂的一个工业门类，没经验的人往往容易高估写代码的良品率

这篇文章本来还有后续，我打了个草稿的，准备回答一些问题，后来因为种种原因没有及时写成文章，现在这股新鲜劲已经过去了，把草稿发出来，有兴趣的河友可以看看。

以下是草稿，写于2014年1月20日。

1. 我的身份问题

只是表明我是做过技术的，是否淘宝离职员工不是关键。这些道理也并不深奥，大部分研发经验丰富的业内人士一看就懂。我的科普目的基本达到了，为了减少麻烦，我不会做任何努力证明我的身份。

2. UI问题

OTN不丑（就是购票界面），12306首页确实丑

3. 串号问题

不一定是自行编写的业务层代码出错。淘宝曾经出过串号问题，是JBoss bug。12306也用的JBoss，且其版本仍存在串号bug的可能。

4. 证书问题

这个确实不妥

5. 到底是不是动态库存

有余票表格可以证明，同时存在动态SKU和人工静态分配。且这个表格是从12306上查询出来的。

6. 和民航的差异

6.1 运力和价格决定了铁路比民航主流，黄牛和正常用户更青睐铁路

6.2 民航大多只有一个经停站，行程规划和库存管理复杂度不如铁路

6.3 民航性价比上来了，一样会挂（如AirAsia亚航开航时放出的特价票，基本是逢特价必挂）

6.4 同一个线路，买机票要跑很多代理网站、航空公司官网才知道哪里是最低价，是不是真没票了（这也是qunar.com发展起来的原因之一）。相比之下，买火车票的要简单很多

7. 分销问题

和机票一样。

预分配的票可以分销，动态库存的部分分销了，也只是分担了前面的压力，库存还是要回到总部。分销商和铁总的通信带宽、技术衔接是个问题

如果预先分票，首先如果预测不准，会造成对票的浪费，其次也是最重要的，黄牛更难解决。

8. 一个车次一台服务器

8.1 技术上讲，1台服务器是单点，down机了这个车次就不能卖了。要保证高可用，起码3台，而铁总有接近5万个车次（数据来源存疑）

8.2 需求上讲，消费者的买票原始需求是城市到城市，不是固定某一个车次。要达到这样的效果，12306的应用还是要把满足这个需求的所有车次库存都查一遍

9. 黄牛到底是怎么工作的

9.1 电视报道的黄牛一分钟一千张票，数字存疑，有黄牛接受采访表示【我也想活在新闻联播里】

9.2 目前的购票流程（不预存票款，无实名检验），黄牛不需要什么后门，仅凭机器自动填写表单和提交表单的速度差，和机器24小时不眠不休，即可拥有对真人的优势。12306在对付黄牛上还有很多可以做的事情，但不能简单地说这里有后门。

9.3 从经济角度，12306和黄牛勾结，收益太小，风险太大。网络售票反而是大大减少了各级售票点和黄牛交易的可能

9.4 技术层面彻底杜绝黄牛很难很难。庞大的肉鸡网络提供足够的IP，人工验证码识别平台，识别一个验证码才2分钱

10. 验证码

10.1 加载慢

复杂的验证码生成比较消耗时间，例如Google采用的那种，生成时消耗的时间，是ems那种的100倍。可以预先生成上百万验证码图片，放在服务器上，消费者请求时，直接把图片发给消费者，而不是实时计算。

10.2 动画验证码

动画验证码刚出来的时候确实能使抢票插件的OCR失效，这是因为抢票公司之前的OCR算法是针对静态图片的。并不是说动画验证码更难识别。

GIF和PNG动画本质上是多帧图片连续播放，抢票插件把每上帧都当成一个静态图片来识别，就可以了。

Flash实现的动画验证码才能对付OCR，但也有可能被人通过swf逆向工程的方式破解

11. 哪些是可以很好地由多台机器分担的

除了库存更新，其它工作（如上面生成验证码和校验验证码的工作）是非常好由多台机器分担的。

库存要应对高频率高并发的查询、更新，又要保证高度的一致性，是12306（含其背后的票务系统）最大的技术瓶颈

12. 消费历史订单放内存

45分钟内的订单可以放内存，以达到最快的查询速度。

45分钟以外的订单，可以放硬盘上的传统数据库。

冷热数据分离。可以更经济地利用内存。

13. 12306比淘宝难度更大，是媒体误读

上一篇文章说的是12306库存比淘宝京东这类电商复杂几十上百倍。但并不是说12306整体技术难度比淘宝复杂。除了库存，还有很多其它衡量的维度，比如淘宝的营销模型比12306复杂几百上千倍。

上一篇文章也说了，淘宝花的时间、人、钱都比12306多10倍，如果淘宝整体复杂度还不如12306，那是不合逻辑的。

12306和淘宝的峰值压力在一个数量级

淘宝和12306都是很牛，就像乔丹和博尔特都是伟大的运动员。

14. 跨天的车次和车次复用

如G824和G821

15.为什么是136个SKU，而不是16个

如果出一张01号站到17号站的票，就把SKU01/SKU02....SKU16这16个SKU的库存都减一。

这种做法是可以运行的。我原来参与设计的一个ERP系统就是这样的做的。

16个商品方案的优点是商品数会比较少，缺点在于查询性能较低，要查询16次才能知道【北京西到深圳北】还有没有余票。而136个商品的设计，穷举了所有出发和到达站点的组合，出票前只需要查询1次库存就知道还有没有余票。

大部分面向公众的网站，其业务特点都是读多写少。电商系统的库存查询次数更是远远多于库存修改次数的。在秒杀系统中，可能会出现99%的请求查库存1%请求改库存的情况。

像12306春运抢票这种场景，在秒杀工具（抢票软件）的推波助澜下，查询1万次库存才成功出一张票也不是没有可能。

还有人说，KFC的食品可以单卖，也可以套餐，为什么没像我一样搞出这么多SKU，那是因为，KFC门店的人肉查询频率非常低，没有必要为了优化查询性能把库存结构设计成那样。KFC网上订餐比门店的查询压力大一点，但只要不是像12306那样全站商品都秒杀，也是不需要为了优化查询性能把库存结构设计成那样的。

16. 为什么不是一个座位号（如4号车厢18D座位）对应一个商品

查询余票时要count，性能差。

因此可以先生成订单，接受支付，支付成功再分配座位号。用异步操作把系统解耦。并发量最大的订单事务上不要把太多非必要的操作（如分配座位、给购票人发邮件短信）牵扯进来。

17. 不能简单地把12306视为原来窗口售票时代票务系统的一个web界面

12306上线，票务系统的每秒读写请求涨了上千倍。因此12306上线时，铁总肯定也花了大量的资源优化原来的票务系统。后台票务系统没有大的改造不足以支撑12306上线

参考资料：

高铁的商务座数量：

1. 京广高铁G80次，380型车，28个:http://news.qq.com/a/20121227/000701.htm#p=5

2. 西安北到深圳北的G824所用的CRH380AL车26个：http://henan.sina.com.cn/news/z/2012-09-24/0712-24627.html

3. 京沪高铁的G129次24个：http://luxury.ce.cn/html/2012/csdc_0628/75379.html

4. 沪杭高铁G7305次28个：http://news.cntv.cn/china/20120520/106624.shtml

（注：以上参考新闻可以看出，这些线路的商务座数量都不超过30个，但如果去12306查询余票，同一线路内，不同路段的商务座余票量加起来很容易超过30，所以后台必定有动态库存机制）

快捷余票查询：http://yupiao.info/