主题：谈谈大型网站架构的一些关键技术 -- 季侯

12306首页都打不开，其实就一个原因就是页面太花俏了。要是我设计，就像谷歌一样，首页只有两个输入框——出发地和目的地。

另外，推特42000流量绝对要小于12306的负荷。公开报道是最高单日10亿，平均下来也要每秒1万多。但是实际上显然是非常不平均的，峰值至少是平均值的10倍，也就是推特的2倍多。

你的思路理主要是分数据，来减轻服务器的负荷，但是我觉得最好还是分人。

下面说说我的想法：

指导思想就是购票流程上的每一步，都把订票人分散成几组前往不同的下一步。换句话说，最好的学习榜样是谷歌。

第一步，首页，只有输入始发站和终点站的两个。输入了以后，根据始发站的不同，把订票人分流给若干下级设备分别处理。我觉得比较合理的分法是按铁路局来分，一分18，十亿就分成了18个6千万。这一步只需要查询始发站属于哪个路局，就一个查询，数据库压力很小。这一步如果害怕ddos攻击，可以加验证码。

第二步，根据上级设备送来的目的地信息，结合已知的运行图，给出若干个乘车方案。方案排序按照直达优先，尽量少换车来排序。一次给出5个方案也就足够了。这5个方案的形成是根据铁路运行图来设计的，所以不是随时变化的，而是基本固定的，只有新增临客才有变动。所以这些个方案很多都可以预先生成。算下来，压力也不大。这样6千万就分成5个一千二百万了。

第三步，输入乘车时间段。这个时段应该是如干日的一个比较大的范围，这个范围最大是从订票时一直到当前可售的最晚的车票（15日后？）选好了这个时间范围，再根据选定的乘车方案，分到下级系统处理。

第四步，输入要定的票数，（1-5张？），然后登记身份证号，付费。其中默认第一个输入的身份证号是用户账号，用户自设密码，以及联系方式等。

第五步，付费完成后，生成订单。到这里网站的任务就完成了，生成了订单之后就和电话订票，窗口订票一样进入铁路内部的订票系统了。从今年的情况看，这个核心系统还是顶得住的。

第六步，订票如果成功，则记录这个账户，保存相关数据，如果订票不成功，全款退回，重头再来，删除账户。

第七步，深夜，全网核查数据库，有同身份证下大量定票的，全删，退款。有身份证号在公安部通缉名单上的，赶紧通知。有已知是记者，官员，黑社会，军人的，打个折。

这么设计的目的，首先通过层层分流，避免出现瓶颈，其次把票务数据查询往后推，只对交易成功的客户提供查询，减少主系统的负荷。

最后，我觉得单日10亿太夸张了，很可能确实有ddos攻击在里面捣乱。