1、如何使用Varnish来加速网站访问
第一种方法，利用缓存插件。越来越多的站长构架网站已经不再自己写程序，而是使用比较完善的现成CMS作为框架结构，比如用到WORDPRESS。网上提供的一些常用CMS功能是非常完美的，但需要单独再设置才能够更加完美的适合我们的网站，提高网站速度。这就需要使用缓存插件来实现。比如WP-
Supercache，W3-TotalCache这两款插件是我们必须安装的缓存插件，可以有效的提高网站速度。
第二种方法，使用CDN加速。近一年CDN已经在我们个人站长中听的较多，也有很多朋友在使用。CDN的全称是Content Delivery
Network，解释为内容分发网络。原理思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。也就是网站加速器，这个需要付费使用的，免费的不是太稳定。
第三种方法，优化代码，减少臃肿结构。如果我们使用较为流行的CMS这方便应该不会有臃肿的代码结构存在，但需要注意的是我们在制作或者选择网站模
板的时候也会存在不合理的结构。我们需要在写模板或者程序的时候使用较为简洁的程序框架，简洁有利于用户体验，也更利于搜索引擎蜘蛛的爬行和抓取。
第四种方法，删除相关插件。有些站长在构架网站的时候喜欢用很多插件实现特别的效果，我们要知道自己制作的网站的目的是为了让搜索引擎更加优化，抓
取更多的页面获得更好的排名效果。而不是采用多么绚丽的效果。插件过多，也会影响我们网站的访问速度和数据库的读取速度。插件尽量控制在4个之内。能不用插件的就不要用插件实现。
第五种方法，减少社会化标签按钮的数量。WEB2.0网站越来越多，我们为了把自己的网站也融入到2.0系统中会在自己的网站加入更多的社会化网站
按钮。但是由于这些数据都是远程调用的，加载需要很长的时间，从而减慢了我们网站的访问速度。我个人建议大家不要加入社会化书签，如果要加入也要加入那些
加载速度快的网站平台。
第六种方法，拒绝加载额外的评论系统。最近我也看到很多提供第三方评论的网站平台，可以提供评论服务，看似不错可以减少我们网站的数据量和垃圾评
论，但是我们也可以看到加载后速度慢了很多。如果对方的速度还可以，都没有太大问题，如果速度慢，那就影响很大。所以，我建议，不要加入第三方平台。
第七种方法，禁止Gravatar头像。Gravatar头像加载也比较浪费资源，我们没有必要加载Gravatar头像，虽然好看一些，但没有必要。可能在网站流量小，评论少看不出来影响效果，如果评论多会明显感觉到速度很慢。
第八种方法，减少图片大小和数量。我们尽量在上传网站图片的时候减少图片的大小和尺寸，可以在上传图片之前对图片进行压缩处理，图片适当尺码即可，不要过大。图片仅仅是网站的点缀，而不需要都是图文。同时，我们也尽量避免使用大量的视频或者音频内容。
第九种方法，开启GZip压缩功能。一般的主机都支持GZip压缩功能。我们需要利用好主机提供给我们的功能，开启压缩可以提高网站的访问速度，一般主机都是免费提供的，但很多人都没有开启。
第十种方法，减少JavaScript脚本文件，尽量存放在一个文件中。尽量外部调用JS代码，不要放在网页中，更不要远程调用外部的JS代码。例
如Google建议您加载在HEAD标签的分析。您也可以尝试结合的JavaScript和压缩他们更快地加载。有些时候我们在头部的CSS，JS代码太
多，导致中间内容部分加载太慢。所以尽量减少头部的代码。
2、varnish 最大并发可以到多少
-p 后跟参数为了进行优化 -w 最小最大线程和超时
http://linux.chinaunix.net/techdoc/net/2007/09/06/967227.shtml
cu论坛里有
3、varnish 内存最大设置多大
varnish 内存最大设置2G。
Varnish是一个轻量级的Cache和反向代理软件，先进的设计理念和成熟的设计框架是Varnish的主要特点，现在的Varnish总共代码量不大，功能上虽然在不断改进，但是还需要继续丰富和加强。下面总结了Varnish的一些特点：
（1）是基于内存缓存，重启后数据将消失。
（2）利用虚拟内存方式，io性能好。
（3）支持设置0~60秒内的精确缓存时间。
（4）VCL配置管理比较灵活。
（5）32位机器上缓存文件大小为最大2G。
（6）具有强大的管理功能，例如top，stat，admin，list等。
（7）状态机设计巧妙，结构清晰。
（8）利用二叉堆管理缓存文件，达到积极删除目的。
Varnish的Storage方式可分为两种：
1）Malloc 通过malloc获取内存。
2）Mmap file 创建大文件，通过二分法分段映射成1G以内的大块。
Varnish进程的工作模式：
varnish启动或有2个进程 master(management)进程和child(worker)进程。master读入存储配置命令，进行初始化，然后fork，监控child。child则分配线程进行cache工作，child还会做管理线程和生成很多worker线程。
child进程主线程初始化过程中，将存储大文件整个加载到内存中，如果该文件超出系统的虚拟内存，则会减少原来配置mmap大小，然后继续加载，这时候创建并初始化空闲存储结构体，放在存储管理的struct中，等待分配。
接着varnish某个负责接口新http连接的线程开始等待用户，如果有新的http连接，但是这个线程只负责接收，然后唤醒等待线程池中的work线程，进行请求处理。
worker线程读入uri后，将会查找已有的object，命中直接返回，没有命中，则会从后端服务器中取出来，放到缓存中。如果缓存已满，会根据LRU算法，释放旧的object。对于释放缓存，有一个超时线程会检测缓存中所有object的生命周期，如果缓存过期（ttl），则删除，释放相应的存储内存。
4、LINUX平台上怎么安装varnish
安装Varnish网站缓存加速器（Linux系统）：
1、创建www用户和组，及Varnish缓存文件存放目录（/var/vcache）：
/usr/sbin/groupadd
www -g 48
/usr/sbin/useradd -u 48 -g www www
mkdir -p /var/vcache
chmod
+w /var/vcache
chown -R www:www
/var/vcache
2、创建Varnish日志目录（/var/logs/）：
mkdir
-p /var/logs
chmod +w /var/logs
chown -R www:www
/var/logs
3、编译安装varnish：
wget
warnish官网下载
tar
zxvf varnish-1.1.2.tar.gz
cd varnish-1.1.2
./configure
--prefix=/usr/local/varnish
make && make
install
4、创建Varnish配置文件：
vi
/usr/local/varnish/vcl.conf
输入以下内容：
引用
backend myblogserver {
set backend.host =
"192.168.0.5";
set backend.port = "80";
}
acl purge {
"localhost";
"127.0.0.1";
"192.168.1.0"/24;
}
sub vcl_recv {
if (req.request ==
"PURGE") {
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
lookup;
}
if (req.http.host ~ "^blog.s135.com") {
set
req.backend = myblogserver;
if (req.request != "GET"
&& req.request != "HEAD") {
pipe;
}
else {
lookup;
}
}
else {
error 404 "Zhang Yan Cache
Server";
lookup;
}
}
sub vcl_hit {
if (req.request == "PURGE") {
set obj.ttl = 0s;
error 200 "Purged.";
}
}
sub vcl_miss {
if
(req.request == "PURGE") {
error 404 "Not in cache.";
}
}
sub vcl_fetch {
if (req.request == "GET" &&
req.url ~ "\.(txt|js)$") {
set obj.ttl = 3600s;
}
else {
set obj.ttl = 30d;
}
}
即(1)、Varnish通过反向代理请求后端IP为192.168.0.5，端口为80的web服务器；
(2)、Varnish允许localhost、127.0.0.1、192.168.0.***三个来源IP通过PURGE方法清除缓存；
(3)、Varnish对域名为blog.s135.com的请求进行处理，非blog.s135.com域名的请求则返回“Zhang
Yan Cache
Server”；
(4)、Varnish对HTTP协议中的GET、HEAD请求进行缓存，对POST请求透过，让其直接访问后端Web服务器。之所以这样配置，是因为POST请求一般是发送数据给服务器的，需要服务器接收、处理，所以不缓存；
(5)、Varnish对以.txt和.js结尾的URL缓存时间设置1小时，对其他的URL缓存时间设置为30天。
5、启动Varnish
ulimit
-SHn 51200
/usr/local/varnish/sbin/varnishd -n /var/vcache -f
/usr/local/varnish/vcl.conf -a 0.0.0.0:80 -s
file,/var/vcache/varnish_cache.data,1G -g www -u www -w 30000,51200,10 -T
127.0.0.1:3500 -p
client_http11=on
6、启动varnishncsa用来将Varnish访问日志写入日志文件：
/usr/local/varnish/bin/varnishncsa
-n /var/vcache -w /var/logs/varnish.log
&
7、配置开机自动启动Varnish
vi
/etc/rc.local
在末尾增加以下内容：
引用
ulimit -SHn 51200
/usr/local/varnish/sbin/varnishd
-n /var/vcache -f /usr/local/varnish/vcl.conf -a 0.0.0.0:80 -s
file,/var/vcache/varnish_cache.data,1G -g www -u www -w 30000,51200,10 -T
127.0.0.1:3500 -p client_http11=on
/usr/local/varnish/bin/varnishncsa -n
/var/vcache -w /var/logs/youvideo.log
&
8、优化Linux内核参数
vi
/etc/sysctl.conf
在末尾增加以下内容：
引用
net.ipv4.tcp_fin_timeout =
30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_syncookies =
1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle =
1
net.ipv4.ip_local_port_range = 5000 65000
5、CloudFoundry何时可以支持绑定域名
[译注]本文翻译自CloudFoundry英文博客站点，原文题为“”，文章发表时间是2012年09月13日。使用云的价值主张是“一切因此而简单”。但构建和操作大规模的云却绝非易事。As正如MarkLucovsky在他的最新访谈中所言：“谁说大规模分布式系统简单？”尽管像CloudFoundry这样的解决方案使构建核心云技术不再那么令人生畏，但仍然不是件容易的事。在这篇嘉宾博文中，AppFog的创始人和CEOLucasCarlson讲述了如何使用CloudFoundry开源PaaS技术建立AppFog的历程以及在这一过程中的收获核心云技术高深莫测运行基于CloudFoundry的简单服务并不是难事。查看MicroCloudFoundryTM。构建一个适合生产和企业工作负荷的服务相当困难。要构建含有一个API端点的基于CloudFoundry的服务，该服务在4个以上的独立基础结构供应商的6个以上不同可用性区域中运行，适合于生产和企业工作负荷，具有一定规模和一般可用性？目前这真的很难。快马加鞭推行CloudFoundry正如您可以设想到的那样，自从AppFog宣布GA以来，人们一直在问我们怎样去做。我们是如何解决怎样将针对CloudFoundry提供、为跨多个云、多个可用区域以及多个供应商提供一个可共用界面的公共云扩大规模的？首先：CloudFoundry代码库确实很不错。由于选择使用CloudFoundry进行构建，我们不必面对此类项目可能出现的很多潜在严峻挑战和消耗大量时间的问题。其次：我们能够从CloudFoundry生态系统内的工具、代码和服务所获得的益处显著加快了我们的开发速度。第三：拥有GA中已经存在并具有一定规模而且并非基于CloudFoundry的公共PaaS是我们的一个重要促进因素。我们具有实现强大的PaaS所需要的内部操作经验。AppFog的操作经验对我们来说非常宝贵。尽管PaaS与NoOps趋势紧密结合，但NoOps并不意味着无操作，而只是对开发人员而言无操作。正如每一个曾运行过CloudFoundry的人员所知，很多操作对于运行PaaS都必不可少而且很重要。最为重要的是，我们拥有一个有成千上万的开发人员（PHPFog的用户）参与的充满活力的社区供我们咨询，在从内部测试版到公共测试版直至GA的过程中帮助我们定义、测试及改进AppFog。悉心倾听，交付所成正是这个社区帮助我们了解了AppFog的GA的发展目标、需要的工作方式以及我们的目标定价。开发人员对我们的要求如下：能够跨数十个或数百个负载平衡的实例上轻松扩展应用程序，甚至免费版也是如此必须在基础结构中最快的服务器上运行应用程序（例如M2.4XL）必须能够跨多个基础结构（Rackspace、HP、AWS、Azure，并且无价格差异）运行应用程序必须简化定价。没有稀奇古怪的打包和组合以及名称。简单而且价格合理，最重要的是公正。在云中实现真正的互操作性，包括运供应商之间的一键式零代码迁移，从而消除了所有供应商锁定痕迹目标是30秒部署到AWS、Rackspace、HP、Azure等等。支持CloudFoundry代码库中的任意及所有语言支持任意及所有关系数据存储和NoSQL数据存储这是一个令人生畏的列表。但这正是开发人员所需要的。因此让我们面对现实…我们事实上是如何做到的呢？如何围绕CloudFoundry构建PaaS这是个复杂的过程。幸运的是，几个月前，JeremyVoorhis在伦敦QCon做了一个报告，叙述了AppFog如何将CloudFoundryOSS位与我们自有的自定义扩展和增强功能集并用，来构建商用系统。这无疑是了解从CloudFoundry到AppFog的发展历程的最好开端。此报告的幻灯片位于此处，视频位于此处。在此，我们不逐一回顾Jeremy历时近一小时的讲话，但我们要讨论一些要点。首先，Jeremy澄清了一些关于“CloudFoundry”这一标志的混淆之处。一方面，CloudFoundry.com是VMware提供的托管PaaS，运行在vSphere虚拟平台上，该平台基于CloudFoundry.org中的开源项目。VMware还公开了其用来管理CloudFoundry.com-CloudFoundryBOSH-的工具的源代码，并公开了其托管服务生产环境中的BOSH版本。我们不在托管VMware服务上进行，而是从同一个开源CloudFoundry项目构建。这种分布式开源系统使团队能够在其生命周期内在云中管理及部署应用程序和服务，这是AppFog服务的核心。由于我们构建了一个基础结构不可知的CloudFoundry服务，因此AppFog在当前的CloudFoundry生态系统中是独一无二的。CloudFoundry的好处在于，基本上它可以与从基于OpenStack的IaaS（如Rackspace或HP）到AWS、Joyent、Citrix等等所提供的基础结构相结合来实现。这种固有的多云可移植性就是CloudFoundry项目如此鼓舞人心的原因所在。对于我们而言，在应用程序的生命周期内和多个基础结构间部署和重新部署的能力是构建下一代PaaS的关键。我们认为，它还可以实现PaaS的以下基本使命：(a)促进产品团队对开发的关注；(b)在应用程序生命周期内形成更短的反馈周期；(c)提供接近即时水平扩展性的可能性。CloudFoundry在云计算革新中的作用即使是对于通常而言精通云计算领域的人，回顾历史发展环境也非常重要。对我们AppFog人而言，CloudFoundry已提供了一些重要的构建基础来构成首个下一代PaaS。但是，这对我们有何意义？首先，了解一些背景信息很重要。PaaS最初是在一些历史性突破的基础上应运而生的，例如：20世纪90年代在Rackspace等公司出现数据中心。21世纪前十年的早期在VMware出现服务器虚拟化21世纪前十年的中期AWS在虚拟化资源中引入API最近出现的DevOps范例及其关联和派生的工具，例如Puppet和Chef。但只是在过去两年，这条发展路线才开始真正走向成熟。像CloudFoundry和OpenStack这样的工具已产生，并能够对整个应用程序生命周期进行管理。这意味着“平台即服务”中的“平台”现在可以包含开发之外的应用程序生命周期的所有方面。Jeremy在报告中将此称为“NoOps”。其含义绝非是再也无人去执行操作，而是操作工作的职责已传递到平台层，并且在应用程序生命周期的大部分时间（如果不是全部生命周期）会保留在该层。如果没有像CloudFoundry这样包罗万象的工具，我们永远也不能逾越第一代PaaS平台与下一代PaaS（如AppFog）之间的鸿沟，前者对于基础结构管理而言实质上与用于（难以控制的）基础结构管理的网关相比只是略有改进，而后者为用户带来的好处则要全面得多。AppFog对CloudFoundry的修正AppFog从为托管CloudFoundry生态系统提供强大的用户界面和多云体验入手开始工作。我们在CloudFoundry代码库和成型的PaaS产品之间遇到了许多障碍。尽管当前的Cloudfoundry.org项目集成了CLI和各种IDE，但我们还着眼于全面的用户体验，包括快速注册、Web控制台以及我们称为Jumpstart、附加组件等等的构建前示例应用程序。尽管一些CloudFoundry用户确实觉得从命令行、Eclipse或SpringToolSuite来操作系统（就像很多AppFog用户的做法一样）非常习惯，但我们还是希望为用户提供直观而又别具一格的控制台，用来管理他们的所有应用程序。下面是AppFog控制台的一个示例：系统创建者希望CloudFoundry对于事物的UX端处于一种不可知的状态，而且不希望使其UX实现过于武断。我们知道，简单和直观并不是最终目的，而在基于低于标准的基础系统生成简洁的UX是很容易的事情。但还有很多方面需要进行探寻，以满足尽可能多用户的需求，我们相信我们已经做到了这一点。以下是我们在CloudFoundry的顶层和下层所引入的一些创新举措：基于Varnish的缓存层，用于显著提高速度从一个基于CF的基础结构一键克隆到另一个基础结构，实现真正的工作负载可移植性CloudFoundryAPI兼容层，自动将请求路由到在空间的完全不同部分中运行的完全自治的CF实例跨数据中心的深度nagios集成，使我们在问题产生影响前就发现问题的存在此外，CloudFoundry使AppFog能够创建非常完整的自通信体系结构。无论是在基础结构级别还是其他级别，它还使我们能够将AppFog设计为一个假定故障发生的系统，并提供一组处理故障的规程。翻开CloudFoundry新的一页构建能够跨多个云的完全成熟的商用级别PaaS，并使其全部具有最高水准的最终用户体验，即使是从基本的CloudFoundry.org系统开始，也是一项宏大的事业。它需要一个极富开发人员敬业精神并全心投入的团队，一个愿意设身处地为客户着想的团队。但我们认为值得为这样的成果付出。我们非常幸运能够拥有像CloudFoundry这样的核心系统。我们以多种方式进行回报，包括为项目添加初始PHP运行时支持，并在优化CloudFoundry使其能够在公共云中良好运行的过程中不断进行回馈。对于AppFog转向GA，我们的激动之情难以言表。对于已经注册并开发了千千万万个应用程序的千千万万个开发人员，我们更是无比兴奋。我们认为，AppFog的成功不仅仅证明了PaaS的强大，还证明了CloudFoundry代码库的力度及其开源生态系统和社区的强大。这不仅仅是AppFog的胜利，更是为CloudFoundry的成功做出贡献的每一个人的胜利。关于作者：LucasCarlson是一位创业家和专业程序员，擅长开发具备一定规模的Web应用程序。Lucas是主要跨云PaaS公司AppFog的创始人和CEO。他撰写了十多个Ruby库，并为包括Rails和RedCloth在内的多个重要Rails产品做出了贡献。Lucas创立、主了广受欢迎的RubyonRails竞赛RailsDay并担任评委，一直是很多重要编程会议中广受欢迎的发言人。Lucas是MOG的第一位工程师，负责这一开创性音乐流服务的开发和技术指导。Lucas居住在俄勒冈州波特兰，喜爱统计学和Go。
6、nginx lvs haproxy哪个用的多
一、lvs的优势：
1、抗负载能力强，因为lvs工作方式的逻辑是非常之简单，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。
2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。
4、无流量，上面已经有所提及了。lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等。
另：lvs也不是完全能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以，用lvs也得多多当心为妙。
二、nginx和lvs作对比的结果
1、nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点 看，触碰多了，人为出问题的几率也就会大。
2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另 外注意，lvs需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。
3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，因为同上所述，lvs对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。
5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中 ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。
6、nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个nginx做apache代理的话，这些窄带链接会被nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。lvs没有这些功能，也就无法能 比较。
7、nginx能支持http和email（email的功能估计比较少人用），lvs所支持的应用在这点上会比nginx更多。
在使用上，一般最前端所采取的策略应是lvs，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。
重要的ip地址，最好交由lvs托管，比如数据库的ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。
nginx可作为lvs节点机器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所逊色于nginx。
nginx也可作为中层代理使用，这一层面nginx基本上无对手，唯一可以撼动nginx的就只有lighttpd了，不过lighttpd目前还没有 能做到nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和lvs是最完美的方案了。
nginx也可作为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。
具体的应用还得具体分析，如果是比较小的网站（日PV<1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。
****************************************************************************************************************
Nginx的优点:
性能好，可以负载超过1万的并发。
功能多，除了负载均衡，还能作Web服务器，而且可以通过Geo模块来实现流量分配。
社区活跃，第三方补丁和模块很多
支持gzip proxy
缺点:
不支持session保持。
对后端realserver的健康检查功能效果不好。而且只支持通过端口来检测，不支持通过url来检测。
nginx对big request header的支持不是很好，如果client_header_buffer_size设置的比较小，就会返回400bad request页面。
Haproxy的优点:
它的优点正好可以补充nginx的缺点。支持session保持，同时支持通过获取指定的url来检测后端服务器的状态。
支持tcp模式的负载均衡。比如可以给mysql的从服务器集群和邮件服务器做负载均衡。
缺点：
不支持虚拟主机(这个很傻啊)
目前没有nagios和cacti的性能监控模板
LVS的优点:
性能好，接近硬件设备的网络吞吐和连接负载能力。
LVS的DR模式，支持通过广域网进行负载均衡。这个其他任何负载均衡软件目前都不具备。
缺点：
比较重型。另外社区不如nginx活跃。
*************************************************************************************
现在网络中常见的的负载均衡主要分为两种：一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，也有类似于LVS、Nginx、HAproxy的基于Linux的开源的负载均衡策略,
商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来说，不过商用负载均衡由于可以建立在四~七层协议之上，因此适用 面更广所以有其不可替代性，他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用。
另一种负载均衡的方式是通过软件：比较常见的有LVS、Nginx、HAproxy等，其中LVS是建立在四层协议上面的，而另外Nginx和HAproxy是建立在七层协议之上的，下面分别介绍关于
LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS的特点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生；
2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
3、工作稳定，自身有完整的双机热备方案；
4、无流量，保证了均衡器IO的性能不会收到大流量的影响；
5、应用范围比较广，可以对所有应用做负载均衡；
6、LVS需要向IDC多申请一个IP来做Visual IP，因此需要一定的网络知识，所以对操作人的要求比较高。
Nginx的特点是：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；
2、Nginx对网络的依赖比较小；
3、Nginx安装和配置比较简单，测试起来比较方便；
4、也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；
5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载；
7、Nginx能支持http和Email，这样就在适用范围上面小很多；
8、不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。
HAProxy的特点是：
1、HAProxy是工作在网络7层之上。
2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。
4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6、HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
***********************************************************************************************
现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
第一阶段：利用Nginx或者HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是 仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。这时是第一选择
第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者 F5的节点来使用，具体LVS或者F5的是选择是根据公司规模，人才以及资金能力来选择的，这里也不做详谈，但是一般来说这阶段相关人才跟不上业务的提 升，所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。
最终形成比较理想的状态为：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。
7、HTTP是如何工作的？
什么是HTTP协议
HTTP 协议定义服务器端和客户端之间文件传输的沟通方式。目前HTTP协议的版本是Http1.1。RFC 2616描述了HTTP协议的具体信息。
这个协议已经成为浏览器和Web站点之间的标准。
当我上网的时候底层是如何进行交互的？
当访问者点击一个超链接的时候，将会给浏览器提交一个URL地址。通过这个URL地址，浏览器便知道去链接那个网站并去取得具体的页面文件（也可能是一张图片，一个pdf文件）。
HTTP工作的基础就是，连接一个服务器并开始传输文件到浏览器。
HTTP传输的基本过程
在http传输的过程中，被称为客户端的请求者向服务器请求一个文件。
最基本的过程是:
1 客户端连接一个主机；
2 服务器接收连接,
3 客户端请求一个文件,
4 服务器发送一个应答.
实例
我们看几个典型的过程
首先，我们想访问本页面。在浏览器上敲入“http://www.maketop.net/resource/rs_041112_02.php”.浏览器将连接www.maketop.net然后发送：
>> GET /resource/rs_041112_02.php Http1.1
>> Host: www.maketop.net
>> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> Accept-Language: en
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
>> Connection: Keep-Alive
>>
解释：浏览器请求页面“/resource/rs_041112_02.php”。并使用HTTP1.1协议。并告诉服务器你的浏览器是Firefox0.10。操作系统是Windows XP。 浏览器希望保持与www.maketop.net之间的连接，并请求获得多的文件，包括网页中的图片。翻译成语言上面是：
>> 用HTTP1.1协议获得 /resource/rs_041112_02.php
>> 访问的主机是: www.maketop.net
>> 接收的文件包括了: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> 使用的语言是: en
>> 接收的编码方式（浏览器能够解释的）是: gzip, deflate
>> 用户的浏览器信息:Windows XP的操作系统 Firefox/0.10的浏览器
>> 保持连接: 还要去图片
>>
www.maketop.net的服务器发出响应：
<< HTTP/1.1 200 OK
<< Date: Mon, 12 Mar 2004 19:12:16 GMT
<< Server: Apache/1.3.31 (Unix) mod_throttle/3.1.2
<< Last-Modified: Fri, 22 Sep 2004 14:16:18
<< ETag: "dd7b6e-d29-39cb69b2"
<< Accept-Ranges: bytes
<< Content-Length: 3369
<< Connection: close
<< Content-Type: text/html
<<
<< File content goes here
浏览器并从服务器的响应中获得服务器的信息：比如运行在Apache。
上面翻译成翻译成语言上面就是
<< HTTP1.1协议方式有效
<< 当前时间是: Mon, 12 Mar 2004 19:12:16 GMT
<< 服务器是: Apache/1.3.31 (Unix) mod_throttle/3.1.2
<< 最后一次修改: Fri, 22 Sep 2004 14:16:18
<< ETag: "dd7b6e-d29-39cb69b2"
<< Accept-Ranges: bytes
<< Content-Length: 3369
<< Connection: close
<< Content-Type: text/html
<<
<< File content goes here
8、varnish缓存可以做正向带理吗
arnish是一款高性能的开源HTTP加速器，挪威最大的在线报纸 erdens Gang 使用3台arnish代替了原来的12台Suid，性能比以前更好。但与老牌的suid相比，各有各的优劣势，网上大量的相对比较只是在其个人对自己熟悉的应用的最大使用上的发挥而已，可能suid到了有能力的人手上才足以发挥最强大的威力arnish采用了“isual Page Cache”技术，在内存的利用上，arnish比Suid具有优势，它避免了Suid频繁在内存、磁盘中交换文件，性能要比Suid高。通过arnish管理端口，可以使用正则表达式快速、批量地清除部分缓存，这一点是Suid不能具备的。 本人就varnish的一些见解与配置方法做简单的介绍与笔记实验环境：Red Hat Enterprise Linux Server release 5.4 (Tikanga) 内核2.6.18-.el5yum install pcre-devel ##预先安装一个软件包，不然会提示错误tar zxvf varnish-2.1.3.tar.gzcd varnish-2.1.3 ./configure --prefix=/usr/local/varnish-2.1.3ke && ke install编辑配置文件，有模版，但太多注释，最好自己新建一个vim /usr/local/varnish-2.1.3/etc/varnish/varnish.conf ############下面附上配置文件的内容及注释########################http请求处理过程#1,receive请求入口状态，根据vcl判断pass还是lookup本地查询#lookup，在hash表中查找数据，若找到则进入hit状态，否则进入fetch状态#pass，选择后台，进入fetch状态#fetch，对请求进行后端的获取，发送请求，获得数据，并进行本地存储#deliver，将数据发送给客户端，进入done#done,处理结束##########配置后端服务器##############代码 代码如下:backend linuxidc01 { .host = "..1."; .port = ""; .probe = { .timeout = 5s; .interval = 2s; .window = 10; .threshold = 8; } }backend linuxidc02 { .host = "..1."; .port = ""; .probe = { .timeout = 5s; .interval = 2s; .window = 10; .threshold = 8; } }##############配置后端服务器组，进行健康检测6秒，使用random方式设置权重######## #########另一种方式round-robin则默认轮询机制####################代码 代码如下:director linuxidc random { .retries = 6; { .backend = linuxidc02; .weight = 2; } { .backend = linuxidc01; .weight = 2; } }##########定义访问列表，允许下列清除varnish缓存#######################代码 代码如下:acl local { "localhost"; ".0.0.1"; }########从url判断针对哪类后面服务器及缓存配置############################代码 代码如下:sub vcl_recv { if (re.http.host ~ "^linuxidc.vicp") #匹配域名跳转后台服务器 { set re.backend = linuxidc; } else { error "Unknown HostName!"; } if (re.reuest == "PURGE") #不允许非访问控制列表内的IP清除varnish缓存 { if (!client.ip ~ local) { error "Not Allowed."; return (lookup); } } #清除url中有jpg等文件的cookie if (re.reuest == "GET" && re.url ~ "\.(jpg|png|gif|swf|jpeg|ico)$") { unset re.http.cookie; } #判断re.http.X-Forwarded-For 如果前端有多重反向代理，这样可以获取客户端IP。 if (re.http.x-forwarded-for) { set re.http.X-Forwarded-For = re.http.X-Forwarded-For ", " client.ip; } else { set re.http.X-Forwarded-For = client.ip; }##varnish实现图片的防盗链# if (re.http.referer ~ ") # {# if ( !(re.http.referer ~ "" ||# re.http.referer ~ "" ) )# {# set re.http.host = "linuxidc.vicp";# set re.url = "/referer.jpg"; # }# return(lookup);# }# else {return(pass);} if (re.reuest != "GET" && re.reuest != "HEAD" && re.reuest != "PUT" && re.reuest != "POST" && re.reuest != "TRACE" && re.reuest != "OPTIONS" && re.reuest != "DELETE") { return (pipe); } #对非GET|HEAD请求的直接转发给后端服务器 if (re.reuest != "GET" && re.reuest != "HEAD") { return (pass); } ##对GET请求，且url里以.php和.php?结尾的，直接转发给后端服务器 if (re.reuest == "GET" && re.url ~ "\.(php)($|\?)") { return (pass); } ##对请求中有验证及cookie，直接转发给后端服务器 if (re.http.Authorization || re.http.Cookie) { return (pass);} { ##除以上的访问请求，从缓存中查找 return (lookup); } ##指定的font目录不进行缓存 if (re.url ~ "^/fonts/") { return (pass); }}sub vcl_pipe { return (pipe); }##进入pass模式，请求被送往后端，后端返回数据给客户端，但不进入缓存处理 sub vcl_pass { return (pass); }sub vcl_hash { set re.hash += re.url; if (re.http.host) { set re.hash += re.http.host; } else { set re.hash += server.ip; } return (hash); }##在lookup后如果在cache中找到请求的缓存，一般以下面几个关键词结束sub vcl_hit { if (!obj.cacheable) { return (pass); } return (deliver); } ##lookup后没有找到缓存时调用，以下面几个关键词结束，及调用fetch参数重新测试是否加入缓存sub vcl_miss { return (fetch); }#让varnish服务器缓存的类型，从后端取得数据后调用sub vcl_fetch { if (!beresp.cacheable) { return (pass); } if (beresp.http.Set-Cookie) { return (pass); } ##WEB服务器指明不缓存的内容，varnish服务器不缓存 if (beresp.http.Prag ~ "no-cache" || beresp.http.Cache-Control ~ "no-cache" || beresp.http.Cache-Control ~ "private") { return (pass); } ##对访问中get有包含jpg,png等格式的文件进行缓存，缓存时间为7天，s为秒 if (re.reuest == "GET" && re.url ~ "\.(js|css|mp3|jpg|png|gif|swf|jpeg|ico)$") { set beresp.ttl = 7d; } ##对访问get中包含htm等静态页面，缓存秒 if (re.reuest == "GET" && re.url ~ "\/[0-9]\.htm$") { set beresp.ttl = s; } return (deliver); }####添加在页面head头信息中查看缓存命中情况########sub vcl_deliver { set resp.http.x-hits = obj.hits ; if (obj.hits > 0) { set resp.http.X-Cache = "HIT ctel-bbs"; } else { set resp.http.X-Cache = "MISS ctel-bbs"; } }#########################以上为 varnish的配置文件##########################创建用户：groupadd useradd -g 创建 varnish_cache的缓存位置mkdir /data/varnish_cache启动varnishulimit -SHn ####设置文件描述符，因为我的机子性能并不好，可以按照自己的配置去设置/usr/local/varnish-2.1.3/in/varnishd -u -g -f /usr/local/varnish-2.1.3/etc/varnish/varnish.conf -a 0.0.0.0:80 -s file,/data/varnish_cache/varnish_cache.data,M -w ,,10 -t -T .0.0.1:####-u 以什么用运行 -g 以什么组运行 -f varnish配置文件 -a 绑定IP和端口 -s varnish缓存文件位置与大小 -w 最小，最大线程和超时时间 -T varnish管理端口，主要用来清除缓存#结束varnishd进程pkill varnishd启动varnishncsa用来将arnish访问日志写入日志文件：/usr/local/varnish-2.1.3/bin/varnishncsa -w /data/logs/varnish.log &每天0点运行，按天切割arnish日志，生成一个压缩文件，同时删除上个月旧日志的脚本（/var/logs/cutlog.sh）：vim /usr/local/varnish-2.1.3/etc/varnish/cut_varnish_log.sh写入以下脚本：#!/bin/sh# This file run at 00:00date=$(date -d "yesterday" +"%Y-%m-%d")pkill -9 varnishncsamv /data/logs/varnish.log /data/logs/${date}.log/usr/local/varnish-2.1.3/bin/varnishncsa -w /data/logs/varnish.log &mkdir -p /data/logs/varnish/gzip -c /data/logs/${date}.log > /data/logs/varnish/${date}.log.gzrm -f /data/logs/${date}.logrm -f /data/logs/varnish/$(date -d "-1 month" +"%Y-%m*").log.gz定时任务：crontab -e00 00 * * * /usr/local/varnish-2.1.3/etc/varnish/cut_varnish_log.sh优化Linux内核参数vi /etc/sysctl.confnet.ipv4.tcp_fin_timeout = 30net.ipv4.tcp_keepalive_time = net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.ip_local_port_range = 使配置生效/in/sysctl -p通过arnish管理端口，使用正则表达式批量清除缓存清除所有缓存/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: url.purge *$清除ige目录下所有缓存/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: url.purge /ige/.0.0.1: 为被清除缓存服务器 为被清除的域名 /static/ige/tt.jsp 为被清除的url列表/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: purge "re.http.host ~ && re.url ~ /static/ige/tt.jsp"+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++一个清除Suid缓存的PHP函数代码 代码如下:<?php function purge($ip, $url) { $errstr = ''; $errno = ''; $fp = fsockopen ($ip, 80, $errno, $errstr, 2); if (!$fp) { return false; } else { $out = "PURGE $url HTTP/1.1\r\n"; $out .= "; $out .= "Connection: close\r\n\r\n"; fputs ($fp, $out); $out = fgets($fp , ); fclose ($fp); return true; } } purge("..0.4", "/index.php"); ?> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++配置开机自动启动arnishvim /etc/rc.d/rc.local在末行写入以下内容：ulimit -SHn /usr/local/varnish-2.1.3/in/varnishd -u -g -f /usr/local/varnish-2.1.3/etc/varnish/varnish.conf -a 0.0.0.0:80 -s file,/data/varnish_cache/varnish_cache.data,M -w ,,10 -t -T .0.0.1:/usr/local/varnish-2.1.3/bin/varnishncsa -w /data/logs/varnish.log &查看arnish服务器连接数与命中率：/usr/local/varnish-2.1.3/bin/varnishstat以上为varnish的状态， 0.00 0.06 Client reuests received 为服务端接收的客户端请求次数 0.00 0.01 Cache hits 为命中缓存，从缓存中取得数据返回给客户端的次数，即命中率11 0.00 0.00 Cache misses 为跳过pass缓存，从后端服务应用中取得数据返回给用户的次数用help看看可以使用哪些arnish命令：/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: help