12306 能扛得住明星出轨这种流量冲击吗？ 第1页

对于一般的流行网站来说，明星出轨的流量叫做冲击。

对于12306来说，明星出轨的流量叫做一个普通的星期二。

先说答案，扛得住。

再说v2ex上面的发言，

等待会上图就知道阿里云在12306上面做了什么东西。

下楼买个早饭，回头答。

正经复制之前的回答.

全文如下:

2012年之前的业务流程图:

第一次优化之前的系统结构

大概是2012年.
互联网售票系统作为客票系统一个新的售票渠 道，建设之初，在借鉴和参考客票核心系统架构的基 础上，根据互联网应用的特点，为系统设计了缓存 服务、用户管理、车票查询、订单及电子客票处理 等多个相对独立的业务分区，以及三级网络安全域， 分别是外网、内网和客票网，系统的体系架构如图 1 所示。
具体实现时，用户管理、车票查询及订单 / 电 子客票处理均采用了传统的关系型数据库，其中车 票查询业务部署了多套负载均衡工作模式的数据库， 订单 / 电子客票处理业务采用了双机热备模式的数据 库，上述数据库均运行在小型机平台上。外网的车次、 余票等缓存服务采用了基于内存计算的 NoSQL 数据 库，运行在 X86 平台上。
其实看下来，该有的都有了。
数据库分库，坐席库分库，缓存，负载均衡...

出现的主要问题包括 ：
（1）高并发的查询请求造成车票查询业务分区 负载过高，查询响应时间过长，用户进而反复重试， 造成 AS（Application Server）的查询线程池拥堵。
（2）放票时高并发的下单请求导致订单 / 电子客 票数据库负载过高，引起交易响应时间过长，造成 AS 以及 inetis 的交易线程池拥堵，下单失败后用户 反复重试，从而加剧拥堵。
（3）AS 线程池的拥堵进一步造成 Web 对外服 务线程的拥堵，影响页面打开及业务逻辑处理，造 成页面打开速度缓慢和超时错误。
（4）内外网安全平台上在活动及新建连接过多 时性能下降，也导致 Web 访问 AS 出错。 （5）订单 / 电子客票数据库负载过高时，对线下 车站的换票业务产生影响。
（6）为减轻网站压力，降低查询和下单的请求量， 网站被迫降级运行，限制在线的登录用户数量，造 成部分用户不能登录网站。
总结来说，用户“拥挤”进来了，
然后一个关卡出问题之后，
拖慢了整个系统的性能，甚至产生了“雪崩”效应。
扩展阅读:
腾讯后台开发技术总监浅谈过载保护 小心雪崩效应
分布式服务框架的雪崩问题 - 凌晨三点半 - 博客园

思考一下，怎么办呢?









如果是我的思路的话，方案如下：

1. 先把AS服务里面的查询大改，至少不能让查询成为瓶颈。

2. 下面交易的改成排队，一个个来，避免多次无效请求。
3. 取票业务之类的拆出来，读从库，不要读主库。

然后我们看下dalao们怎么做的。

针对上述问题及原因，我们将架构优化及重构 思路重点放在提升车票查询和交易处理的响应速度， 以降低查询和交易的延迟。同时尽可能分离核心业 务，减少业务环节间的强关联，具体内容包括 ： 、
（1）使用内存计算 NoSQL 数据库取代传统数据 库，大幅提升车票并发查询能力，车票查询的 TPS/ QPS（Transaction/Query per Second）由不足 1 000 次 /s 提升至超过 20 000 次 /s，RT（Response Time）由原来的 1 s 缩减至 10 ms，使用户可以快速 获取到车次及余票情况。
（2）构建交易处理排队系统，系统先通过队列 接收用户的下单请求，再根据后端处理能力异步地 处理队列中的下单请求。队列的下单请求接收能力超过 10 万笔 / 秒，用户可以在售票高峰期迅速完成 下单操作，等候系统依次处理，等候过程中可以查 询排队状态（等候处理的时间）。排队系统中也采用 了内存计算 NoSQL 数据库。

（3）对订单 / 电子客票进行分节点分库分表改造， 将原有的 1 个节点 1 个库 1 张表物理拆分为 3 个节 点 30 个库 30 张表，线上相关操作按用户名 HASH 的方式被分散到各个节点和库表中，有效提升了核 心交易的处理能力并具备继续横向扩充能力，使用 户在队列中的订票请求可以得到更快的响应和处理。

（4）对订票、取票操作进行了业务分离，由不 同的业务节点（售票节点和取票节点）承载网上售 票和线下取票业务 ；对订单 / 电子客票生成和查询进 行了读写分离，使用内存计算 NoSQL 数据库集中存 储订单 / 电子客票，提供以 Key-Value 为主的查询服 务，订单查询的 TPS 由 200 次 /s 左右提升至 5 000 次 /s 以上，大幅提升了订单 / 电子客票的查询效率。

优化和重构后的架构如图 3 所示。
在新的架构中，通过高效的车票查询集群和缓 存服务，用户以较低延迟即可获取到所需车次的余票 情况。
随后的下单操作（订票请求）直接由排队系 统压入队列处理，不同的车次 / 日期进入不同的队列， 订票请求不再直接面对内网的 AS 和客票网的核心交易系统。

具体实现时，考虑到车票查询结果有缓存延 时，在订票请求进入队列前，还将实时查询车次余票， 确有余票且当前排队人数不超过余票数量时才最终 允许订票请求进入队列。

排队系统收到请求后，采 用动态流量控制策略，即根据位于客票网各个铁路 局客票中心的席位处理以及订单 / 电子客票集群处理 的响应时间，向 AS 提交用户的订票请求，处理响应 时间放慢，则提交速度放慢，反之则提高订票请求 的提交速度。

读写分离，避免了高并发、低延时要 求的查询操作影响交易处理 ；
售票和取票分离，使 网上售票与线下取票互不干扰。

优化架构后的系统在 上线前压力的测试中，极限交易能力为 300 张 /s，可 以满足日售票量 500 万的业务需求。
成绩是这样的：
2013 年春运，优化架构后的 12306 网站最高日 售票量达到 364 万，占全路售票量的 40%，售票量 为 2012 年春运最高峰（119 万）的 3 倍多，各铁路 局客票系统以及 12306 网站性能稳定，运行平稳， 充分证明了架构调整的有效性。
优化思路远比我“想象”（其实我是抄的，2333）的做得好。

然后，还是低估了大家的热情，13年黄金周系统又要炸了。
2013 年十一黄金周，12306 互联网售票量达到 了 460 万，再次接近系统处理的上限，且高峰期外 网入口带宽紧张，已不能满足互联网售票量进一步 提升的需要。此外，作为铁路售票的主要渠道，互 联网售票系统单中心运行模式已不能满足业务安全 性和可靠性的需求。为此，自 2013 年底起启动了 12306 网站的第 2 轮架构优化，优化目标旨在提高系 统的安全可靠性，以及在高峰期具备处理容量的弹性扩充能力

又开始了新一轮的优化啦。

如果大家有印象的话，这个时候某云就出场了。

这一波我基本没什么太好的思路了，直接看下中国铁道科学研究院的dalao们怎么搞吧。
具体内容包括 ：
（1）将用户登录及常用联系人查询等业务迁移 至内存数据库中，提高了相关业务的处理性能和可 靠性。
（2）构建中国铁道科学研究院第 2 生产中心，与既有的中国铁路总公司第1生产中心间实现双活， 提升网站的安全性和可靠性，并将订单 / 电子客票集 群的处理能力提高 1 倍。
（3）在公有云上部署车票查询服务，通过策略配置可随时将车票查询流量分流至公用云，以缓解在售票高峰期网站的处理资源和带宽压力。
架构图如下：

此次架构优化过程中，完成的主要工作包括 ：
（1）构建了用户和常用联系人内存查询集群， 由用户数据库向集群实时同步数据，并实现了读写 分离，用户登录和常用联系人查询的 TPS 提升了 50 倍以上，消除了业务瓶颈。 （2）构建了第 2 生产中心，采用虚拟化技术与 原有的第 1 生产中心组成了双活架构。用户流量通 过 CDN 在两中心间进行对等分配（50:50），两个中 心拥有独立的 Web、AS、缓存服务集群、车票查询 集群、用户及常用联系人集群以及交易中间件，排 队系统以主备模式运行，用户数据双向同步。正常 情况下双中心双活模式运行，其中任一个中心发生 故障时可由另外一个中心承载全部售票业务。
（3）在互联网公用云上部署了车票查询集群及 查询服务，由 CDN 完成车票查询流量在第 1 生产中 心、第 2 生产中心以及公有云间的流量分配，流量 分配可通过动态调整策略在线完成。
总结来说，加机器加机器啊，加内存啊加内存啊，做集群啊做集群啊。
PS：现在看来某云当年在蹭热度，看起来好像没帮忙做了多少技术性上的事情。

然后呢？这个基础的成果：
在双活架构的建设过程中，我们将订单 / 电子客 票集群完全迁移至 X86 虚拟化平台，并扩充至 10 组 节点，100 个库，100 张表。上线前的压力测试验证了 系统可以满足 1 000 万张 / 天的设计售票能力，在 2015 年春运高峰时段，实际售票速度超过了 1000 张 /s（约 合 360 万张 /s）。
第 1 生产中心、第 2 生产中心间订 单 / 电子客票集群具备热切换能力，显著提高了系统 的故障隔离能力和系统的安全及可靠性。
公有云在 2015 年春运期间最高分流了 75% 的查询请求，网站 对外车票查询服务能力增加了 3 倍。基于 CDN 缓存 服务（一级缓存）、双中心及公有云缓存服务（二级 缓存）、双中心及公用云车票查询集群（实时计算）， 12306 网站在 2015 年春运高峰日处理了超过 180 亿 次车票查询服务，平均 TPS 超过 30 万次 /s。
牛逼牛逼，送上我的膝盖！！！

最后...
回顾 12306 互联网售票系统的发展，高峰售票 量由 2012 年春运的 119 万张 / 天，增至 2013 年春 运的 364 万张 / 天，系统架构的优化与调整起到了至 关重要的作用。2014 和 2015 年春运售票量再次超过 500 万和 600 万，最高达到 636 万 / 天，验证了二次 优化后架构的合理性和有效性。
12306 互联网售票系统在优化架构的同时，还在 核心业务中用低成本的 X86 平台全面替代了原有的 小型机平台，其架构优化实践对同类大规模并发访 问的网上交易系统具有重要的借鉴意义。下一步我 们将继续优化订单 / 电子客票双活架构、系统故障感 应、隔离以及智能切换技术，同时深入开展网站用 户行为分析和安全管控机制建设，持续提高系统的 安全性、可靠性及稳定性，改善用户购票体验。
再次抛弃小型机，IBM躺枪...

这个架构大概撑到了2015年之后了，再之后的架构我也没看到别的文献了。
过阵子有空再找找看。

全文完。

各种参考文献:
12306互联网售票系统的架构优化及演进：http://www.tljsjyy.com/CN/article/downloadArticleFile.do?attachType=PDF&id=3756
铁路互联网售票系统的研究与实现: http://www.tljsjyy.com/CN/article/downloadArticleFile.do?attachType=PDF&id=2613
虚拟化技术在12306双活数据中心中的应用:http://www.tljsjyy.com/CN/article/downloadArticleFile.do?attachType=PDF&id=3760
互联网售票中的海量请求处理技术研究:http://www.tljsjyy.com/CN/article/downloadArticleFile.do?attachType=PDF&id=3844

看完了这一堆之后还是会知道铁道部研究院不是吃白饭的，

明星出轨这种大流量下对于他们来说完完全全达不到出票压力大，

加机器能搞得定的事情，大概率其实都不太算问题。

其他答主的优秀回答：

再扯多几句关于政府网站的安全风险。

前几年的项目不太了解，

据我所知近几年的上海这边的政府网站项目，

项目验收基本是走安全评审，由第三方安全公司专门来做审查，

什么SQL注入跨站伪造请求之类的估计分分钟在验收阶段就搞出来了，

还真没想象中那么惨。

而且每个项目投标商都会有类似的安全评分，

每次完成项目都有类似的评分。

不过里面有多少水分其他的东西我也不了解咯。

大概是这样……

更新来了...

数据库相关：

评论区有同学好奇12306的数据库，昨天又去翻了一波铁道部研究院的论文，

回来简单更新一波。

客票系统由中国铁路总公司数据中心，地区数 据中心和所辖车站系统组成，采用分布与集中相结合 的多级分层系统架构 [1]。客户端采用 PB、C# 及 H5 等前端展示技术，运行在 Windows、Android、IOS 等多种操作系统上 ;应用层使用了如 C T M S、D B C S 等自主研发的中间件，以及 JBoss、Nginx 等商业和 开源中间件产品 ;数据层包括数据库、数据复制、集中存储和分布式存储等技术。
目前，数据库支撑着客票系统的核心交易与运 营统计、分析业务，类型包括关系型数据库、数据 仓库、内存数据库和分布式数据库等。其中，数据仓库占比较少，大部分使用商用关系型数据库产品 。

来源：铁路客票系统应用开源数据库技术研究

论文还提到这样的一个图。

扩展资料：关系型数据库服务器 | Sybase | SAP ASE

嘿嘿嘿，显然在16/17年前，12306大部分的数据都是Sybase ASE这货。

在之后，开始往开源数据库上跑。

原文是这样说的。

数据库产品种类繁多，百花齐放 [6]，针对不同业 务场景各具优势 , 有适用于事务处理应用的 OldSQL、 适用于数据分析应用的 NewSQL 和适用于互联网应 用、大数据处理的 NoSQL。通过细化客票系统业务 场景，剥离非交易型业务，如查询，统计分析等业务， 采用更擅长此方面的数据库产品能够更好地突破限制。

细分业务场景的基本策略是对于核心交易部仍采用 Sybase ASE 关系型数据库，并探索研究 PostgreSQL、MySQL 等开源关系型数据库的使用 ; 非交易的场景采用其他类型的数据库，如高速查询采 用内存数据库 Gemfire、Redis、Memcache ;文档文 件存储方面使用 MongoDB、Ceph 等，大数据存储可 以仍然采用 Sybase IQ, 部分场合可以采用 Cassandra、 HBase ;统计分析、数据仓库采用 Hive、NewSQL 数据库 Clustrix，或者 MPP 数据库代表 Greenplum 等; 数据挖掘采用 NLTK 等。
针对不同场景多种数据库综合运用上，客票系 统中一些非核心、非交易的场景已经开始用其他类型数据库进行替换。

然后由于分库分表，也用了一些开源组件。

论文也提到做过云服务化，这也是某云一直在宣传的，然而看下来只是卖服务而已啊。

客票系统对数据库处理能力需求具有规律性， 在节假日售票高峰时，需求最为紧迫，而在非节假日， 需求并不那么突出 [8]，通过将数据库部署在云资源上，提供数据库云服务，在高峰时，动态伸展，满足应 用需要 ;在非高峰时，可以部署其他应用，提高资 源利用率。采用公有云服务还可以降低基础建设和 维护费用，通过支付月租费实现基础设施扩展，减 少运维人员和运维工作量。
铁路客票系统在国庆和春运高峰期间已经采用 云服务进行业务分流，应对客运高峰。

另外一个论文提到也提到了一些系统和数据库的对应关系,直接截图过来算了.

来源:铁路客票系统应用开源数据库技术研究

总结下来就是：

前几年都是靠关系型数据+存储过程之类的东西撑下来的，

最近两年开始搞MySQL/postgreSQL/MongoDB之类的继续再优化,

同时也靠云服务器扩容来支撑春节之类的大流量时间.

还有一些小伙伴对今年老登录不上去或者频繁跳登录页表示奇怪...

然后可能一不小心我又发现了"真相".

以维护铁路旅客运输正常秩序，提供公平公正购票环境为出发点，通过对现有铁路客票系统的黑名单管理现状进行分析，提出了构建完整统一铁路客运黑名单管理体系的解决方案，并对系统高并发处理和分布式访问的关键技术进行简要介绍。铁路客运黑名单管理体系作为铁路客运诚信系统具有重要意义。

来源:铁路客运黑名单管理体系研究

为了确保公平公正售票，保障百姓购票利益，利用大数据技术，结合现有用户购票行为数据，设计基于指数权重的铁路互联网异常用户智能识别算法，并用2017年的用户行为数据进行测试，异常用户预测准确度达80%。测试结果验证了该算法的可行性，可以有效提高异常用户识别准确度，为保障12306铁路互联网售票系统的安全稳定运行及维护公平公正的售票环境提供了技术支持。

基于指数权重算法的铁路互联网售票异常用户智能识别的研究与实现

由于这两个文章都没有PDF原文，具体内容就不是很清楚来，这里也不多探究。

这两个基本都是17年左右的文章,这些功能大概率已经上线了,所以....

更新完毕。

谢谢大家了。