在外地打工的你，肯定都经历过春运抢票！经历过网站进去就卡死、进去就无票的无奈！今天从技术的角度来分析一下为什么你买不到票！买票一.场景分析都说12306做的烂，技术水平差，也难怪用户吐槽，12306刚上线的时候，一到买票就崩溃wx投票网站，搞得大家都买不到，排队起码还能碰碰运气，网上真的是无可奈何。我们从技术角度看，全国几亿用户，向潮水一样涌进来买票，堪比98年的大洪水啊，谁能扛得住。好在，经过多年的努力，现在的12306已经健硕了很多，虽然票还是难买，但僧多粥少，确实没有办法。从数据量看，12306的数据肯定没有微信qq、淘宝等这些大厂量大，但论并发量，肯定12306更大；车次上，也就几千辆wx投票网站，每辆车座位几千个，数据量都不大，但是可能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，wei一的瑕疵是数据同步没那么及时，所以有时候总是查询有票，下单却没票，就是cache的数据还没有及时更新。3.请求排队把用户请求先放队列，如1000张票，可以放2000个请求进来，根据顺序下单，售完后剩余的请求返回失败。通过队列和异步操作，把下单和支付一个点的事情扩展成了一个时间段来做，系统压力大大减轻了。通过层层过滤，大量的请求被拦截到了上游，剩余的在DB层处理的游刃有余了。四.总结：通过以上的分析可见：1.系统表现层的一些改动，虽然稍微降低了用户体验，却能大大降低系统难度，所以程序员同学费尽脑汁想方案，不如和产品好好聊一聊；2.针对具体业务，肯定还有很多的更细节的优化；3.万变不离其宗，其实根本的思想就是“限流”，后续有时间再聊一聊高并发下的数据安全。抛砖引玉，感谢阅读，欢迎多提宝贵意见！