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

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