高性能网站架构的思考 (转)

今天看到了一篇关于网站架构的文章,写的很好,改了改,添加了一些自己的想法:

对于大流量高并发的网站,首先考虑的都是如何用最少的资源处理最多的业务。一般来说,网站架构最初需要考虑三个方面:数据库瓶颈、代码执行效率和服务器端的配置。下面结合项目开发中经验总结一下。
        1. 合理设计与使用数据库
        对于数据库的瓶颈可以归纳为两点:如何设计高性能的数据库?如何使用设计出来的高性能数据库?
 
     
首先,设计数据库之初就应该预估可能产生的数据量和所能承受的压力:该分表的分表,该分区的分区,该建立索引的就建立针对类型的索引,该读写分离的就趁早
的做好数据库主从或者数据库集群。虽然大多数互联网公司都有专业的DBA,但是需求第一线的码农必须具有设计优秀数据库的能力。
       
其次,合理使用数据库,基础的概念已经老生常谈的内容:尽量少用或者不用JOIN、IN和GROUP
BY等查询和临时表、数据库端编程、配置my.cnf记录慢查询、增加查询内存等。关于JOIN查询,每次JOIN都是两个表数据量的乘积(笛卡尔积),
所以尽可能的在程序中处理。关于数据库段编程,我以前倒是经常在SQL
Server中写存储过程和触发器,不过在MySQL中除非迫不得已一般都不会使用这些自定义函数,因为数据库的压力已经很大了。不过类似淘宝那种特征量
对特征值的设计有时候是不可避免的使用多个JOIN查询的,这个就需要专业的DBA去从底层优化了。
        下面这个SQL语句是一个很典型的反面教程,8000条数据卡死了,要是有人当着我的面写这样的查询我就地干掉他:

[sql] view plain copy

  1. SELECT COUNT(*) FROM `dbkxdhk`.`shop_goods` AS g ,(SELECT goods_id, attr_valueAS cut FROM `dbkxdhk`.`shop_goods_attr` WHERE attr_id=2) AS cut,(SELECT goods_id, attr_value AS color FROM `dbkxdhk`.`shop_goods_attr` WHERE attr_id=3)AS color,(SELECT goods_id, attr_value AS symmetry FROM`dbkxdhk`.`shop_goods_attr` WHERE attr_id=6) AS symmetry,(SELECT goods_id, attr_value AS clarity FROM `dbkxdhk`.`shop_goods_attr` WHERE attr_id=4) ASclarity,(SELECT goods_id, attr_value AS polish FROM `dbkxdhk`.`shop_goods_attr`WHERE attr_id=5) AS polish,(SELECT goods_id, attr_value AS cert FROM`dbkxdhk`.`shop_goods_attr` WHERE attr_id=8) AS cert,(SELECT goods_id, attr_value AS carat FROM `dbkxdhk`.`shop_goods_attr` WHERE attr_id=1) AS carat,(SELECT goods_id, attr_value AS location FROM `dbkxdhk`.`shop_goods_attr` WHEREattr_id=62) AS location,(SELECT goods_id, attr_value AS certificate FROM`dbkxdhk`.`shop_goods_attr` WHERE attr_id=8) AS certificate WHERE g.goods_id = cut.goods_id AND g.goods_id = color.goods_id AND g.goods_id = symmetry.goods_idAND g.goods_id = clarity.goods_id AND g.goods_id = polish.goods_id ANDg.goods_id = cert.goods_id AND g.goods_id = carat.goods_id AND g.goods_id = location.goods_id AND g.goods_id = certificate.goods_id AND g.is_on_sale = 1 ANDg.cat_id=1 AND g.is_alone_sale = 1 AND g.is_delete = 0 AND g.cat_id IN(‘1‘,‘2‘,‘7‘,‘9‘,‘8‘)

最后,关于数据库缓存,现在一般都使用Memcache,PHP等语言也已经对Memcache提供了足够多的支持。此外也可以优化下数据库自身的缓存设
置,例如增加查询内存等。而Key-Value的NoSQL的火爆能否完全解决关系型数据库的瓶颈这个我也没有实际的经验,我只能说在某些领域内或许
NoSQL可以帮助我们更好的使用关系型数据库。
        2. 代码效率 - 细节决定成败
        一个最基础的例子,PHP中单引号和双引号的区别。我开始写PHP的时候基本上都用双引号,因为这样在字符串中我可以直接填入变量,例如:

[php] view plain copy

  1. $sql = "SELECT * FROM test WHERE id=$id";
  2. $arr["key"] = $value;

不过,zend在编译PHP代码的时候,如果是双引号的字符串,会首先针对整个字符串进行一次扫描以判断这个字符串是否有需要被替换的变量存在,而单引号的字符串则不会存在这个问题,所以说单引号字符串的执行效率是要高于双引号字符串的。

[php] view plain copy

  1. $sql = ‘SELECT * FROM test WHERE id=‘.$id;
  2. $arr[‘key‘] = $value;

不要觉的这样的写法吹毛求疵,如果一个系统庞大的一定地步,这样的效率损失的绝对要避免的。
        3. 选择最合适的服务
 
     
关于Apache和Nginx的争论从来没有少过,就像不同开发语言之间的争论一样。同样,作为一个从Apache学起的码农,我是比较青睐
Apache,在Ubuntu配置开发环境很方便,并且了解的Apache模块比较多,对Nginx了解的比较少。不过Nginx确实在处理静态文件上的
效率要高出很多,所以目前大部分项目均采用Apache的前提下,已经开始实施把css、js、图片等静态文件部署到Nginx服务器上,无法实现静态话
的程序比如一些API还是部署到Apache。
        4. 使用缓存或者CDN减少HTTP请求
       
一个HTTP请求要经历连接、请求、应答和关闭4个主要过程,数据包经过多个层次的网络协议,所以减少HTTP请求是可以有效的降低服务器压力的。一般来
说,网页中最消耗流量的图片甚至是js和css都可以尽可能的缓存到用户的浏览器,这样不仅仅是可以提高再次访问的速度。如果经济能力允许,最好的缓存到
CDN。
        5. 合并压缩静态文件
       
可以使用雅虎的Yslow去页面分析,將Css中用到的图片尽可能的合并为一张大图,同理,也不要使用过多的Css和Javascript文件,能合并的
合并,能压缩的压缩。然后跳回上一步中执行缓存或者CDN即可。然后,页面内容可以采用Apache的gzip模块进行压缩,文字内容的压缩比例是非常高
的。
        6. 页面静态化
       
静态化与否和SEO没有关系,不管是动态还是静态的页面,爬虫抓取到的内容是一样的,不一样的只有抓取的速度问题。同样访问者也一样,静态页面可以在一定
程度上提高加载速度,最重要的是可以强有力的缓解数据库的压力。以我这个博客为例,页面全部静态化,访问者唯一能够触发的就是页面访问次数的更改,其他时
候只有在页面内容发生改变,比如新增加了评论或者新修改了文章内容后才会重新读取数据库生成页面。
       
理论上来说大部分网站都是可以静态化的,不过静态化存在服务器IO这个很严重的瓶颈,所以现在大互联网公司采用缓存的方式较多,缓存+squid或者
varnish的方式除了数据库效率外和静态页面的加载速度确实基本上没差别的。当然还有很多应用是不能生成静态页面的,比如微博、SNS以及API等。
        上面的是我浅显的总结了一些高流量高并发网站的基础工作,可能存在不少适用范围较小的地方。不足和缺点请不吝赐教。

时间: 2024-10-06 09:54:38

高性能网站架构的思考 (转)的相关文章

高性能网站架构的思考

今天看到了一篇关于网站架构的文章,写的很好,改了改,添加了一些自己的想法: 对于大流量高并发的网站,首先考虑的都是如何用最少的资源处理最多的业务.一般来说,网站架构最初需要考虑三个方面:数据库瓶颈.代码执行效率和服务器端的配置.下面结合项目开发中经验总结一下.        1. 合理设计与使用数据库        对于数据库的瓶颈可以归纳为两点:如何设计高性能的数据库?如何使用设计出来的高性能数据库?        首先,设计数据库之初就应该预估可能产生的数据量和所能承受的压力:该分表的分表,

高性能网站架构设计之缓存篇(3)- Redis的配置

我们说Redis是一个强大的Key-Value存储系统,在前面我们已遇到了两个问题: 1.redis server 启动后,独占进程,能不能修改为后台服务呢? 2.redis server 服务是单线程的,而我的机器是多核的,能不能在同一台机器上开启多个实例更充分的利用 cpu 资源呢?但6379端口已经被前一个实例绑定,肯定会有冲突,那能不能修改默认端口呢? 答案是肯定的,redis 提供了灵活的配置方式,一种可以通过配置文件来配置,另一种你可以在运行时通过 config set 命令来修改配

高性能网站架构方案

高性能网站架构方案,本文谈了七点网站架构方案,用以优化网站响应时间,实现大型网站技术架构方案.无论是电子商务或者其他网站且可使用. 一.优化网站响应时间的架构方案: 网站能不能留的住用户,一方面是看内容,另一方面是看响应时间.通常有以下几个方式来降低网站响应时间: 1.减少HTTP请求.包括合并css和javascript.减少图片数量,比如利用css的偏移技术来在一个图片中选择不同的位置内容.利用浏览器的Cache功能,我们可以在头中声明是否被浏览器缓存. 2.动态内容静态化.比如永久生成HT

高性能网站架构设计之缓存篇(5)- Redis 集群(上)

集群技术是构建高性能网站架构的重要手段,试想在网站承受高并发访问压力的同时,还需要从海量数据中查询出满足条件的数据,并快速响应,我们必然想到的是将数据进行切片,把数据根据某种规则放入多个不同的服务器节点,来降低单节点服务器的压力. 上一篇我们讲到了 Redis 的主从复制技术,当实现了多节点的 master-slave 后,我们也可以把它叫做集群,但我们今天要讲的集群主要是利用切片技术来组建的集群. 集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点,这里我们需要一个规则或

高性能网站架构设计之缓存篇(1)- Redis C#客户端

一.什么 Redis REmote DIctionary Server,简称 Redis,是一个类似于Memcached的Key-Value存储系统.相比Memcached,它支持更丰富的数据结构,包括string(字符串).list(链表).set(集合).zset(sorted set --有序集合)和hash(哈希类型),并提供了数据持久化机制,在某些场景下,你完全可以把它当做非关系型数据库来使用.它是一个高性能的存储系统,能支持超过 100K+ 每秒的读写频率.同时还支持消息的发布/订阅

高性能网站架构设计之缓存篇(6)- Redis 集群(中)

昨天晚上钓鱼回来,大发神经,写了篇概括程序员生活现状的文章,没想到招来众多人的口诛笔伐,大有上升到政治层面的趋势. 我也许不会再发表任何冲击心灵的文章,我希望给大家带来更多的正能量,所以那篇文章已被我删除. 我的本意只是想让各位看过文章之后能冷静地思考自己的程序人生,不管是对是错,人都有选择的权力,走好自己的路. 我没有你们想象中那么悲观,我也在不懈的努力,哪怕一时的跌倒,我也要重新站起. 生活无时无刻不是压力,让我们背起行囊,迈出踏实的一步,走起! 我们继续我们的 redis 缓存之旅. 前一

高性能网站架构利器--redis必杀技

目录 1.redis简介 2.redis主从复制实现 3.sentinel集群管理工具实现redis的高可用性 4.redis cluster 4.1.redis cluster环境搭建 4.2.redis cluster增加节点 4.3.redis cluster删除节点 4.4.redis cluster主从手动切换 5.总结 1.redis简介 Redis是一个开源的使用ANSI C语言编写.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库,并提供多种语言的API.从201

大规模高性能网站架构设计思路整理

近期关注了一些主流高并发大型网站如:大众点评.携程.去哪儿等 整理实现思路如下: 一.第一步 1.js .CSS.图片 优化压缩 2.站点动静分离,将动态网站单独部署.静态网站单独部署 3.数据库读写分离,比如:高频率读写的表分离 4.数据库优化,分表.分库.索引等 二.负载均衡 1.软件负载均衡,如:lvs,ngnix等 2.硬件负载均衡,如:F5等 三.缓存 1.数据缓存,如:memcacahe 2.Varnish Cache 3.Squid 四: 1.CDN

高性能网站架构缓存——redis集群

相信你已经对redis有一定的了解,并能够安装上,进行简单的使用了,但是在咱们的实际应用中,使用redis肯定不会使用单机版,不光是redis不能使用单机版,其他的也不会使用,所以今天我们来说一下redis cluster的安装. 1.  Redis Cluster的架构图. (1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽. (2)节点的fail是通过集群中超过半数的节点检测失效时才生效. (3)客户端与redis节点直连,不需要中间proxy