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

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

以下是草稿，写于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/