如果我是 12306 的架构师，我保证它不挂！

如果我是 12306 的架构师，我保证它不挂！

一大早上，N 多的技术公众号发文章称，12306 又挂了。使用 Github 上 2.3K 的抢票软件，我不到 3 秒就抢到票了。。。

类似的话题，一大堆技术号在发，好像在吹响胜利的号角。

不管你用不用抢票软件，都有可能抢不到票。因为票就那么多，有人抢到就有人抢不到。

除此之外，还有不少技术号称，只有程序员才知道 12306 的技术有多难。我个人就是一个程序员，以我个人的经验来看，12306 的技术其实是走歪了。

所以，我发了一个朋友圈，不少人求教思路，于是，就有了这篇文章。

我们都知道，一辆火车，每一天都有 N 种卖法。多数人的思考和实现方法都是动态计算车票。动态算票有多难？

假设你买手机，库存 100，卖出去一台，库存就是 99。但车票不一样，，他是可以买半个的，比如 Z35，北京到广州，一共停 5 个站：北京西，郑州，武昌，长沙，广州。

如果硬卧有 200 张，并且全部没有被限制，随便买。有人买了北京西到郑州的一张票，12306 数据库的记录就要变，当天 Z35，北京到广州剩余 199 张，郑州到广州剩余 1 张。

如果有人又买了郑州到长沙的两张票，12306 数据库的记录就要变。当天 Z35，北京到广州剩余 198 张，长沙到广州剩余 2 张，北京西到郑州剩余 1 张。

以此类推，每天有那么多班次，那么多人，那么多流量，想不挂都难。

其实，12306 之所以是这么难，我认为它的技术线路走歪了。

第一是，我们不能把买票变成抢购，因为它需要动态计算余票。因此，我们需要把预订改成预约，预约后就付款，付款后，后台慢慢的出票，再计算余票。这样就分流了，没有票的就发短信通知，购买失败。

第二种是，借助大数据。预测每辆车每天每个站的预估票数，提前生成票数，然后再上架。对，和买商品一样。我上架多少，卖多少。如果有没有卖出去的，或不够卖的情况，后台在计算一遍，把没卖出去的调整站间票数，再次上架销售。

这两种做法都是避免，每卖出一张就算一次余票，和剩余卖法。减少服务器的压力。

如果不从根上解决这个问题，每年你再增加动车，新开高铁等，系统实时计算的需求就越来越多。服务器始终是扛不住的。

这还不说，线上，线下，电话预订，第三方刷票软件等的疯狂流量。你说你能不挂吗？

说实话，过年不一定要回家，出去旅游也是一个不错的选择。平时出去旅游，到处都是人。过年，人少的时候，正是旅游的好时机。

最后，送 3 个抢票软件的。

12306项目地址：https://github.com/testerSunshine/12306

py12306项目地址：https://github.com/pjialin/py12306/

12306bypass (分流抢票)傻瓜式操作，链接: https://pan.baidu.com/s/1fxNOHHytcfutEP8YgoSZ6g 提取码: 8h7k