索爱x10mini，大书包小说，苹果ipad怎么用
转眼间2021年的五一假期已经过去了，经常被人诟病的12306购票系统今年毫无疑问的、又一次被网友吐槽了，原因自然就是又出现了加载速度过慢的问题：
尤其是当网站开启售票、抢票时，12306就会经常出现并发超荷的情况，这也不能怨12306的架构程序员，任何程序员面对一个每天点击量高达1495亿次、300多万并发量的网站，估计都会头疼不已
尤其是五一长假期间，全国上下有几亿人在同时抢票，可以说12306承受了这个世界上能秒杀任何系统的QPS
那么其背后的服务端架构是什么样的呢？
12306的进化史
12306购票网站最早成立于2011年，上线的当天网站就迎来了十分巨大的访问量，直接导致了网站的宕机，稍微的订单和登录人数增加就会导致服务器反应不及，车次信息和购票无法刷出。甚至有人登录12306都无法进入，大大的“404错误”标识飘荡在空空如也的网站上。
往后数年的春运期间，12306都没有抗住流量大考，甚至在2014年春运时彻底瘫痪。年年买不到票。用户们这个年年吐槽12306。
2015年，12306终于反应过来，开始与各类商业公司合作，比如将75%的余票查询业务切换到了阿里云上，火车票查询业务占据了整个网站流量。合作后，提高了网站的负担能力。2019年的春运，12306挺过了流量的高峰297亿次的日访问量。
主要依靠的架构技术有下面几种：
1、大型高并发系统架构
高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段(双火机房、节点容错、服务器灾备等)保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。下边是一个简单的示意图:
2、数据源
先不说票少人多的问题，12306从早期一直到现在最大的问题就是遗留系统，也就是原来的火车站和售票点的那套
这套系统部署在铁路内部专网，而且票务数据也都留在各个铁路局，所有最早的12306系统在查票和买票的时候，都会通过专用网闸和防火墙去又慢又不爽的各个铁路局去查余票和改余票
这样子过防火墙在两个网络间查询有多慢，大家看最早的版本(2012年春节)就知道了，查询一旦稍微高一点就挂，后来把查票单独分离出来做了缓存处理，但是一直到现在的购票处理也都是要去铁路内网的各个数据库去改数据的。
最后貌似做了预处理，把票放在一个票池子里，提前分配，一少部分进入车站和网点，大部分到12306的网站，回流的退票也到票池子里经过重新计算车次以后过段时间再重新放出来。
就算这样实际上也比较慢，因为数据是分散在不同的铁路局（铁路内网）的，这点铁总也想把票都收到一起，到时候这个改进就是利益相关的扯皮了。
本文地址：http://www.reviewcode.cn/youxikaifa/210860.html 转载请注明出处！
