免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖

千万级pv高性能高并发网站架构与设计交流探讨帖 活动结束 获奖名单公布 [复制链接]

论坛徽章:
6
丑牛
日期:2013-09-17 00:18:40未羊
日期:2013-10-31 12:10:47午马
日期:2013-12-07 01:58:50水瓶座
日期:2013-12-24 22:43:12水瓶座
日期:2014-03-15 21:12:13操作系统版块每日发帖之星
日期:2016-08-07 06:20:00
发表于 2011-12-06 15:42 |显示全部楼层
目前网站架构一般分成负载均衡层、WEB层和数据库层,我其实一般还会多加一层,即文件服务器层,这样我们在后面的讨论过程中,我们可以依次对这四层进行讨论;这里为了更具有说服力,我将用我现在维护的电子商务网站(并发最大值2000,日PV500万左右)

首先说下负载均衡层,我们熟悉的硬件/软件技术有F5/LVS、HAProxy,还有Nginx,它们的性能都是非常优异的,且不说F5的抗并发能力,LVS现在在全世界范围内的应用,而且淘宝现在升级架构,也将LVS取代了F5,HAProxy可能大家不是特别熟悉,但它确实在生产环境下表现优异,强大的吞吐能力,稳定性比之硬件过尤不及,再说下Nginx,我是将Nginx/HAProxy+Keepalived架构用于了各种生产环境中的,经过长时间的线上观察,发现Nginx/HAProxy作为负载均衡器/反向代理也很稳定,就算并发压力过大,我们前面可以用F5/LVS来顶,而将 Nginx作为中层代理,这样的效果其实也不差,所以负载均衡层的压力不能算是特别大。

WEB层这块压力比较大的网站现在都换成了Nginx作为WEB应用服务器,事实上,它的抗并发能力确实超过了预期;我朋友维护的一家门户网站,高峰期时某台Nginx应用服务器的并发达到了一万以上,但Nginx也很负责和稳定的提供服务,在实际的生产环境中,如果我们考虑到后端的数据库服务时,一万并发应该也算是一个比较大的数值了;另外,Linux集群有一个优势,就是它的高扩展性,就算我们的网站的并发有一万以上,我们后端的WEB服务是 Apache,我们多加几台Apache服务器即可,在实际的线上维护时,我们发现,高峰期间,实际上每台WEB的并发并不算是特别大,所以网站的压力在这一层我们也能通过技术手段加以克服。

再说下文件服务器层,由于网站的后期宣传策话,名气也越来越大,PV值也越来越高,原先的DRBD+Heartbeat+NFS(这个其实也只是单 NFS,只不过我们利用DRBD来保证NFS的高可用而已)已经越来越顶不住压力了,这个时候我们想到了分布式文件系统,我测试的的是MooseFS,在内网测试了很长时间还是没敢用到生产环境下面,googel的分布式文件系统还是很成熟的,推荐大家学习;最后还是用采用以前的CDN传统的方法解决这个问题,即用了squid反向代理加速器来解决小文件过多的问题,Nginx强大的正则处理分发能力,也让后端的NFS压力变得很小;另外,我还用采用域名的分散策略例如使用pics.xxx.com/pdf.xxx.com...来区分标记为a或b的一系列文件,这些文件存储的时候,依然按照标记,存到 pics或pdf的服务器上。这个策略将区分机器的任务交由dns服务器来执行,扩容时会相应轻松。这需要web项目初期就规划好这些东东,后期才转用域名策略的成本比较高甚至不可以实现,大家可以注意下,其实这一层如果网站是专业的图片服务器网站时压力还是很大的,我们需要在这个上面投入足够多的硬件资源。

最后说下数据库层的压力,我觉得网站的PV和并发上去以后,数据库这块的压力是最大的,CDN大型广告网站我们用的是oracle RAC方案,它保证了数据的高可用性,当然了价格也是非常昂贵的(如果使用高配置的PC服务器,Oracle一般按照CPU个数收费);那么免费的 MySQL数据库,面对这种并发压力大的情况,又用哪些方法呢?首先,我们说下传统的MySQL主从方案,配置简单,单机MySQL优化做好事性能也不弱,如果这种架构解决不了数据库的压力情况,我们可以考虑以下几种方案:

常规复制架构--Master-slaves,是由一个Master复制到一个或多个Salve的架构模式,主要用于读压力大的应用数据库端廉价扩展解决方案,读写分离,Master主要负责写方面的压力。级联复制架构,即Master-Slaves-Slaves,这个也是为了防止Slaves的读压力过大,而配置一层二级 Slaves,很容易解决Master端因为附属slave太多而成为瓶劲的风险。

Dual Master与级联复制结合架构,即Master-Master-Slaves,最大的好处是既可以避免主Master的写操作受到Slave集群的复制带来的影响,而且保证了主Master的单点故障。

MySQL的数据库切分,我们可以通过数据切恰好技术将一个大的MySQL Server切分成多个小的MySQL Server,既解了写入性能瓶颈问题,同时也一次提升了整个数据库集群的扩展性,从而解决了数据库压力过大的问题,这个现在也是我在生产环境中比较推荐的做法之一。

事实上我也跟许多系统维护人员和MySQL DBA线下交流过,现在生产环境下用得比较多的MySQL架构有:一、MySQL一主一从(这个优化得好,百多万PV的网站完全没问题);二、 DRBD+Heartbeat+MySQL(MySQL官方推荐);三、MySQL一主多从,读写分离,LVS或HAProxy作读的LB。

最后说明一点的是:前端缓存可以租别人的CDN或自己搭建squid或nginx服务器来实现,这个看自己的实际需求了。

论坛徽章:
6
丑牛
日期:2013-09-17 00:18:40未羊
日期:2013-10-31 12:10:47午马
日期:2013-12-07 01:58:50水瓶座
日期:2013-12-24 22:43:12水瓶座
日期:2014-03-15 21:12:13操作系统版块每日发帖之星
日期:2016-08-07 06:20:00
发表于 2011-12-06 15:43 |显示全部楼层
前端缓存----LVS---nginx中层代理---应用服务器---数据库缓存---数据库
arezone 发表于 2011-12-06 15:38


恩,确实是如此;或者直接可以用HAProxy+Keepalived来代替LVS+Nginx的功能,HAProxy能顶上亿的并发的,刘鑫兄,对吧,你应该最清楚了,呵呵。

论坛徽章:
0
发表于 2011-12-06 15:46 |显示全部楼层
书 我已经买了

论坛徽章:
6
丑牛
日期:2013-09-17 00:18:40未羊
日期:2013-10-31 12:10:47午马
日期:2013-12-07 01:58:50水瓶座
日期:2013-12-24 22:43:12水瓶座
日期:2014-03-15 21:12:13操作系统版块每日发帖之星
日期:2016-08-07 06:20:00
发表于 2011-12-06 15:52 |显示全部楼层
书 我已经买了
taojie2000 发表于 2011-12-06 15:46


谢谢支持和关注

论坛徽章:
0
发表于 2011-12-06 15:53 |显示全部楼层
能不能说的细致点啊,我想好好学些下这写内容,对于老男孩我是早有耳闻。能不能告诉我们更细致的资料啊
淘气kk 发表于 2011-12-06 15:00



    谢谢啊,能谈到架构 就是另一个层次了,很难面面俱到了。多关注大家发的帖子吧。等有机会CU组织沙龙啥的,我可以和大家分享下我的实践心得。

论坛徽章:
0
发表于 2011-12-06 15:57 |显示全部楼层
个人认为,不能单以每日pv衡量系统架构,统计每日的峰值点、峰值时段、峰值数据也是必要的,我们是做在线数据服务的,深有体会。
另外,有很多想说的,但这里高手如云,实在不敢献丑,抱着谦恭之心,虚心求教了。
向战斗在运维一线的英雄们致以崇高的敬意!!!

论坛徽章:
6
丑牛
日期:2013-09-17 00:18:40未羊
日期:2013-10-31 12:10:47午马
日期:2013-12-07 01:58:50水瓶座
日期:2013-12-24 22:43:12水瓶座
日期:2014-03-15 21:12:13操作系统版块每日发帖之星
日期:2016-08-07 06:20:00
发表于 2011-12-06 16:00 |显示全部楼层
个人认为,不能单以每日pv衡量系统架构,统计每日的峰值点、峰值时段、峰值数据也是必要的,我们是做在线数 ...
bailongshi 发表于 2011-12-06 15:57


恩,我比较关注的几个方面,PV、UV和并发,基本每天都在做这些统计和监控工作

论坛徽章:
0
发表于 2011-12-06 16:02 |显示全部楼层
实际上是这样的一个问题 ,运维的高端技术能够完全运用自如的技术专家毕竟是少数,而很入门或者运 ...
kns1024wh 发表于 2011-12-06 15:16



在放一个大众的系统架构麻雀图:

论坛徽章:
0
发表于 2011-12-06 16:08 |显示全部楼层
千万级pv的系统架构是一个庞大的架构,涉及到的技术还是很多的,我觉得应该分层进行讨论,一层层的深入,如 ...
king_819 发表于 2011-12-06 15:33



    从机房选择开始。。。你这不光是是系统架构了。呵呵。我的意思主要讨论一些常规业务的高并发的应用 如 BBS,BLOG,SNS,及普通的浏览的站的高并发架构的设计的内容。
机房选择-硬件选择-CDN选择 这些需要以后单开帖讨论了。

论坛徽章:
6
CU大牛徽章
日期:2013-04-17 10:59:39CU大牛徽章
日期:2013-04-17 11:01:45CU大牛徽章
日期:2013-04-17 11:02:15CU大牛徽章
日期:2013-04-17 11:02:36CU大牛徽章
日期:2013-04-17 11:02:582015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2011-12-06 16:08 |显示全部楼层
前来学习,最近搞数据库缓存搞的头大
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。




----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP