百度技术总监谈12306高性能海量并发网站架构设计
12306全国火车票网上售票网站的情况大家都见到了，如果让你来设计该订票网站，你会如何设计才能应对如此大规模以及高并发的情况呢？以下是百度前技术总监邵辉给出的设计：
列车在线订票系统的业务逻辑比较简单，不用多说。可能的瓶颈有两个，一个是车次和剩余票量的查询，一个是下单。在设计软件架构之前，需要先研究产品需求、软硬件条件、网络环境以及关联系统的接口，但这些资料无从获得，所以只能做几点分析和假设，做为设计的前提条件。
1.2012年铁路春运是2.35亿人次，去程售票的那几天应该是订票的最高峰点，假设是3天内订出1.2亿张票，那么每天是4000万张。由于还有车站窗口、电话、代售点等渠道，所以每天通过网站售出的票应该小于4000万张，这里假设2000万张是由网站售出的。
2.如果2000万张票是在一天内均匀地订出，那么每秒钟大约是230张。中国排名前100位的网站应该都会超过这个事务量，不会有什么难题。问题是，订票网站是在一个固定时刻（早上6：00）开始放票，考虑一个极端的情况：早已守候在电脑前的2000万用户在准点开始按下按钮下单，并且都在1分钟时间内订到了票，那么系统需要每秒33万的事务处理能力，这至少需要上千台服务器的集群才能按时处理完。（按照网上有关12306建设资金的报道来看，服务器投入肯定远远不到这个数。）实际情况当然不会这么极端，但必须保证整个系统有非常好的横向扩展能力，以便在必要的时候添加设备扩展服务能力。车站窗口、代售点和电话售票之所以不会产生这样的峰值，原因是这些渠道都是有人工受理，效率足够低，低到用户需要排几个小时的队来等候，自然就把峰值给抹平了。
3.前面还不是最大的问题。铁道部应该还有个核心数据库，保存最权威的票务数据，网络订票系统、电话订票系统和代售点必须与这个数据库对接以提交订单记录和获得准确的车票余量信息。至于这个接口有多少条连接，每秒允许多少次事务，那就不得而知了。这里我们假定接口要么足够宽，宽到不会成为瓶颈，要么在事先已有固定数量的车票分配给了网络订票系统，这样网络订票系统就可以根据这个固定数量自主地接受订单，然后在后台慢慢地把订单数据传给核心数据库。否则，就好像8车道的马路一下变成了2车道，无论如何也不可能让用户畅通无阻地订到票。
有了上面的分析和假设，可以考虑以下设计方案：
- 车次和剩余票量的查询。考虑到车次查询量可能是订单数量的数倍至数十倍，不能让用户提交查询请求时直接去主数据库检索数据，而应该采用前端+缓存+检索+数据库的多层逻辑结构。数据库存放持久化的权威数据并保证数据的一致性；缓存层负责把车次、余量等数据放到内存中以保证最好的查询性能，并有比较好的横向扩展性；检索机负责定时（例如每5秒一次）去数据库检索所有车次信息并主动更新缓存机上的数据；前端负责响应来自用户的web请求。这个架构无法保证用户看到的车票余量是实时准确的（比如有数秒的滞后），但由于用户从看到车票余量到完成订单之间肯定是有时间间隔的，在订票高峰期和票量较少时本来就无法保证“在看到有票的情况下一定能订到票”（技术上能够实现这一点，但代价非常大），所以这个缺陷并不明显，是个很划得来的折中。注意是检索机负责将车票数据抓出来并更新到缓存机上，这是保护数据库并使缓存层能够线性扩展的关键方法。另外查询页面需要采取防频繁刷新的措施，这个在前端机上设置web server策略即可。
- 下单部分由于要更新车票余量，必须保证数据的一致性，扩展性不可能很好，因此是整个系统中最为脆弱的一环。实现的方法分同步处理和异步处理两种。同步处理就是用户选择完车次正式下单订票后，立即锁住车票记录并检查车票真实余量，如果大于1，那么余量减1，解除锁定并回复用户订票成功进入支付流程，否则解除锁定回复订票失败请用户选择其它车次。这是订票系统的标准流程，无论用户量大还是小，处理流程都是一样的。为了支撑春运这种极端情况下的高访问量，需要提高订单处理的并发吞吐量和单个事务的处理速度。提高吞吐量可以将不同车次的车票数据分拆到不同的物理服务器上，提高订单处理速度可以考虑取消关系数据库，将车次数据放到内存中并用原生语言实现订单处理逻辑。有一个比较值得考虑的措施是在用户下单前用图片或者短信的方式要求用户二次验证，这既可以防止刷页面，也可以使峰值变得更平缓。异步处理就是在用户提交订单时并不立即告诉用户订票成功或者失败，只是将订票请求放入队列里排队，订单成功处理后再通知用户。处理优先级上采用时间排序或者抽签都可以，不过抽签适合在非常时期采用，并不适合作为一个标准策略，这多少增加了系统开发的复杂度。采用异步的方式将会在最大程度上避免用户下单高峰造成的冲击，缺点是用户不知道什么时候能有结果，是否应该尝试其它车次，这对用户体验有一定程度的损伤。
- 硬件架构方面，负载均衡设备是必须采用的，除了扩展负载能力，也需要扛住DoS攻击。服务器用普通PC服务器就可以了。网络架构方面，内网应该设计成无阻塞的，外网引入三大运营商的BGP带宽，不要用静态带宽。
最后说一句，几千万用户同时下订单，即使是三大互联网巨头的系统，也不一定撑得住，12306网站崩溃并不算太丢人，但需要好好考虑架构优化方案，明年春运不能再倒了
百度技术总监谈12306高性能海量并发网站架构设计相关推荐
- 从12306看海量并发网站架构
TUP第19期综述:从12306看海量并发网站架构(含PPT下载) 发表于2012-02-20 20:27| 19643次阅读| 来源CSDN专稿| 28 条评论| 作者付江 高并发产品设计新浪微博t ...
- TUP第19期综述：从12306看海量并发网站架构
摘要:2月18日CSDN和<程序员>杂志举办了 CSDN TUP技术沙龙 第19期:大数据系列研讨会之从12306谈起.本次活动分上下午两部分组成,上午是小规模专家研讨会,下午是开放式的主 ...
- 浅谈千万级PV/IP规模高性能高并发网站架构
原创作者:老男孩linux实战运维培训机构 老男孩 QQ:31333741 说明:几个月前老男孩发过一次类似的文章,本次为了参加一个朋友邀请的活动,稍微完善了一下,欢迎各位同仁一起交流网站架构技 ...
- 浅谈千万级PV/IP规模高性能高并发网站架构（转自老男孩）
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://oldboy.blog.51cto.com/2561410/736710 如果把来 ...
- 浅谈千万级高性能高并发网站架构
浅谈千万级PV/IP规模高性能高并发网站架构 高并发访问的核心原则其实就一句话"把所有的用户访问请求都尽量往前推". 如果把来访用户比作来犯的"敌人",我们一定 ...
- 千万级PV规模高性能高并发网站架构详解
1.缓存(expires) 2.deflate压缩 3.Apache/nginx静态服务器提供html页面内容 4.CDN/cache缓存静态内容如:html.jpg.gif.js等 5.MYSQL数 ...
- 《浅谈12306核心模型设计思路和架构设计》阅读有感
<浅谈12306核心模型设计思路和架构设计>阅读有感 12306的业务复杂度远远比淘宝天猫这种电商网站要复杂.一般的电商网站,购买都是基于商品的概念,每个商品有一定量的库存,用户的购买行为 ...
- 微信技术总监讲大数据高并发系统架构
微信--腾讯战略级产品,创造移动互联网增速记录,10个月5000万手机用户,433天之内完成用户数从零到一亿的增长过程,千万级用户同时在线,摇一摇每天次数过亿--在技术架构上,微信是如何做到的?日前, ...
- 惊！一个千万级 PV 规模高性能高并发网站架构
作者:一盏烛光,贤牛特邀工程师. 成为[贤牛]工程师,按需运维,灵活用工,让运维工程师多赚一些零花钱,多一些企业级运维经验. 客户端:缓存(expires).deflate 压缩 缓存服务器:CDN/ ...
最新文章
- DNA甲基化与表观遗传学数据挖掘与分析学习会 （10月26-27 上海）
- Ansible — 示例与最佳实践
- 程序员十大安全技巧（转）
- 解决input输入框在iOS中有阴影问题
- linux物理内存地址与iomem,一种Linux系统物理内存镜像文件分析方法_4
- php中metadata,模型元数据（Models Metadata）
- 德利捷读码器设置软件_S7-1500PLC+变频器+编码器组成位置控制系统
- python 写入文件编码_使用Python写入文本文件时的编码问题
- UIBarButtonSystemItem 样式
- my.ini修改后服务无法启动_教你发布vue+.netCore项目到服务器
- 记录CodeForces第一次比赛经历
- python编写登录接口_Python之编写登录接口
- 假如我们等不到对的人，就趁孤单让自己优秀起来。单身是最好的升值期
- 教你快速使用VSCode编写HTML文件
- 善待自己 改变命运的N个人生哲理
- vs 设置起始页不见了_VS2015，为什么模板不见了，请教
- 相机计算坐标公式_相机位姿估计3：根据两幅图像的位姿估计结果求某点的世界坐标...
- 扫地机器人漫谈（一）：扫地机的形状
- 2016年最受注目的网络技术关键词预测
- ResNet中残差块的理解（附代码）