主题：【原创】关于12306“排队”系统引发的争议 -- 忘情

这件事情其实就是铁道部自己愚蠢，只知道做事，不知道做秀。做事和做秀其实不矛盾，甚至是相互帮助的，而且越现代的社会，做秀就越重要。

这个问题其实是铁路的老问题，因为铁路系统独立性很强，一般不与其它部门做太多的互动，特别是媒体，比如前面被撤职那个铁道部发言人，他是诚实的近乎天真，他说话的方式是对一个单位内部人员讲话的那种方式，他把铁道部的人思想表达的很清楚：我出于好心，做了实事，现在确实出了事情，我会改正，继续前进。这种态度在和其它外人打交道时是极度愚蠢和危险的。下场如何，大家都看到了。

另外，在网上订票这件事情最大的问题其实就是铁道部低估了他的困难程度，这是一个决策级的失误，技术上改进这种战术动作很难纠正过来。

我提几个可能是胡说的建议：

1。分割购票系统，把热线和冷线，或者各个开往各个大方向的购票系统在物理上分开，比如单独给动车设置服务器，这样可以保证整个大系统不会完全崩溃（现在情况表明全部彻底解决困难很大），另外可以设定一个什么各方向购票热度指标什么的，比如每秒点击数什么的，给大家一个预期，这样可以很自然的找到辩解的借口，这样由于大家在体验上有分歧，舆论上体验会有分歧，媒体大有发挥的空间，但是不会整个否定系统了。

2。把热线订票由即时系统变成订单系统，订单系统可以做的稍为复杂一点，比如如果某个车次没了，自动尝试下一个车次什么的，如果没有下铺上铺也可等等，以及是否等待可能的退票，总之设定一个优先等级。其他动作全部后台处理，进程以及结果邮件回复。顺便再给个当前订单排队号以及最后一个买到该车次的排队号以示公平。然后写个攻略之内，介绍各种订单排序方式的优劣。这样结合每个账单的订单数量，可以限制大量的外部持续连接访问。

而且Google的复杂度比12306低很多吧。客票是需要1对1的，要避免1票多卖，Google只需要返回查询数据即可。

我最近的操作使用来看，查余票的操作一点也不快。

需要怎样的预算来解决国庆、春运客票预订高峰？

告诉你，Google不仅访问量比12306大得多；复杂度和难度,更比12306高太多了。即使是我国处理大规模数据最高水平的百度，也差google很多。google的本事，主要的一点，它对数据分布处理的能力特别强。而12306对大规模数据的分布处理，根本就没经验。

查余票的操作是不快，毕竟可以接受。

但是出票排队出的问题就很荒唐。其实1天出票不到1千万张，数据量是相当小的。

这个问题对有相关经验的真正专家（很少）并不难解决，但对12306的开发者以及辩护的专家，难如上青天。

解决方案大体我已经说了几次了，但忘情是搞宣传的，没有影响力。等于是废话。细节也就懒得说了。

整个系统其实就几个部分：

1、余票查询。

2、数据录入。

3、座位锁定。

4、支付出票。

唯一的难度就是一个高并发的查询操作，但是以铁道部的报价，完全可以烧硬件上大型服务器，然后在搜索策略上想想办法就能解决。

我自己是做网游的，说句实话，这个系统难度比开心农场还要低得多。就拿哪一个选座功能来说，铁道部说是不同的车型座位编号不一样，所以不支持。这种上不得台面的理由，无非搞一个配置表查一下就能解决了。车次-车箱车型-座位规则。这台车上需要显示的是1234，那台车是abcd，完全是个显示问题，如果用我熟悉的语言写，这个就是代码上不超过半天的事情，结果现在搞成非得统一所有座位编码才能选。

就即使是不能自主选票，这个座位也要安排得稍微靠点谱，我同时买两张票，不能一张给我安排到车头，一张安排到车尾吧？我不止一次买到这样的票，但是肯定不是最后的两张，因为你刷新重买，也许就分到一块了。这个把同时买票的人分到一个地方有什么难度吗？我看没有，无非就是循环遍历一下空座的事情，找个稍微用心点的毕业生都能写好吧。

我不知道是不是所有铁道部的人都不懂技术还是另有什么奇怪的内幕。我也根本不介意铁道部这个网站花了多少钱，但是总不能花了这个天价，最后做出一个最后象是一个外包了5，6次，最后落在一个完全没有经验的学生手里的产品吧。

至于复杂度，我觉得得有针对性的讨论。从搜索引擎上，Google应该是牛中的大牛了，但是12306面对的应该是电商节假日促销的问题，而且每一张车票都要设计“锁”，复杂度是非常高了，觉得无论淘宝还是京东应该和国庆、春运铁路网上售票无法比拟。

这几天大家应该感觉12306访问比前几天快多了，应该是买到火车票或者买不到火车票的基本都确定了自己的出行方式，从网上订票的人少了。按照十一、春运这种峰值去设计服务器集群，不知投资收益比是否合适。