抢票开始了，很多用户被提示搞得懊恼，心情若过山车般起落。特别是这样一组提示：
1、余票不足！
2、没有足够的票!
3、目前排队人数已经超过余票张数，请您选择其他席别或车次。

明明是看到余票查询结果里有几张，甚至上百张票，一下单就这提示，你说气人不？出提示了，立即再回过头去刷新余票，依然显示余票一张未少，这是闹哪样，逗人玩儿呢？

带着这些问题，小编和技术做了一个讨论，结果是：这完全是12306一种不得已而为之的用户体验让步技术方案，导致这一让步的原因则是www.12306.cn的抢票访问压力。应对瞬间巨大的访问压力，12306网站采用了如下2种技术：
1、购买大量的CDN服务器，进行余票数据缓存分发；
2、下单过程采用排队分配车票机制。

余票数据通过CDN服务缓存后，就不是分配票服务器的实时数据了。余票信息采用缓存分发，主要是根据普通用户购票的行为来的，普通用户大多是查过来看过去地比较，最后才决定下单购买，也有用户比较了一通，最后甚至并不购买。这样就导致查询余票（下行）接口的访问是下单接口访问的几十倍，甚至几百倍。给查看的余票数据就被专门分离出来，只要“应付”一下大多数人看看的需要即可，真正需要购票的用户，会提交订单申请，再实时分配。

缓存也是动态的，当一个用户发起查询余票的网络请求时，域名服务器会根据网络就近原则分配一个实际的CDN节点给用户。CDN根据查询条件查看自己的缓存是否有没过期的数据，若存在就立即返回给用户，不存在才请求分配票服务器的实时余票信息。一个CDN节点通常是同区域的很多人同时使用，因此缓存也是共享的。即便你之前未访问过，也可能其他用户请求过同样条件的余票信息，因此数据也是旧的。这个缓存时间具体是多少？这个就只能是12306的运维人员能说清了。分离出来的缓存数据已经能足够快反应用户请求了，为了防止无谓（相同数据）的网络传输，余票接口还限制了刷新时间间隔。

抢票时大量的用户查询到了余票，同时迅速提交订单（上行），12306技术人员发现即便分离缓存了余票信息，下单接口还是面临巨大的并发压力，导致系统拥堵僵死。这时，有聪明人就把现实中的排队逻辑运用在了分配车票这件事上。首先，迅速大量地收下来大家的购票请求，同时按照先后次序排队；另一方面，用一系列算法来给大家的请求慢慢分配票，比如，60岁以上的先分配下铺等等。

抢票过程讲究的是尽快查询到余票后，尽快提交订单，不要浪费无谓的时间而耽误成功购票。买火车票APP首先让你准备好订单需要的车次、坐席，以及购票人数据，在遵守CDN服务器的规则下查询余票，查到余票后立即申请订单，随即把下单验证码交给熟练的客服人员用电脑鼠标输入，然后立即提交订单。整个过程一气呵成，在稳定的基础上追求速度的极致，当然，网络网速，以及不可预知的缓存对查到余票的影响也是导致失败的一些重要原因。在条件一定的情况下，其实不用太刻意责怪自己的抢票太慢，你已经比那些不借助任何工具软件的抢票人要快很多了。

当然，当出现文章开头说的3种提示时，表示本次票库的票已经分配完了，不用抓狂地再次立即狂点[下单]或[监控买票]，否则只能增加自己的懊恼情绪！你可以重新定义托管任务为“代下订单”，静候有人退票、限售解禁等购票机会。

更多参考阅读：
2016春运抢票，需要知道的几点
春运抢票操作方法