文章纯属个人猜测，和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位数字求与，累计为零结果数量，才知余票情况。
而相对的，淘宝的库存查询可以直接取数，所以如果淘宝库存查询的事件复杂度时1，那余票查询的时间复杂度是800*N（因为有循环控制，累加的存在所以有N>3）；
所以余票查询的时间复杂度是淘宝库存查询复杂度的至少2400倍。
那是不是意味着余票查询系统需要的硬件成本比淘宝高数千倍？其实这也未必，前面说了，余票系统数据量比较小，可直接内存计算。两个情况合计起来，凭我现在的经验
也做不出推断，至于需要什么样的硬件，之后有时间，在上代码测试下结果。
但是12306说它计算复杂度很高确实没问题，大家一起谅解一下。
原文：https://www.cnblogs.com/luochenshulin/p/12097843.html