码迷,mamicode.com
首页 > Web开发 > 详细

从12306说起 大型高并发网站架设

时间:2015-04-18 13:12:36      阅读:138      评论:0      收藏:0      [点我收藏+]

标签:

 【IT168 评论】2012年春节,铁道部推出12306网站,进行网络实名购票。每一个返乡人原以为不用再忍冻排队,就能买着一张回家的火车票,但结果还是大失所望。7天内,12306网站访问用户已占全球互联网用户的0.902%,每天点击量高达10亿人次;系统一度支撑不住如此庞大的访问量而陷入崩溃。针对12306的责难也不绝于耳。


  面对12306,人们发表种种猜想,究竟是哪里有问题引起了大家的兴趣,IT168也特意邀请了网站架构方面的专家-ITpub资深版主丁昊和腾讯架构平台部刘天斯,跟我们一起聊聊12306背后的故事。


  12306订票网站存在哪些需求特点和挑战?

  刘天斯:12306订票网站具有分时段、分区域、高并发等特点,如何确保在高峰时段正常提供服务是一个非常大的挑战,放眼春运期间网上订票系统,表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素,也不排除对流量预估不准确、架构设计不合理等情况。


  同样类似的电商性质,12306和淘宝、京东等一样吗?

  丁昊:其实这三者间基本没有什么可比性,12306购票系统更像是秒杀性质,但是要比淘宝、京东上的秒杀活动更强大,所需的处理能力也要比秒杀更多。


  面对同样经历过宕机事件的淘宝和京东,性质和12306网站崩溃一样吗?

  丁昊:TMall宕机更多的是准备不够充分,另外还可能是超出预计;京东的宕机则主要是自己的业务逻辑造成的;而12306则是两者的合集。


  面对如此不堪一击的12306,有何改进意见?

  刘天斯:个人认为更有价值是体现在数据分析上,如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等,这些数据对优化、改良现有架构非常有帮助。抛开宽带因素,以下是对12306平台系统架构的几点建议:


  一、前端优化

  具体参考:yahoo前端优化34条规则,针对12306平台,个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离,静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现,这对动态CDN加速是一个挑战,因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性,可以缓解刷票机给平台带来的压力。


  二、运用缓存

  缓存最大的好处是减少后端数据存储的I/O压力,从一个普通用户订票轨迹来看,查询读往往是入库写的好几倍,如何减少数据库的读I/O对提高平台的整体性能至关重要,比较流行的缓存技术有针对页面级和数据级,页面级缓存有varnish、squid等,如使用CDN,页面级的缓存可以不用考虑,重点将精力放在数据级的缓存规划上,技术方面可以用Nosql来实现,比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区,这样可以很好地提高缓存命中率,减少后端数据库的压力。


  三、代理层

  引入代理层的目的是拆分业务,目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测,不一定准确)来对外提供服务,比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等,只要其中一个功能模块出现堵塞,影响必定是全局性的。一个好的方法是优化、规范各业务URI,在代理层实现业务的划分,可用的技术有Haproxy、Nginx等,如将/otsweb/regitNote/映射到注册组WEB服务器,/otsweb/AppQuery/映射到查询组WEB服务器,/otsweb/Pay/映射到支付组WEB服务器等等,如此一来,当查询业务出现延时堵塞时不会影响到用户支付。


  四、数据库层

  之前接触过一些政府行业的业务,数据库服务器往往都使用一台高端的硬件,比如小型机,在互联网行业,尤其是类似于12306订票系统,这往往是最致命的,理由很简单,在大流量并发下处理能力再强的服务器也吐不出数据,因为受网络I/O、磁盘I/O、业务逻辑等方面的限制所以必须将数据打散,方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离,大部分数据库都支持这点,除此之外还建议使用分区模式,分区策略可以根据业务特点进行,按地域进行分区是一个好主意,因为每个区域都是一个大分区,还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。


  五、负载均衡层

  保障一个业务平台的高可用性,采用负载均衡策略必不可少,即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等,也有开源的LVS,看成本的投入来选择,此处不详细展开讨论。


  六、业务层

  此次12306网站瘫痪事件,业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口,与电话订票、代售点都是平级的,后端肯定还关联着很多复杂的业务系统,在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现),可以将网站业务平台剥离出来,当然,完全剥离也不太实际,至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比,因为大部分的用户都是提前一周以上就着手预定车票。


  一个大型的高并发高性能网站架构需要从哪些层面去考虑呢?

  丁昊:缓存、队列、锁机制、数据库分表、代码、灵活性、扩展性等等都是要考虑的因素,而且各因素之间相互联系、缺一不可。


  关于使用开源技术建设高并发网站,有什么样的看法?

  丁昊:拥抱开源,就等于拥抱了变化,这样才能更好的发展。开源软件可以读源码,可以修改源码,也可以增加功能,而且这些还是免费的。如果facebook,google这类网站都用收费的,估计也活不到今天了。对于构建大型高并发网站,主要的是看产品的设计,采用哪种开源软件其次,要能hold住使用的开源软件。


  云计算目前大热,使用云计算平台来搭建高并发网站可行吗?

  丁昊:可行,在业务不繁忙的时候甚至可以关掉一些服务器。但是,不足之处也有,目前国内并没有什么成熟的云平台能提供高可靠性,高性能的解决方案。


  针对数据库的问题,有人建议采用NoSQL技术解决,但也有人质疑NoSQL技术不成熟,并且在实现数据一致性方面存在问题,您怎么看?

  丁昊:NoSQL的技术其实是很成熟的,只是它刚刚被认知起来,另外大多的NoSQL都倾向于内存操作,所以可靠性降低了,以此来换取高性能。对于数据一致性问题,主要还是看业务的需求,是要求实时一致性还是最终一致性。互联网大多数产品都是最终一致性,对于交易系统大多数都是实时一致性,也不排除最终一致性(例如跨行转账)。


  虚拟化如何在大型高并发网站中应用?

  丁昊:虚拟化技术主要目的之一就是降低IT成本,但是随之而来性能也会降低。不过如果用作Web server,缓存服务器之类的倒是可以考虑。


从12306说起 大型高并发网站架设

标签:

原文地址:http://blog.csdn.net/sxhlovehmm/article/details/45111861

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!