大家都知道12306可是目前中国访问量最大的系统之一，特别是节假日的时候更是一票难求，在几年前，每到节假日，系统由于不堪重负，常常宕机，后来马云将阿里巴巴的技术无偿提供给12306，对系统进行了升级改造，经过阿里巴巴技术团队的改造，系统比较稳定，那么阿里巴巴的技术团队是怎么实现高并发的购票交易的呢，12306系统的架构是怎样的，今天我们来讲讲他是怎么做到高并发的。
12306的系统主要分为查票与买票交易，说白了就是读与写数据，很显然，它肯定实现读写分离
那么我们来看看读，其实这个很好解决，多级缓存嘛，无非是多弄些缓存服务器集群，大家查的数据都是缓存中的数据，由于缓存的数据同步时间不一致，所以导致两个用户同一时间看到同一班次余票的数量有差异，而且经常在买票中，查票的时候明明有票，但是买的时候就提示余票不足，这也重复说明了买票与查票是两个独立的系统
1、查票的架构
预估算法：全国1000车次的车，每个车车位为1000，预售30天，也就是30天的最大订单量为1000*1000*30=30000000，但是抢票的人可以能是1亿，那么，肯定有人抢不到，必须把核心的业务服务器来处理已经抢票成功的人，保护主核心业务服务器不受外界抢票人数干扰
1.1、将查票请求生成sql，去redis集群查找缓存，未找到或过期，返回原数据，并发送异步更新缓存的消息到消息队列服务器进行异步缓存更新
1.2、1台并发查询20万，500台，以键值形式存储票源信息，如北京到上海表示为md5(sql)：data,time,当时间达到失效时间时，主动发送一个更新缓存的指令到更新缓存队列
1.3、订单根据算法，分配到不同的数据库上，订单数据库500台，每天交易
2、购票的架构
上面解决了查票的问题，那么下面就要解决买票的问题了，以前12306系统并发一多就挂了，这是由于12306系统没有做核心业务承载保护功能，也就是熔断机制
到系统达到他最大的承载量时，如果不进行保护，当然会挂掉
经过阿里巴巴技术团队改造后的12306系统采用了队列的方式进行购票处理，我们购票的时候会显示一个排队的时间及排队的人数，这也是12306汲取了电商秒杀系统架构的结果，保护核心业务逻辑服务
2.1、根据redis中的车次余票信息进行抢票过滤，按照请求的顺序进行入队操作，按照每台承担10万的并发，需要1000台
2.2、车票余票建立一个key，通过decri，将请求放入kalfa消息队列，过滤多余的购票请求，每台10万并发，1000台
2.3、存入有效的购买人的购票数据，后台业务处理服务器进行消息处理，实际有效余票队列为3000万，每台100万，30台
2.4、监听消息 队列数据，进行订单处理，每台tps为30000，共需要1000台
2.5、订单根据算法，分配到不同的数据库上，订单数据库500台，每天交易
{{collectdata}}
网友评论0