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

1.黄牛是有大量资金的，因为他把票转手出去后就能回收，占用资金只有短短不到一个月而已。实名制倒确实为一个很好的预防方式。

2.按你的思路，是可以方便那些较早时间即可提前确定自己行程的人，但对于那些行程确定较晚的人，就直接排除掉了，而由于中国的国情，不可能太早确定行程的人要占绝大多数。你的办法相当于是“只为少数人服务”，估计从政治上不好交差。

3.即使第2条的内容不计。那你总要留一些票用于“预留预订”后的售票，这时，更多的人来抢剩下的这些票，同样未能解决问题（未预订的后来者不知你还有多少票没卖出）。

4.关于支付的问题，你提的预存金额这个办法，我觉得还是有意义，但这就要搞个类似于支付宝的玩意出来。并在买票前，系统先行估算金额后，要求客户超量预存，未用完部分可以在指定地点退现金。但是，搞不好这样一样，麻烦有可能更大。

12306可以像游戏机厅一样有自己的资金账户系统，用户必须先充值，再用账户里的钱买票。用不完的随时退回卡或者支付宝里。这样系统不用等外部的支付系统，支付流程很快就能完成。用户不需要手忙脚乱的抢着45分钟内给钱，也不会出现付了钱不出票。而且这个设计也能防黄牛，起码黄牛要给出大量的资金，还要建立许多账户，不然某个账户有大量资金必然会引起怀疑。

从目前的情况来看，12306做的很仓促，设想也太单纯了。最起码的给支付流程准备专用服务器和带宽都没有。而且它那个放票设计，纯粹鼓励人去疯狂刷票的。很多简单地设计就能避免问题。比如分目的地地区错时放票。

我基本上每天把百度新闻过一遍，也没找到您引用的这些关键数据啊？

意大利铁路网 www.trenitalia.com

说实话 这个网站做的还是不错的 经常出各种打折票（提前2周以上预订） 虽然有时候也出Bug和各种幺蛾子

不过考虑到意大利的人口只有6000万 估计网站压力不会很大 不知道有没有参考价值

俺不太确定，以下几方面到底哪些是最恰当的理解：

* 唯一的机会就是有新创意，等大家伙发现你已经起来了。

* 大家都是从一台普通服务器开始的，流量大了就往上叠加呗！

* 要么就是网站做大了以后为了吓唬竞争对手或自我宣传把这些说得神乎其神。

水涨船高.再大的水淹不死鸭子.你有多大的用户,就有多大的能力.

理论上是如此，但是基本做不到。

现在业界对新创意还是很敏感的，基本是稍有规模就被发现，然后有实例的抄袭者就来了；如果没被发现，那么风投也不会知道你。

的确大家都是从一台服务器开始的，但是如果架构不好的话，就算往上堆机器也没用。因为不同时期不同流量要解决的问题是不一样的。

某个著名b2c网站就是业界的笑话，架构很多年没变了，所以堆了再多的机器性能都没啥提高，稍微搞个活动就崩溃。

技术问题没什么神乎其神的，是真是假，做技术的人还是能辨别出来的。

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

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

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

下面说说我的想法：

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

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

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

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

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

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

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

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

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

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