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

friendmine

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

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

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

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

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


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

abuve

这么好的个人观点，怎么没人来讨论呢！支持一下，学习了。

fuq1986

楼主好厉害，虽然看不懂。我是菜鸟啊

friendmine

我只是觉得这么做是可行的，而且是专门针对这种订票系统。
不过我对于这些都不懂，只是一个想法，
可惜，回的人不多。
不过我感觉是大家在从ER这种数据库的处理方式过渡到NoSQL这种方式应该考虑的东西。
或者说我们在考虑应用ER的数据库结构的时候，是不是要同时考虑一下NoSQL等类似的东西。

expert1

回复 1# friendmine


    看明白了，我对这种不太懂，不过有个看法，座位号很多吧，比如15车50号，3车卧铺下铺，这种怎么标示？hash ?

friendmine

座位号这种东西，就是到最后的特定车次票务服务器了。
这个如果不用hash也没关系啊。
一辆车也就是几千张票吧。
我想就是把车次这种资源的查询加快，弄成一个hash,
具体的每辆车的，可以由具体的服务器来处理。
而服务器由前面的大的车次对应的hash直接定位，
这样就能减少查询次数。

荒废庭院

楼主，我觉得这里关键问题是，更新的问题
大量并发下，要保证原子更新。

friendmine

这种没有大量并发下的更新。
实际上我们需要的更新是在，票的有无上。
这个是在具体的某个车次对应的服务器上做的。
相应的一个车次的票是几千张，那么几千，几万条的查询或是更新是很容易的。
大量的查询主要是一个是 按起始点查车，这个是由一个大的hash表来处理，事先生成。
二就是具体的车查票。由上一个查询固定到每次车后，由页面发起ajax什么的，直接到具体的服务器上查询，这样就不是在全国的票务上查询。
只是具体的车上。
说白了，就是把票状态的表做物理分离。

yulihua49

friendmine 发表于 2012-02-20 19:39
给我的感觉， 这个问题不是什么太难的东西。
因为大家都是在讨论技术，而忽略了每天的车次信息是固定的，
...

12306的问题不是数据库或查询的问题。是安全架构的问题。他有一个网闸（GAP)是瓶颈。

friendmine

那就没办法了，这个不是我所知的范围了。