买不到高铁票的人们，在回家路上骚出了一片天

行内人才是真正定性分析，当年12306刚出来的时候说花了2500万，我哥们直接分析说这点钱做不成，结果就是当年春运崩溃，然后花了几十亿.....才是现在的基础。
这事情跟行外人说来，算法简直一钱不值，连关键技术都算不上，光知道吹什么峰值一秒多少多少，总认为淘宝双11那本事足够，结果阿里非常聪明的不去干，只做分流支持。

第三点可以分为两步
每一趟车单独一个进程处理，每一个站点，记一个总座位数。订票时，无需加锁，订票起点到终点计数挨个减一，如果没有负数，那么说明余票满足，进入第二步；否则从后往前加回去，重试n次不成功报告抢票失败。
第二步：因为都是火车容量可以满足需求的，那么进入抢座位，这个时候简单处理，直接串行分配，到了这一步，数量已经大减了，一单分配成功，再提交数据库。
然后一个刀片承载100进程，相当于100趟车，全国几千趟车，几十个刀片可以负载。然后网页后端做负载均衡，调度到合适的后台进程上，这样就可以解决。
现在的解决方案是完全依赖数据库，太通用了，所以无法打到特定功能的效率。
按照这个方案，一秒钟一个进程可以处理至少一万个选择。几千个进程，每秒钟可以处理几千万个订单。
灾难恢复，数据库不考虑，如果分配进程崩溃了，那么直接暂停该线的选择，然后从数据库抓数据还原场景，然后再开放这条车次的选择。

是哈，以前年轻的时候也吐槽过，不过工作后，从皮毛上了解了一下，才知道其中的难点。而且还只是皮毛的了解，里面涉及的各个方方面面复杂的吓人，这些年12306不断在完善，而且没有出现宕机的情况，已经是非常牛X的事了。