浅谈千万级PV/IP
规模高性能高并发网站架构
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。
如果把来访用户比作来犯的"
敌人"
,我们一定要把他们挡在800
里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储)。
如:能缓存在用户电脑本地的,就不要让他去访问CDN
。 能缓存CDN
服务器上的,就不要让CDN
去访问源(静态服务器)了。能访问静态服务器的,就不要去访问动态服务器。以此类推:能不访问数据库和存储就一定不要去访问数据库和存储。
说起来很轻松,实际做起来却不容易,但只要稍加努力是可以做到的,Google
的日独立IP
过亿不也做到了么?我们这几千万的PV
站比起Google
不是小屋见大屋了。我们还是先从我们的小屋搭起吧!哈哈!下面内容的介绍起点是千万级别的PV
站,也可以支持亿级PV
的网站架构。
高性能高并发高可扩展网站架构访问的几个层次:
有人会问,我们老是说把用户对业务的访问往前推,到底怎么推啊?推到哪呢?下面,老男孩就为大家一一道来。
第一层:
首先在用户浏览器端,使用Apache
的mod_deflate
压缩传输,再比如:expires
功能、deflate
和expires
功能利用的好,就会大大提升用户体验效果及减少网站带宽,减少后端服务器的压力。当然,方法还有很多,这里不一一细谈了。
提示:有关压缩传输及expires
功能nginx/lighttpd
等软件同样也有。
第二层:
页面元素,如图片/js/css
等或静态数据html
,这个层面是网页缓存层,
比如CDN
(效果比公司自己部署squid/nginx
要好,他们更专业,价格低廉,比如快网/CC
等(价格80
元/M/
月甚至更低)而且覆盖的城市节点更多),自己架设squid/nginx cache
来做小型CDN
是次选(
超大规模的公司可能会考虑风险问题实行自建加购买服务结合)
,除非是为前端的CDN
提供数据源服务,以减轻后端我们的服务器数据及存储压力,而不是直接提供cache
服务给最终用户。taobao
的CDN
曾经因为一部分图片的次寸大而导致CDN
压力大的情况,甚至对图片尺寸大的来改小,以达到降低流量及带宽的作用。
提示:我们也可以自己架设一层cache
层,对我们购买的CDN
提供数据源服务,可用的软件有varnish/nginx/squid
等cache
,以减轻第三层静态数据层的压力。在这层的前端我们也可以架设DNS
服务器,来达到跨机房业务拓展及智能解析的目的。
第三层:
静态服务器层一般为图片服务器,视频服务器,静态HTML
服务器。这一层是前面缓存层和后面动态服务器层的连接纽带,大公司发布新闻等内容直接由发布人员分发到各cache
节点(sina,163
等都是如此),这和一般公司的业务可能不一样。所以,没法直接的参考模仿,比如人人的SNS
。
我们可以使用Q
队列方式实现异步的分发访问,同时把动态发布数据(数据库中的数据)静态化存储。即放到本层访问,或通过其他办法发布到各cache
节点,而不是直接让所有用户去访问数据库,不知道大家发现了没有,qq.com
门户的新闻评论多的有几十万条,如果所有用户一看新闻就加载所有评论,那数据库不挂才怪。他们的评论需要审核(美其名约,实际是异步的方式,而且,评论可能都是静态化的或类似的静态化或内存cache
的方式),这点可能就是需要51cto.com
这样站点学习的,你们打开51CTO
的一篇博文,就会发现下面的评论一直都显示出来了,也可能是分页的。不过,应该都是直接读库的,一旦访问量大,数据库压力大是必然。这里不是说51cto
网站不好,所有的网站都是从类似的程序架构开始发展的。CU也可能是如此。
提示:我们可以在静态数据层的前端自己架设一层cache
层,对我们购买的CDN
提供数据源服务,可用的软件有varnish/nginx/squid
等cache
。在这层的前端我们也可以架设DNS
服务器,来达到跨机房业务拓展及智能解析的目的。
第四层:
动态服务器层:php,java
等,只有透过了前面3
层后的访问请求才会到这个层,才可能会访问数据库及存储设备。经过前三层的访问过滤能到这层访问请求一般来说已非常少了,一般都是新发布的内容和新发布内容第一次浏览如;博文(包括微博等),BBS
帖子。
特别提示:此层可以在程序上多做文章,比如向下访问cache
层,memcache,memcachedb,tc,mysql,oracle
,在程序级别实现分布式访问,分布式读写分离,而程序级别分布式访问的每个db cache
节点,又可以是一组业务或者一组业务拆分开来的多台服务器的负载均衡。这样的架构会为后面的数据库和存储层大大的减少压力,那么这里呢,相当于指挥部的外层了。
第五层:
数据库cache
层,比如:memcache,memcachedb,tc
等等。
根据不同的业务需求,选择适合具体业务的数据库。对于memcache
、memcachedb ttserver
及相关nosql
数据库,可以在第四层通过程序来实现对本层实现分布式访问,每个分布式访问的节点都可能是一组负载均衡(数十台机器)。
第六层:
数据库层,一般的不是超大站点都会用mysql
主从结构,如:163,sina,kaixin
都是如此,程序层做分布式数据库读写分离,一主(或双主)多从的方式,访问大了,可以做级连的主从及环状的多主多从,然后,实现多组负载均衡,供前端的分布式程序调用,如果访问量在大,就需要拆业务了,比如:我再给某企业做兼职时,发现类似的51cto
的一个站点,把www
服务,blog
服务,bbs
服务都放一个服务器上,然后做主从。这种情况,当业务访问量大了,可以简单的把www,blog,bbs
服务分别各用一组服务器拆分开,这种方式运维都会的没啥难度。当然访问量在大了,可以继续针对某一个服务拆分如:www
库拆分,每个库做一组负载均衡,还可以对库里的表拆分。需要高可用可以通过drbd
等工具做成高可用方式。对于写大的,可以做主主或多主的MYSQL REP
方式,对于ORACLE
来说,来几组oracle DG
(1master
多salve
方式)就够了,11G
的DG
可以象mysql rep
一样,支持读写分离了。当然可选的方案还有,mysql cluster
和oracle
的RAC
,玩mysql cluster
和oracle RAC
要需要更好更多的硬件及部署后的大量维护成本,因此,要综合考虑,到这里访问量还很大,那就恭喜了,起码是几千万以上甚至上亿的PV
了。
象百度等巨型公司除了会采用常规的mysql
及oracle
数据库库外,会在性能要求更高的领域,大量的使用nosql
数据库,然后前端在加DNS
,负载均衡,分布式的读写分离,最后依然是拆业务,拆库,。。。逐步细化,然后每个点又可以是一组或多组机器。
特别提示:数据库层的硬件好坏也会决定访问量的多少,尤其是要考虑磁盘IO
的问题,大公司往往在性价比上做文章,比如核心业务采用硬件netapp/emc
及san
光纤架构,对于资源数据存储,如图片视频,会采用sas
或固态ssd
盘,如果数据超大,可以采取热点分取分存的方法:如:最常访问的10-20%
使用ssd
存储,中间的20-30%
采用sas
盘,最后的40-50%
可以采用廉价的sata
。
第七层:
千万级PV
的站如果设计的合理一些,1
,2
个NFS SERVER
就足够了。我所维护(兼职)或经历过的上千万PV
的用NFS
及普通服务器做存储的还有大把,多一些磁盘,如SAS 15K*6
的,或者用dell6850
,搞几组 NFS
存储,中小网站足够了。当然可以做成drbd+heartbeat+nfs+a/a
的方式。
如果能达到本文设计要求的,中等规模网站,后端的数据库及存储压力会非常小了。
象门户网站级别,如sina
等, 会采用硬件netapp/emc
等等硬件存储设备或是san
光纤同道,甚至
在性价比上做文章,比如核心业务采用硬件netapp/emc
及san
光纤架构,对于资源数据存储,如图片视频,会采用sas
或固态ssd
盘,如果数据超到,可以采取热点分取分存的方法:如:最常访问的10-20%
使用ssd
存储,中间的20-30%
采用sas
盘,最后的40-50%
可以采用廉价的sata
。
象百度等巨型公司会采用hadoop
等分布式的存储架构,前端在加上多层CACHE
及多及的负载均衡,同样会根据业务进行拆分,比如爬虫层存储,索引层存储,服务层存储。。。可以更细更细。。。为了应付压力,什么手段都用上了。
特殊业务,如人人,开心网,包括门户网站的评论,微博,大多都是异步的写入方式,即无论读写,并发访问数据库都是非常少量的。
以上1-7
层,如果都搭好了,这样漏网到第四层动态服务器层的访问,就不多了。一般的中等站点,绝对不会对数据库造成太大的压力。程序层的分布式访问是从千万及PV
向亿级PV
的发展,当然特殊的业务 还需要特殊架构,来合理利用数据库和存储。
分享到:
相关推荐
一例千万级pv高性能高并发网站架构图,包括CDN、全局负载均衡、本地负载均衡、内网DNS、集群、Hadoop集群、数据库集群、缓存集群、NOSQL集群等
计算PV、UV和IP的方法以及利用这些数据进行用户访问预估,对于优化高并发架构的性能也是至关重要的。 在扩展性方面,架构设计需要考虑如何通过分层的方式,将用户的请求尽可能地前移,减少对数据库和存储层的直接...
### 亿级PV网站架构的技术细节与套路 在构建能够支撑亿级页面访问量(PV)的大型网站架构过程中,需要关注多个方面的技术细节与实践经验。以下内容将围绕这一主题展开,详细介绍包括但不限于后端架构设计、服务治理...
7. **网络协议与TCP/IP**:在HTTP请求背后,是TCP/IP协议栈在工作。TCP负责数据的可靠传输,IP负责数据包的路由。了解这些基础网络知识有助于理解源码如何通过网络进行通信。 总之,这款ASP源码利用了网络编程原理...
此外,研究中也提到了如何通过PV/T系统来提高太阳能的总利用效率,这涉及到对复合抛物面聚光太阳能PV/T空气集热器的性能计算,以及对具有蛇形冷却通道的PV/T系统模型的分析。 研究者们认为,现有的文献中缺乏能给出...
在构建亿级PV的高并发网站时,性能优化是一项至关重要的任务。本资料主要涵盖了后端架构、前端优化、服务器配置优化等多个方面,旨在最大化网站的处理能力和用户体验。 首先,后端架构的优化包括负载均衡、动静分离...
2、亿级pv网站架构实战之性能压榨 3、做一名优秀的工程师入门篇 4、后端多元化之快速切入Java开发 5、如何在面试中脱颖而出 6、零基础构建自己的服务治理框架(上) 7、零基础构建自己的服务治理框架(下)
亿级PV(Page View)网站架构设计是针对高流量、大规模用户访问的网站进行的一种优化策略,旨在确保系统稳定、高效、可扩展性良好。以下是一些关键知识点: 1. **负载均衡**:在亿级PV的场景下,单台服务器无法承受...
### WEB2.0高并发高流量网站架构分析 #### 一、硬架构 **1. 机房的选择** 在选择机房时,需考虑的主要因素是目标用户群体的地理位置分布。例如,如果用户主要分布在南方,则可以选择电信机房;若用户主要位于北方...
Nginx: PV、UV、独立IP 做网站的都知道,平常经常要查询下网站PV、UV等网站的访问数据,当然如果网站做了CDN的话,nginx本地的日志就没什么意义了,下面就对nginx网站的日志访问数据做下统计; 概念: UV(Unique ...
标题中的“7.rar_HYBRID MPPT_PMSG wind_pv with grid _pv/wind_wind pv”揭示了我们讨论的主题是关于一个混合能源系统,该系统整合了风能和光伏(太阳能)发电,并且与电网连接。其中,MPPT代表最大功率点跟踪...
- 提升并发性能的方法:通过优化代码逻辑、数据库索引等方式提升单个服务器的处理能力。 2. **集群架构** - 定义:通过多台服务器组成集群,共同承担负载,提高系统的整体性能和可用性。 - 优势: - **性价比**...
屌丝程序员如何打造日PV百万的网站架构
教你搭建日PV千万级的网站集群架构-绝对的极品教程.zip 阿里P8架构师谈 苏宁六年企业IT架构的演进之路 大并发大型网站架构设计 大型网站架构演化 大型分布式网站架构技术总结 Nginx负载均衡4种策略
### WEB网站千万级访问架构演变之路 #### 一、引言 随着互联网技术的发展与普及,网站访问量呈现爆发式增长。为了应对这种变化,网站架构必须经历一系列的演变过程来适应不同规模的访问需求。从最初简单的单机模式...
Hybrid PV-wind generation shows higher availability as compared to PV or wind alone. For rural electrifications, researches are focused on hybrid power system which provides sustainable power. The ...
在互联网行业中,高并发是衡量系统性能的关键指标,特别是在大型互联网平台的设计中。高并发意味着系统需要具备同时处理大量请求的能力,确保用户在高峰期也能获得流畅的体验。本讲主要探讨了高并发业务架构设计的...
假设我们需要构建一个支持千万级PV的秒杀系统,以下是一些具体的实现思路和技术方案: - **前端页面**:使用静态资源和CDN加速技术,提高页面加载速度;同时可以通过JavaScript实现前端的秒杀倒计时功能,提高用户...
在构建一个能够处理百万级别页面视图(PV)的网站应用时,硬件需求、系统选择以及软件部署和架构规划是至关重要的。本文将详细阐述这些关键点,以确保网站的稳定性和可扩展性。 首先,我们需要了解服务器配置的需求...