浏览器缓存和服务器缓存

1负载均衡配置

2失败重试配置

在fail_timeout时间内失败了max_fails次请求后,认为上游服务器不可用,就会将服务地址剔除掉,fail_timeout时间后会再次将服务器加入存活列表进行重试。

limit_req_zone指令设置参数

参数说明

limit_req_zone定义在>

分布式：服务分散部署在不同服务器组成一个整体应用，分散压力，解决高并发。

假设访问量特别大，就可以做成分布式，将一个大项目拆分出来单独运行。跟cdn一样的机制。

Redis分布式：将redis中的数据分布到不同的服务器上，每台服务器存储不同内容。Mysql集群是每台服务器都存放相同数据。分布式部署：系统应用部署在2台或以上服务器或虚拟机上，服务间通过RPC、WCF(包含WebService）等交互，即可称作分布式部署。微服务也算作分布式的一种，反之则不然。分布式优点:1、将模块拆分，使用接口通信，降低模块之间的耦合度。2、将项目拆分成若干个子项目，不同团队负责不同子项目。3、增加功能时只需再加一个子项目，调用其它系统接口即可。4、可灵活进行分布式部署。5、提高代码的复用性，比如service层，如果不采用分布式rest服务方式架构，在手机Wap商城、微信商城、PC、Android、ios每个端都要写一个service层逻辑，开发量大，难以维护和一起升级，此时可采用分布式rest服务方式共用一个service层。缺点：系统之间交互要使用远程通信，接口开发增大工作量，但利大于弊。微服务：可单独部署运行的微小服务，一个服务只完成单一功能分散能力，服务之间通过RPC等交互，至少有一个数据库。用户量过大高并发时，建议将应用拆解为多个子系统，各自隔离，独立负责功能。缺点：服务数量大，后期运维较难。分布式、微服务区别：分布式依赖整体组合，是系统的部署方式；微服务是架构设计方式，粒度更小，服务之间耦合度更低。独立小团队负责，敏捷性更高。集群：多台服务器复制部署相同应用，由负载均衡共同对外提供服务，逻辑功能仍是单体应用。项目如果跑在一台机器上，这台机器如果出现故障，或者用户请求量比较高一台机器支撑不住，网站可能就访问不了。那怎么解决呢？就需要使用多台机器，复制部署一样的程序，让几个机器同时运行网站。那怎么分发请求到所有机器上？所以负载均衡的概念就出现了。负载均衡：将请求分发以分摊服务器压力。基于反向代理能将所有的请求根据指定的策略算法，分发到不同的服务器上。实现负载均衡常用Nginx、LVS。负载均衡服务器出现问题了怎么办？所有冗余的概念就出现了。冗余：两台或多台服务器，一个主服务器，一个从服务器。假设一个主服务器的负载均衡服务器出现问题，从服务器能替代主服务器来继续负载均衡。实现的方式就是使用Keepalive来抢占虚拟主机。双机双工模式：目前Cluster（集群）的一种形式，两台服务器均为活动状态，同时运行相同的应用，保证整体的性能，也实现了负载均衡和互为备份。WEB服务器或FTP服务器等用此种方式比较多。实现多台服务器代码（文件）同步方案：1、负载均衡中实现代码同步rsync。2、rsync+inotify逐一文件监听并实时同步。3、实现redis共享session。

适合缓存的内容

1 不变的图像，如logo，图标等

2 js、css静态文件

3 可下载的内容，媒体文件

适合协商缓存

1 HTML文件

2 经常替换的

3 经常修改的js、css文件，js、css文件的加载可以加入文件的签名来拒绝缓存，如‘indexcss签名’，‘index签名js’

不建议缓存的内容

1 用户隐私等敏感数据

2 经常改变的API数据接口

NGINX配置缓存策略

本地缓存配置

1 add_header指令：添加状态码为2XX和3XX的响应头信息，设置代码add_header name value [always];，可以设置Pragma、Expires、Cache-Control，可以继承

2 expires指令：通知浏览器过期时长，设置代码expires time;

3 Etag指令：指定签名，设置代码etag on|off，默认on

前端代码和资源压缩

优势

1 让资源文件更小，加快文件在网络中的传输，让网页更快的展现，降低带宽和流量的开销

压缩方式

1 js、css、、html代码的压缩

2 gzip压缩

gzip配置

gzip on|off; #是否开启gzipgzip_buffers 32 4K|16 8K; #缓冲（在内存中缓存几块？每块多大）gzip_comp_level [1-9] #推荐6，压缩级别（级别越高，压得越小，越浪费CPU计算资源）

gzip_disable #正则匹配UA，什么样的Uri不进行gzip

gzip_min_length 200 #开始压缩的最小长度

gzip_>用同步软件不就搞定了，省的瞎折腾了啊
我现在用的Bestsync2011同步软件，我觉得还蛮好用的，速度比较快，日志功能很强大，反正如果同步有任何错误，你能查看到每个文件的同步状态。
for example: 你可以把软件安装在服务器上，建立1个任务，来将这两台服务器进行实时同步。
1 在主菜单里面点 编辑-->追加任务
文件夹1选择 服务器A需要同步的文件夹位置
文件夹2选择 服务器B需要同步的文件夹位置
方向为由文件夹2到文件夹1
然后选择 完成 按钮
在主菜单上，点选 开始 按钮， 这样， A与B上的文件就完全一致了。
2 在任务列表中，双击你刚刚建立的这个任务，然后会d出属性对话框

翻到 “日程” 那页
勾选上 “文件一旦变化，立即同步”这个选项
最后点击 确定 按钮
这样，只要服务器A的指定文件夹一旦变化，就实时同步到服务器B了以此类推
他们新浪微博上要好多教程，你不清楚可以去看那上的手册。。。
是否可以解决您的问题？

后端群集是为了平衡来自前端的请求。通常是为了减轻单独后端处理的压力（尤其各种动态网页），但又不希望使用缓存，使得客户端不能看到最新页面。倘若前端做了缓存，那么前端就不会对后端发送请求，取而代之，从缓存调用。所以请求不会去后端，也就看不到最新页面。
所以说缓存+群集后端要闹哪样啊？

理解负载均衡，必须先搞清楚正向代理和反向代理。

注：

正向代理，代理的是用户。

反向代理，代理的是服务器

什么是负载均衡

当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。

我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。

负载均衡是用反向代理的原理实现的。
1、轮询（默认）

每个请求 按时间顺序逐一分配 到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstreambackserver {server192168014;server192168015;}

2、weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的

情况。

upstreambackserver {server192168014weight=3;server192168015weight=7;}

权重越高，在被访问的概率越大，如上例，分别是30%，70%。

3、上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。

我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstreambackserver{ip_hash;server192168014:88;server192168015:80;}

4、fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstreambackserver {serverserver1;serverserver2;fair;}

5、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {    server squid1:3128;    server squid2:3128;    hash$request_uri;    hash_method crc32;}123456

每个设备的状态设置为:

down 表示单前的server暂时不参与负载

weight 默认为1weight越大，负载的权重就越大。

max_fails：允许请求失败的次数默认为1当超过最大次数时，返回 proxy_next_upstream模块定义的错误

fail_timeout:max_fails次失败后，暂停的时间。

backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

配置实例：

#user  nobody;worker_processes4;events {# 最大并发数worker_connections1024;}>