咱也谈谈铁路订票网的构架

给我的感觉， 这个问题不是什么太难的东西。
因为大家都是在讨论技术，而忽略了每天的车次信息是固定的，
而且查询条件也给了我们一个静态化的可行性。

这样就给我们提供了一个优化空间非常大的业务信息，
不知道大家为什么专注于讨论那么多亿次的并发，
而不是先看一下在业务处理上，能不能化这么高的并发分化一下。
出发地，目的地，日期对就车次的信息都静态化成一个大的Hash表，
就是我要提的优化的基础。

不过最近看讨论了这么多天，就是下边这样。
1.什么短时高并发，对技术要求多高。
2.什么各种投资问题。

不错，要是真的什么短时高并发， 确实是个技术难题，可是我不觉得这个铁路订票是这种系统。
首先大家的基本概念应该是这样。
订票用户-》所有的数据查询-》下订单。
如果把上面的数据查询考虑成是所有用户对于所有车次的，单结点查询，的确是这样的。
数据量确实是大。几亿次肯定是达到了。
我的考虑就是，动态变成静态。
对数据库查询，变成Hash的Key值计算。
模糊变成精确。

就变成这样了。以一天的订票数据为例。
首先就是查询，
现在的查询条件是，出发地，目的地，日期。而且这个出发地，目的地是针对车的，只要是转车，就不会有结果。
那么，能否把出发地，目的地，日期对就车次的信息都静态化成一个大的Hash表呢？
肯定没问题。
以Hash(出发地，目的地，日期)得到一个车次信息， 这部分是可以静态化成一个大的Hash表的，也就是几十万条数据吧，查询起来肯定是超快的。
这样，就可以把最开始的数据库查询Hash化，把原来的动态计算变成一个静态的Hash表的查询。
再把所有的车票信息分散成一个个的小数据表，每几十个车次，放到一个服务器上，这样也就是十几万条的数据信息，如果用memorycached，或是一些关系数据库都可以，反正十几万条数据的简单操作，怎么都能优化得相当快。
基本上是下边这种结构。


如果一来，就是一个简单的分布式的系统，
那有什么大问题啊。
只要加些机器，提个带宽肯定就是个很简单的东西吧。