我说一下个人看法，12306的客户端虽然做的一般，但12306的服务器端其实做的挺好了。中国每年春运都是数以亿计的集中抢占的各种服务请求，试问这个世界上除了面向过年的中国人民，应该很少有峰值时期需要承受如此负载压力的服务端。
然而铁路也不可能总是保持这种“巅峰”服务状态，因为峰值时间持续很短，一年365天里可能只有分散的十来天需要承受“大范围人类迁徙”造成的巨大负载压力。比如铁总有N台服务器来处理买票业务的请求，但是在少见的峰值时间段，服务请求可能会瞬间提升数量级。比如（纯假设）平时平均每分钟铁总只需要处理一万个请求，开抢年30票的时候可能每分钟就有上千万甚至上亿个请求过来。这样铁总的N台服务器肯定是不够用的，理论上比如（纯假设）需要增加至1000N台服务器才能满足需求。那你觉得铁总哪里平白瞬间增加一千倍的机器（/虚拟机）预算？
虽然我不知道铁总具体是怎么操作的，有内部知道的如果不保密可以分享一下。但我猜测（纯猜）铁总不可能平日里就买够1000N个机器备用，这样成本太高。日常使用就备够N台就行了，在快到大小峰值来临时（各大节日），迅速大范围从各大官方有合作的云服务商那里租用计算资源，快速部署后上线服务。在峰值过去后再还回去。
但是即便如此，中国人民过年30的热情还是非常高涨，能租来的计算资源应该也是勉强够用，达不到绰绰有余的地步，所以还是会有客户端请求得不到服务的现象。特别是集中不间断抢票请求大范围爆发的时候。
对于解决方式，可能有人说让铁总买更多的机器不就得了？反正他们拿人民的钱，应该为人民做好服务。但事实不是这么简单，钱也不是大风刮来的，计算资源也不是，都有上限。
如果在服务资源上不能再有更多可观的文章，那只能在客户服务请求上做文章了。比如引入预约请求，来拉长处理窗口的时间。每个人在春运抢票前输入自己可接受的始发地和目的地，输入可接受的出发时间段，输入优先偏好的车次或车型(K, T, G, D, C等），输入人数以及是否必要连坐等。预约输入后提交后，由服务器后续排队计算给出可以乘坐的车次和座位，服务端先为用户reserve下车票，让用户在限定时间内（比如一小时）付款确认。这样可以避免集中抢票时的过载请求，要知道用户在付款前每一次查询车次、退出、重查、刷新等操作都会造成请求，在服务端负载本来就过载的情况下，这些查询、刷新等非最终确定买票的请求其实是浪费计算资源，而预约可以有效在峰值时段避免这些请求的大量涌入，将计算资源集中用于票和座位的分配上。
还有一个拉长处理的方法是政策是过年的法定假期多给几天（调配过来也行），然后在不影响过年的前提下分不同时段放假。让旅客可以分批次从年28~30分开回家，从年初五到年初八分开回来，总之分而治之也是一个办法……就像一些城市为了避免早高峰，让一部分人8:00上班，一部分人8:30，一部分人9:00上班一样，一天都理论上工作8小时。
但是不管怎么说，我们也是在这里自说自话，铁总或政策的改动需要考虑更多因素。以上纯属个人拙见，很多属于个人猜测，不必过于当真。愿大家都能过个好年。
<hr/>补充：没想到大家对这个话题这么感兴趣。我想说的是，一个萝卜一个坑，我们可以通过调度优化让一个坑争取在可接受时间内为四五个萝卜服务。但是一口气同时来一万个萝卜是怎么也排不开的，即使排开，那时间上也接受不了。就像告诉你十年后第一万个萝卜才能排上，这样“排”就没有意义了。所以硬性条件（火车和铁路）的不足必然会引发“抢”，再怎么优化程序也只是想办法尽量让抢的行为更有序一些，避免不必要的混乱，但避免不了“抢”的现实。
所以还请大家理性抢票，尽早准备充足的预案，安全回家过年。也提前祝大家新年快乐～ |
