架构必看:12306抢票亿级流量架构演进(图解+秒懂+史上最全)
架构必看：12306抢票亿级流量架构演进（图解+秒懂+史上最全）
⼴交天下好友
⽂章很长，⽽且持续更新，建议收藏起来，慢慢读！ 奉上以下珍贵的学习资源：
推荐：⼊⼤⼚、做架构、⼤⼒提升Java 内功的精彩博⽂
⼊⼤⼚、做架构、⼤⼒提升Java 内功必备的精彩博⽂2021 秋招涨薪1W + 必备的精彩博⽂
1：2：
3: （⾯试必备）4: （史上最全）
5:6:
7:8：
9:10：
11:
Java ⾯试题 30个专题 , 史上最全 , ⾯试必刷阿⾥、京东、美团... 随意挑、横着⾛
1：
17、
29、30、
9.更多专题，请参见【】
SpringCloud 精彩博⽂
更多专题，请参见【】
第⼀代架构：双机热备模式
2011 年 6 ⽉ 12 ⽇，系统投⼊试运⾏，发售京津城际 列车车票；2011 年 9 ⽉ 30 ⽇，发售全路动车组车票；
2011 年底，发售全路列车车票，互联⽹正式成为铁 路新的售票渠道。
互联⽹售票系统设计了缓存服务、⽤户管理、车票查询、订单及电⼦客票处理 等多个相对独⽴的业务分区，以及三级⽹络安全域， 分别是外⽹、内⽹和客票⽹，系统的体系架构如图所⽰：
数据库的维度：
⽤户管理、车票查询采⽤了传统的关系型数据库。
其中车票查询业务部署了多套负载均衡⼯作模式的数据库， 订单/ 电⼦客票处理业务采⽤了双机热备模式的数据库，上述数据库均运⾏在⼩型机平台上。
外⽹的车次、 余票等缓存服务采⽤了基于内存计算的 NoSQL 数据 库，运⾏在 X86 平台上。
第⼀代架构的性能：
上线前的压⼒测试，⼀笔 流程包含⽤户登录、车票查询、下单及⽀付等业务操作，系统极限交易能⼒为 34 张 /s，按按⾼峰期 10 h计算，售票量可达到 120 万张 / 天的设计能⼒。
第⼀代⽹络架构：
第⼆代架构：缓存提速+队列削峰+分库分表+读写分离
主要问题：
2012 年春运期间，由于访问量超出设计预期， 12306 ⽹站在⾼峰期出现了⼀系列问题：
页⾯打开缓慢、
查询和下单报错
后台系统过载
⽤户体验不佳
根因分析：
（1）请求⾼峰（类似于秒杀）响应迟缓
放票时 ⾼并发的下单集中在⼀起，形成请求⾼峰（类似于秒杀），请求导致订单 / 电⼦客 票数据库负载过⾼，引起交易响应时间过长，造成 AS 以及 inetis 的交易线程池拥堵。下单长时间不响应，同⼀次购买，⽤户会反复重试，从⽽加剧拥堵。 由于响应时间过程，⽤户进⽽反复重试，⼀次操作变成多次，操
作此时倍数增长，进⼀步 造成
AS（Application Server）的查询线程池拥堵, 导致响应时间进⼀步拉长
假如是tomcat ，设计了340条线程，1000⼈买票，数据库操作每秒34个订单，线程池就满了。
请求还需要在等待队列中排队。
最⼤⼯作线程数，默认200。
12306 放票时间
最⼤连接数默认是10000
等待队列长度，默认100。
最⼩⼯作空闲线程数，默认10。
（2）请求⾼峰时数据库负载过⾼
放票时（请求⾼峰时 下单请求、查询请求过多， 导致订单 / 电⼦客 票数据库负载过⾼，造成数据库连接数会被占满。
数据库的连接数是⾮常宝贵的系统资源，不可能⽆限增长，此时应⽤将⽆法再进⾏横向扩容，业务将⽆法继续发展。
订单 / 电⼦客票数据库负载过⾼时，对线下车站的换票业务产⽣影响。
（3）级联雪崩：
AS 线程池的拥堵进⼀步造成 Web 对外服务线程的拥堵，影响页⾯打开及业务逻辑处理，造 成页⾯打开速度缓慢和超时错误。
响应时间拉长之后，导致内外⽹安全平台上在活动及新建连接过多，性能下降，也导致 Web 访问 AS 出错。
（5）部分⽤户不可⽤
为减轻⽹站压⼒，降低查询和下单的请求量， ⽹站被迫降级运⾏，限制在线的登录⽤户数量，造成部分⽤户不能登录⽹站。
结合系统监控数据，梳理上述主要问题的原因和关联关系， 总结出主要问题：
是由于车票查询以及订单 / 电⼦客票业务分区处理能⼒不⾜，造成⾼峰期⾼并发访问请求下响应时间过长，加之各个业务分区未能很好进⾏隔离，导致系统由内⾄外产⽣“雪崩”效应，造成⽹站拥堵，影响⽤户的购票体验。
优化后的架构图

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。