主题：【讨论】回应对12306.cn网站的技术质疑 -- 忘情

先收钱，再订票，再退钱，就是很多钱要在银行和铁道部之间走来走去，银行肯定要多收钱的，铁道部干不干是个问题？旅客干不干也是个问题？

另外春节不好说，十一好多公司都是走高铁的，这是肯定的。

而且十一主要客流就是旅游的。

但是没有实际数据 没法说。

高峰时期IT压力，应该是可以分流的，查询和下单负载要分开，不同车次的负载也可以分开呀。

我看过淘宝的IT人员写的负载均衡的数据库的设计 还有网通的，我觉得应该是有这种技术的，只不过铁路的人员没有找到正确的方法。

我去年12月份用的12306买票，感觉操作不像taobao那样顺畅，怎么说呢，感觉不像一个成熟的软件公司写的东西，的确，taobao是分散的店家，但是他们不是分散的数据库，所有的买卖，减少库存也是对杭州的服务器读写的，不是在各个卖家的数据库读写的。我记得比较清楚是他们的it设计是每个大城市群是有前置服务器担任镜像的任务

等铁路说成交了，再网银汇款。只提交了意向，没成交当然不要交钱，也不涉及退费

高铁当前供求还算平衡吧，走网上订啥方法都该行的，不行还可以走旅行社嘛

这次改版，在流程设计和用户体验上做得太差。

比如，增加了一个“预约”功能，结果点进去一看：“预约时间已过，预约时间为2012年09月10日，11:00至20:00。”话说现在都24号了，这个功能若是不能用，为什么不删掉或者置灰？

购票时，下了订单，被告知需要等待的时间大于30分钟。这个信息除了引发不满，没有给我任何有益的帮助。我需要不停地刷，或者隔半个小时登录一次。

12306.cn的技术方面，也许存在很多问题。不过对于一年只有两次（国庆、春节）的大流量，是否需要花很多钱从技术上去解决这个问题？我个人觉得可以采用更好的策略而不是简单的下订单后排队这种方法。比如，ETS的Toefl报名，也是瞬间高峰，它的网站采用的方法就是限定每个ip在指定时间内的点击次数，如果超出，就封ip。

从我个人的体验来说，不能进入系统的感觉比下了订单后不知何时支付要好得多。

对没有超大规模数据处理经验的公司来说，即使软件水平很高，12306网站做起来也是非常困难的。有人说这个东西很容易做，纯粹胡说八道。

但对具有超大规模数据处理经验的公司来说，就没多大难度。

这篇文章，等于随便拉个大夫来，说病人没救了，治不好没有责任。

其实是蒙古大夫。

这篇文章作为宣传，忽悠人是可以的（简直太好了，所以被选中）。

但是就解决问题上，完全不着边际。

连忘情都知道，问题就在“升级后用户购票可能会被强制排队，由于系统存在多处漏洞，排队后购买失败的概率很大。”

这篇文章没有一处是具体针对解决这个瓶颈问题的。倒是把大半篇幅，用来解说对并不存在问题的地方。

因为这个网站的业务的原因，所有的操作都是对那么很少量的数据的大量处理从而导致的问题。无论用云计算还是增加更多的服务器，如果不解决这个核心问题，都是白搭。解决数据处理过于集中，我能想到最简单的办法是两条措施，大家看看有没有什么启发：

1、分散数据。

把票务数据按照不同车次、不同时间，分散到不同的表、数据库或服务器中。比如，可以按照某种规则，一张表里只保存几个（比如，5个，具体数值就需要统计以往记录进行分析）车次的几天（比如，2天，那么，预售期10天，就会分散到5个表里。当然，具体几天，还是需要分析以往数据的）的车票数据。这样的话，在数据操作时，影响到的范围将大幅度减小，这将大幅度提高并发度。

2、二级数据管理

可以把数据分布在2个级别上管理，一个级别记录完整数据，在第二级上按某种机制记录部分数据，第二级可以由很多个服务器组成，也就是，1：n的情况。而Web服务器只访问二级数据库，并不访问一级数据库，二级数据库访问一级数据库。

比如，某次车的某天的数据，这个车次的所有票务情况完整保存在第一级数据库中，每个二级数据库需要从一级数据库申请自己可以分销的票的数量，二级数据库的票销售完毕之后，把销售结果同步到一级数据库，并再次申请自己分销的票的数量。这样的话，一级数据库的访问次数将大幅度减少，而同时也保证了数据的一致性，不会出现把票卖超了的情况。

比如十天后，八点多的票今天八点开放，九点多的票今天九点开放，每小时放一批，这样如果你本来想买的是下午的票，不需要早上就去抢票。至少并发访问量只有现在的十分之一。只需改下规则，压力明显下降。

首先是查询，查询可以用平行分流，路线是固定的，不需要和中央系统实时对话, 等待时间和余票百分比代替具体票数.用户要求知道某时某地出发到某地有几种选择，各种路线耗时，价钱，预估购票成功机会。看到要等1个小时去争1%余票的人估计不会太多. 用排队红绿色小人的图形显示也行. 这里就是个影响用户反馈的节点。用户有个各种选择路线的心理排位，你可以通过查询信息排位来影响用户的心理排位。比如航空公司经常把较冷门日期的航班价格降低下来对冲热门时间。同样查询结果中有的路线可以实时定票，有的需要等待可以起一部分的分流平流的作用。当然有的用户可能为此刷屏，像摇老虎机那样希望刷出热门路线的实时定票，这种可以用专门的技术手段处理。

现在我们处理选择等待的用户, 大多数人都没有网上排队的心理准备.自然反应一个是刷屏,一个是同时开另个网页骂体制. 其实这个时间完全可以用来理顺个人信息,支付渠道. 先交10元的排队费, 确定买票后票价中扣除,放弃不退.再让用户有多个选择,按心理排位同时选几个路线一起排队, 再选择及时通知工具,用户自己选短信, 自动回电...专门给个定购号,定购号指向专门临时网页用来给人刷屏用.刷屏网页不联中央系统除了确定的用户个人信息外,最多一张人机分辨图, 让用户给自己发信息的安慰键.一个定购号有效时间倒计时,选择路线一键购票的红绿按钮. 为了防止一个用户占几个队却只守着热门票, 一个定购号只及时通知第一条路线支付等候. 超时不用,自动购票键自动从绿变红, 及时通知支付等候超时无反应失败.第一次最少再等10分钟, 第二次30分钟, 第三次等于从头排起.

防黄牛不应该是系统的主要责任. 云计算当系统压力测试. 模拟每秒百万级别的查询,刷屏,信息输入和定购号DDos.

我不是干这行的，所以这个问题可能太外行了。有没有可能人工模拟系统的巨大压力，至少可以先内部自己试试行不行再上线啊。做工程的人都知道，模型是很重要的，模型如果都通不过，真正的实验更别提了。我小时候家门口有个水利部门的实验室，里面都是按比例缩小的码头、水电站之类的模型，还有模拟的河流、海滩，然后模拟各种自然现象下那些模型会不会出问题。

回到网站这个问题，其实大名鼎鼎的惠普照样搞不定。他们自己甩卖touchpad的时候，自己网站的购物系统照样崩溃，不过你要是买别的东西还行。

支付宝没有对用户收费。铁路对银行的力度，不应该比支付宝差。

12306网站支持余额功能可以免费充值转账，预购单按最高成交金额比对余额。余额不足提示，并禁止提交，提交后锁定余额中对应金额。

有空多交流。

首先可以采用“不远攸高”的所有订单一视同仁的方式，从所有订单中一张张地抽取订单，直到无票。这种情况比较大的问题是，如果最后一张订单是多票订单，即使最后被选上也无法拿到足够多的票。对于这个问题，最简单的办法是从预留给窗口的车票中取得足额票补足。

一张张随机抽取订单如果太慢，可以批量抽取，然后交给多台主机分别撮合成交。最后的问题仍然是，可能最后被选取的订单票额不足。改进的做法是可以采取批量逐渐递减的做法，防止最后选择的订单由于无票导致被选却无法订票成功的情况。

其次可以采用原有的达到某一订票数量，进入团体票的排队抽签机制。就是把订单按照普通订单和团体票分成两个组，分别赋予不同的权重。其实现在计算机的能力，完全可以按订票数对订单分类，然后给每个类赋予一个经过测算的权重来保持公平。

1.防止有人利用设计漏洞同时对一个车次多次提交订单，以增加中签概率。

可以对每天的每个车次都建立一个已申购身份证数据库，新增订单中某个身份证号已在其中，则订单无法提交成功，当然页面要提示这种错误原因所在。

这种查询量很少，应该没有系统不能负担。

2.订单中如果只允许单一车次，如果无法订购成功影响其订购其它车次的问题，或者填很多订单导致的繁琐。

可以采用搜索得到符合要求的全部某日或者某几日始发终到的相关车次，剔除其中不适合自己的，并给剩余的车次赋予优先级，输入数量和对应身份证，形成订单。

3.考虑铁路内部联运的问题，

订单可以分行程，前后行程之间可以建立关联关系：比如后面行程票能够订到，前面的订票才予以考虑。

4.最大的问题是，如果这种预售机制已经结束，剩余票是否只在窗口销售，不允许再在网上销售的问题。如果允许，弄不好还会存在当前的困境。

我认为允许也只能还是固定拿出票来，按天或者分时段抽签出票。这才能解决前面的困境。

5.对于非假日时段或者非紧张的票源，可以建立正常购票与假日购票(申购中签模式)的触发机制。一旦票源紧张立刻进入抽签购票模式。这种机制可以是人为设定的期限，也可以是某日某次票快速售罄作为标准。