文章纯属个人猜测，和12306木有任何关系，咱也没到能接触这种大架构网站的级别。

 在论证这些之前先大概罗列一下国内列车（包括传统火车，动车，高铁）行情。3

1：车站，全国大大小小的列车客运站大约3000的数量，

2：车次，开通的列车车次两年前约3700个班次，现在预估4000左右；

3：座位 ，动车组车厢二等座约80人，一般一组8个箱，约600个座位，还有两组串联16节车厢的情况，超过1000个座位。

     还有普通列车接近20节车厢的，差不多2000座位。

4：列车停靠站，一般的停靠站数量动车组多的由20+，列车就更多，有停靠50+的车站，查询到的最多的班次停靠站有62个。

5：列车票，最多提前预定30个工作日。

从数据量上来说，提供查询的最大化座位量 4000（车次）*800（平均车次座位数量）*30（最长预售天数）=96，000，000；

根据报道2019年春运的40天，全国铁路累计发送旅客4.1亿人次，所以这个96，000，000应该超出了实际情况不少。

停靠站数量目前来说查询到最长的是62个，如果按平均每次停站5分钟，那如果60个停靠站，全程的旅途停站的时间达到5个小时。

而这个时间从北京出发开往上海的车子早就到站返回了，预估可以预见的未来，不会有超过60个停靠站的车次出现。所以，

每一个座位的余票情况可以用一个64位的数字来表示。那这个数据量大约是96，000，000*8（64位数字）约为 768，000，000；

小于768M，都没到一个G。所以对于查询余票的计算可以抛开IO和数据库的影响，直接内存中运行。

如何计算：停靠站最多60，我们以中位数来算，即使停靠30个站，可售卖的票种类也有C(30,2)=600种。与列车平均座位数量800在数量上相当。

所以在计算余票时，大概率事件，需要比对每一个座位的余票数量，即使做优化，能达到的效率不会高多少。

举个列子从南宁往广州的动车。按平均800个座位，客户下了一个查询从南宁去梧州的座位余票（1111000.。。。途径平南，滕县两站所以4个1）

则必须与800个座位的每个64位数字求与，累计为零结果数量，才知余票情况。

而相对的，淘宝的库存查询可以直接取数，所以如果淘宝库存查询的事件复杂度为基准，那余票查询的时间复杂度是它的800*N倍（因为有循环控制，累加的存在所以有N>3）；

所以余票查询的时间复杂度是淘宝库存查询复杂度的至少2400倍。

那是不是意味着余票查询系统需要的硬件成本比淘宝高上前倍？其实这也未必，前面说了，余票系统数据量比较小，可直接内存计算。两个情况合计起来，凭我现在的经验

也做不出推断，只能说它的时间计算复杂度确实是淘宝的数千倍。至于需要什么样的硬件，之后有时间，在上代码测试下结果。