12306是用什么技术优化的（来学习高并发网站的优化）

在外地打工的你，肯定都经历过春运抢票！

经历过网站进去就卡死、进去就无票的无奈！

今天从技术的角度来分析一下为什么你买不到票！

买票

一 . 场景分析

都说12306做的烂，技术水平差，也难怪用户吐槽，12306刚上线的时候，一到买票就崩溃，搞得大家都买不到，排队起码还能碰碰运气，网上真的是无可奈何。

我们从技术角度看，全国几亿用户，向潮水一样涌进来买票，堪比98年的大洪水啊，谁能扛得住。

好在，经过多年的努力，现在的12306已经健硕了很多，虽然票还是难买，但僧多粥少，确实没有办法。

从数据量看，12306的数据肯定没有微信qq、淘宝等这些大厂量大，但论并发量，肯定12306更大；车次上，也就几千辆，每辆车座位几千个，数据量都不大，但是可能100w人抢1000张票，锁冲突是非常大的。一般的互联网应用通过合理的分库分表，都能很好的降低锁冲突，但是对12306并不太适用，这就是为什么12306难点所在。

二. 我们看看12306所采取的措施：

1. 复杂的验证码

“一票难求”，催生了大量的网络刷票软件，有免费的，有收费的，五花八门！不少网友也用过，一般还是有效的。刷票软件从登录、选票、下单，都通过程序完成，比人肉买票快不知多少倍，这也是为什么到点就没票的原因，因为一瞬间就卖完了。

所以，为了公平起见，官方就限制任何的三方刷票软件，从登录开始，就使用了复杂的验证码，采用图片验证码，增加程序自动识别的难度，防止自动刷票软件登录；

验证码

在github上也有不少开源的抢票程序，感兴趣的可以研究一下。

2. 客户端的限制

查询车票

查询余票时，在没有返回结果之前，‘查询’按钮置灰，不能连续点击，对于购票用户中99%是普通用户，这样就限制了这些用户无脑狂刷了。

3.票数显示折中

因为余票查询是量非常大的操作，数据肯定放到了cache，如果显示余票数，每次数量变动都需要刷新cache，如果只显示 “有无”，就只需要临界值才需要淘汰。

查询

4. 分散始发站售票时间

从早上8：00开始，到下午18：00 ，每个整点和半点都有始发站开始售票，这样就把流量分散到了一天的多个点上，系统的压力就大大减轻了

售票时间

5. 购票和支付分开

先购票，购票成功后可以45分钟内付款，这样支付系统压力也小了很多，和购票流分开，也达到了错峰的效果。

为了方便捡漏，网站还增加了候补功能，也避免了用户一直刷票了。

三 . 上面都是我们看到的优化措施，那么看不到的server端会采取哪些措施呢？

通过浏览器前端的限制，99%的无效请求已经被拦截，但是对于专业人士，如刷票软件，是可以轻松绕过这些限制的，仍然会有大量请求到达服务器，

1. 频率限制

短时间内相同用户的多次请求，肯定只处理一次，其他的忽略请求计数可以通过redis来实现，也可以通过lua脚本来实现。通过频率限制，99%的多余请求也被过滤掉了。

2.cache的使用，

12306的特点是读操作远远大于写操作，应对海量的查询请求，肯定会用到cache，唯一的瑕疵是数据同步没那么及时，所以有时候总是查询有票，下单却没票，就是cache的数据还没有及时更新。

3.请求排队

把用户请求先放队列，如1000张票，可以放2000个请求进来，根据顺序下单，售完后剩余的请求返回失败。

通过队列和异步操作，把下单和支付一个点的事情扩展成了一个时间段来做，系统压力大大减轻了。

通过层层过滤，大量的请求被拦截到了上游，剩余的在DB层处理的游刃有余了。

四 .总结：

通过以上的分析可见：

1. 系统表现层的一些改动，虽然稍微降低了用户体验 ，却能大大降低系统难度，所以程序员同学费尽脑汁想方案，不如和产品好好聊一聊；

2. 针对具体业务 ，肯定还有很多的更细节的优化；

3.万变不离其宗，其实根本的思想就是“限流” ，后续有时间再聊一聊高并发下的数据安全。

抛砖引玉 ，感谢阅读，欢迎多提宝贵意见！