⑴ 接触过的Nginx的负载均衡算法有哪些
Nginx 官方默认的几种负载均衡的算法
①Round-Robin RR轮询（默认） 一次一个的来（理论上的，实际实验可能会有间隔）
②weight 权重 权重高多分发一些 服务器硬件更好的设置权重更高一些
③ip_hash 同一个IP，所有的访问都分发到同一个web服务器
第三方模块实现的调度算法 需要编译安装第三方模块
④fair 根据后端服务器的繁忙程度 将请求发到非繁忙的后端服务器
⑤url_hash 如果客户端访问的url是同一个，将转发到同一台后端服务器
看你在学习Nginx的知识，推荐你去看黑马程序员视频库，里面有它的学习视频，讲解的很详细哦！
⑵ 12《Nginx 入门教程》Nginx负载均衡(上)
负载均衡，其英文简称Load Balancing，是一种计算机技术。用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。宏观上的意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行以解决高性能，单点故障（高可用），扩展性（水平伸缩）等高流量下常见的问题。
由于载均衡技术是要对网络传输中的报文控制，因此会涉及到网络七层模型，因此负载均衡分类可以按照网络层次进行分类，比如二层、三层、四层、七层负载均衡。其中最常见的是四层和七层负载均衡。此外，还有其他方面进行分类的，有软件负载均衡、硬件负载均衡等。
负载均衡服务器对外依然提供一个VIP（虚IP），集群中不同的机器采用相同IP地址，但是机器的MAC地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。
和二层负载均衡类似，负载均衡服务器对外依然提供一个VIP（虚IP），但是集群中不同的机器采用不同的IP地址。当负载帆并唤均衡服务器接受到请求之后，根据不同的负载均衡算法，通过IP将请求转发至不同的真实服务器。
四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。
七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 http、dns 等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个 Web 服务器的负载均衡，除了根据 IP 加端口进行负载外，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。
业界已经有很多开源的负载均衡工具，大部分是工作在第四层和第七层的。代表的开源工具有 Nginx/LVS/Haproxy。值得一提的是，LVS 是国内前淘宝网高级研究员章文嵩博士的作品。LVS 主要用来做四层负载均衡，Nginx 和 Haproxy 主要是做七层的负载均衡，但它们都支持四层的负载均衡，例如在 Nginx 中的 stream 模块除了支持四层的反向代理功能，也支持四层负载均衡功能。
负载均衡算法可以分成两大类，一类是静态的负载均衡算法，常见的有轮询、权重等；另一大类动态的负载均衡算法，常见的有最少的连接、最快响应、服务类型、服务质量等等，还有很多策略，不同的软件会实现不同的负载均衡算法。
Nginx 的 stream 模块和 http 模块分别支持四层和七层模块的负载均衡。其用法和支持的负载均衡策略大致相同。首先使用 upstream 指令块 和 server 指令指定上游的服务，upstream 指令的用法如下:
官网示例如下:
这里定义了4台上游服务器，分别用域名, ip+port、socket 形式指定地址，后面跟上若干配置参数。默认情况下，upstream 指令块中采用的是加权 Round-Robin 负载均衡算法。该算法通过加权轮询的方式访问 upstream 中 server 指令指定的上游服务。此时，在server 指令中我们可以添加一些关于服蔽瞎务的静态配态凯置，比如指定服务的权重(weight)、server 的最大并发连接数(max_conns)、max_fails 和 fail_timeout 等。
除了默认的 Round-Robin 算法外，Nginx 中常用的负载均衡策略还有基于客户端 ip 地址的 Hash 算法。该算法以客户端的 ip 地址作为 hash 算法的关键字，映射到特定的上游服务器中，当然也可以根据客户段的其他 key 来进行 hash 算法。涉及的配置指令为 ip_hash 和 hash，用法如下:
最后 Nginx 中一种常用的动态负载均衡算法是最少连接数算法。该算法会从所有的上游服务器中找到并发连接数最少的一个，然后将请求转发给它，如果出现多个最少连接数的服务器，则会在这些最少连接数的服务器中继续应用 Round-Robin 算法。配置该策略的指令为 least_conn，其指令格式如下：
当然, Nginx 中的负载均衡策略还有很多，就不在此一一介绍了。可以仔细研读官方文档进行进一步学习
本小节只是介绍了负载均衡的相关知识，以及对应 Nginx 中的配置指令，后面一节会实战 Nginx 的负载均衡功能，同时测试多种负载均衡算法。
⑶ 使用 Nginx 限流
Nginx不颤虚仅可以做Web服务器、做反向代理、负载均衡，还可以做限流系统。此处我们就Nginx为例，介绍一下如何配置一个限流系统。
Nginx使用的限流算法是漏桶算法。
（1）安装Nginx。
如果你的linux是Ubuntu或Debian，使用apt-get安装，在命令行中输入以下命令：
如果是CentOS，使用yum安装，在命令行中输入以下命令：
（2）找到Nginx所使用的配置文件所在的位置。在Ubuntu和Debian是在如下位茄局燃置：
而CentOS则是在如下位置：
（3）在http块中，配置基础的限流配置：
其中4到8行定义的是一个服务器接口。而第2行和第6行配合完成了一个限流设置，下面解释一下这两行做的事情：
limit_req_zone命令在Nginx的配置文件中专门用于定义限流，它必须被放在http块中，否则无法生效，因为该命令只在http中被定腊皮义。
该字段包含三个参数：
第一个参数，就是键（key），即值$binary_remote_addr所在的位置，它代表的是我们的限流系统限制请求所用的键。
此处，我们使用了$binary_remote_addr，它是Nginx内置的一个值，代表的是客户端的IP地址的二进制表示。因此换言之，我们的示例配置，是希望限流系统以客户端的IP地址为键进行限流。
对Nginx有经验的读者可能还知道有一个Nginx内置值为binary_remote_addr是Nginx的社区推荐用值，因为它是二进制表达，占用的空间一般比字符串表达的$remote_addr要短一些，在寸土寸金的限流系统中尤为重要。
第二个参数是限流配置的共享内存占用（zone）。为了性能优势，Nginx将限流配置放在共享内存中，供所有Nginx的进程使用，因为它占用的是内存，所以我们希望开发者能够指定一个合理的、既不浪费又能存储足够信息的空间大小。根据实践经验，1MB的空间可以储存16000个IP地址。
该参数的语法是用冒号隔开的两个部分，第一部分是给该部分申请的内存一个名字，第二部分是我们希望申请的内存大小。
因此，在该声明中，我们声明了一个名叫mylimit（我的限制）的内存空间，然后它的大小是10M，即可以存储160000个IP地址，对于实验来说足够了。
第三个配置就是访问速率（rate）了，格式是用左斜杠隔开的请求数和时间单位。这里的访问速率就是最大速率，因此10r/s就是每秒10个请求。通过这台Nginx服务器访问后端服务器的请求速率无法超过每秒10个请求。
注意到第5行声明了一个资源位置/test/，因此我们第6行的配置就是针对这个资源的，通俗地说，我们在第6行的配置是针对特定API的，这个API就是路径为/test/的API，而其真正路径就是第8行声明的 http://backend 。注意，这个URL是不存在的，实际操作中，读者需要将它换成你已经开发好的业务逻辑所在的位置，Nginx在这里的作用只是一个反向代理，它自己本身没有资源。
第6行中，我们使用limit_req命令，声明该API需要一个限流配置，而该限流配置所在位置（zone）就是mylimit。
这样一来，所有发往该API的请求会先读到第6行的限流配置，然后根据该限流配置mylimit的名称找到声明在第2行的参数，然后决定该请求是否应该被拒绝。
但是这样还不够。不要忘了，Nginx使用的漏桶算法，不是时间窗口算法，我们前文介绍中说过，漏桶算法是有两个参数可以配置的！
（4）配置峰值。Nginx漏桶算法的峰值属性在API中设置。参数名为burst。如下：
在第6行中，我们只需要在声明limit_req的同时，指定burst就可以了，此处我们指定burst为20，即漏桶算法中我们的“桶”最多可以接受20个请求。
这样一个Nginx的限流系统就配置完毕了，但实际操作中，我们还可能需要很多别的功能，下面笔者就介绍几个很有用的配置技巧。
相对于传统的漏桶算法慢吞吞地转发请求的缺陷，Nginx实现了一种漏桶算法的优化版，允许开发者指定快速转发，而且还不影响正常的限流功能。开发者只需要在指定limit_req的一行中指定burst之后指定另一个参数nodelay，就可以在请求总数没有超过burst指定值的情况下，迅速转发所有请求了。如下所示：
您可能会担忧：这种情况下，会不会出现所有请求都被快速转发，然后接下来又有没有超过burst数量的请求出现，再次被快速转发，就好像固定窗口算法的漏洞一样，从而超过我们本来希望它能限制到的上限数量呢？答案是不会。Nginx的快速转发是这样实现的：
举例而言，配置如上所示，假如在某个瞬时有25个请求进入系统，Nginx会先转发20个（或21个，取决于瞬时情况），然后拒绝剩下的4个请求，并将当前桶中数量标为0，然后接下来的每100毫秒，缓慢恢复1个空位。
这样我们可以看到，Nginx既做到了快速转发消息，又不会让后端服务器承担过多的流量。
限流系统会提前拒绝请求，因此，我们在业务服务器上是肯定看不到这些请求的。假如我们收到一个报告说某用户在使用网站的时候出现错误，但是我们在业务服务器上又找不到相关的日志，我们如何确定是不是限流造成的呢？
只有限流系统的日志才能说明问题。因此，我们需要Nginx打印出它拒绝掉的请求的信息。但同时，Nginx打印的限流日志默认是错误（error），如果我们设置了一个基于日志错误扫描的警报，它扫到的限流错误，真的是我们希望给自己发警报的情况吗？
配置请求的位置就在资源中，使用的命令是limit_req_log_level，如下：
在第7行中，我们将Nginx的日志改为了警告（warn）。
限流的HTTP标准响应状态码是429，但是如果读者拿上述的配置文件直接去测试，会发现Nginx返回的是503（服务不可用）。到底应该返回什么状态码，是一个偏程序哲学的问题，此处我们不讨论，我们只讨论：如何让Nginx返回我们指定的状态码？
答案也是在同一个资源中，它的配置命令是limit_req_status，然后我们指定它为429即可：
除了以上功能以外，Nginx还支持很多复杂先进的限流功能，可以访问 https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/ 作进一步的了解。
⑷ 软件架构中，负载均衡有哪些调度算法
谢邀！
负载均衡调度算法也叫负载均衡方法有很多种，下面以使用比较广的nginx为例说说软件负载均衡的调度算法：
nginx默认的调度算法，按照时间顺序逐一分配后台服务器
在server后加weigth，weight值越高，后台服务器分配概率越大，下图是说ip为102的后台服务分配概率是ip为101后台服务的两倍
按照访问ip的hash分配，增加ip_hash关键字，同一ip访问相同的后台服务
按照访问url的hash分配，增加url_hash关键字，同一url访问相同的后台服务
按照最少连接数方式分配，增加least_conn关键字，哪个后台服务连接数少就分配哪个
按照最短响应时间分配，增加fair关键字，响应时间短的后台服务优先分配
⑸ Nginx的功能与特性
Nginx在过去的10年里，作为Web服务器行业里的新生代迅速崛起。Nginx由俄罗斯工程师Igor Sysoev编写，2004年10月4日发布了第一个公众版本：1.0.1。Apache一直占据Web服务器行业的第一，但自2008年开始，它的市场份额在潜移默化的转移到Nginx身上。直至今日，据Netcraft的统计显示，全世界排名前100万的网站中有超过27%的网并樱站在使用Nginx作为Web服务器。Nginx迅速在一向稳定的Web服务器行业崛起并站稳跟脚.
1 、静态HTTP服务器
Nginx是一个HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端。
2、反向代理服务器
客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。
3、负载均衡
当网站访问量非常大，将同一个应用部署在多台服务器上，将大量用户的请求分配给多台机器处理。同时带来的好处是，其中绝毕丛一台服务器万一挂了，只要还有其他服务器正常运行，就不会影响用户使用。Nginx可以通过反向代理来实现负载均衡，并能使用3种自带策略及2种第三方策略。
（1）RR（默认，每个请求按时间顺序逐一分配到不同的后端服务器）
（2）权重（指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况）
（3）ip-hash（以上配置会将请求轮询分配到应用服务器，也就是一个客户端的多次请求，有可能会由多台不同的服务器处理（若存在登录session时则需要重复登录）。ip-hash根据客户端ip地址的hash值将请求分配给固定的某一个服务器处理）
（4）fair（第三方 按后端服务器的响应时间来分配请求，响应时间短的优先分配）
（5）url_hash（第三方 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。 在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法）
4、虚拟主机
有的网站访问量大，需要负载均衡。有的网站，由于访问量太小，需要节省成本，将多个网站部署在同一台服务器上。例如将www.a.com和www.b.com两个网站部署在同一台服务器上，两个域名解析到同一个IP地址，但是用户通过两个域名却可以打开两个完全不同的网站，互相不影响，就像访问两个服务器一样，所以叫两个虚拟主机。
在服务器8080和8081分别开了一个应用，客户端通过不同的域名访问，根据server_name可以反向代理到对应的应用服务器。虚拟主机的原理数虚是通过HTTP请求头中的Host是否匹配server_name来实现的，另外，server_name配置还可以过滤有人恶意将某些域名指向你的主机服务器。
1、IO多路复用epoll
2、轻量级
3、CPU亲和（affinity）
4、sendfile
⑹ nginx 负载均衡之一致性hash，普通hash
哈希负载均衡原理
ngx_http_upstream_hash_mole支持普通的hash及一致性hash两种负载均衡算法，默认的是普通的hash来进行负载均衡。
nginx 普通的hash算法支持配置http变量值作为hash值计算的key，通过hash计算得出的hash值和总权重的余数作为挑选server的依据；nginx的一致性hash(chash)算法则要复杂一些。这里会对一致性hash的机制原理作详细的说明。
一致性hash算法的原理
一致性hash用于对hash算法的改进，后端服务器在配置的server的数量发生变化后，同一个upstream server接收到的请求会的数量和server数量变化之间会有变化。尤其是在负载均衡配置的upstream server数量发生增长后，造成产生的请求可能会在后端的upstream server中并不均匀，有的upstream server负载很低，有的upstream server负载较高，这样的负载均衡的效果比较差，可能对upstream server造成不良的影响。由此，产生了一致性hash算法来均衡。
那么为什么一致性hash算法能改善这种情况呢？这里引用网上资料的一致性hash算法的图例。
因为对于hash(k)的范围在int范围，所以我们将0~2^32作为一个环。其步骤为：
1，求出每个服务器的hash（服务器ip）值，将其配置到一个 0~2^n 的圆环上（n通常取32）。
2，用同样的方法求出待存储对象的主键 hash值，也将其配置到这个圆环上，然后从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
其分布如图：
除了上边的优点，其实还有一个优点：对于热点数据，如果发现node1访问量明显很大，负载高于其他节点，这就说明node1存储的数据是热点数据。这时候，为了减少node1的负载，我们可以在热点数据位置再加入一个node，用来分担热点数据的压力。
雪崩效应
接下来我们来看一下，当有节点宕机时会有什么问题。如下图：
如上图，当B节点宕机后，原本存储在B节点的k1，k2将会迁移到节点C上，这可能会导致很大的问题。如果B上存储的是热点数据，将数据迁移到C节点上，然后C需要承受B+C的数据，也承受不住，也挂了。。。。然后继续CD都挂了。这就造成了雪崩效应。
上面会造成雪崩效应的原因分析：
如果不存在热点数据的时候，每台机器的承受的压力是M/2(假设每台机器的最高负载能力为M)，原本是不会有问题的，但是，这个时候A服务器由于有热点数据挂了，然后A的数据迁移至B，导致B所需要承受的压力变为M（还不考虑热点数据访问的压力），所以这个失败B是必挂的，然后C至少需要承受1.5M的压力。。。。然后大家一起挂。。。
所以我们通过上面可以看到，之所以会大家一起挂，原因在于如果一台机器挂了，那么它的压力全部被分配到一台机器上，导致雪崩。
怎么解决雪崩问题呢，这时候需要引入虚拟节点来进行解决。
虚拟节点
虚拟节点，我们可以针对每个实际的节点，虚拟出多个虚拟节点，用来映射到圈上的位置，进行存储对应的数据。如下图：
如上图：A节点对应A1，A2，BCD节点同理。这时候，如果A节点挂了，A节点的数据迁移情况是:A1数据会迁移到C2，A2数据迁移到D1。这就相当于A的数据被C和D分担了，这就避免了雪崩效应的发送，而且虚拟节点我们可以自定义设置，使其适用于我们的应用。
ngx_http_upstream_consistent_hash
该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器，比如：
指令
语法：consistent_hash variable_name
默认值：none
上下文：upstream
配置upstream采用一致性hash作为负载均衡算法，并使用配置的变量名作为hash输入。
参考文档：
https://www.cnblogs.com/FengGeBlog/p/10615345.html
http://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-mole/
⑺ nginx负载均衡有个服务器不分发
Nginx负载均衡在默认情况下会按照预设的算法（如轮询、IP Hash等）将请求分发给多个后端服务器，从而实现负载均衡的效果。如果发现有一个服务器没有收到请求，可能是因为该服务器处于宕机、网络不哗绝物通或者配置宏凳错误的状态。以下是一些解决该问题的方法：
1. 检查后端服务器的状态：使用ping命令或者其他网络工具检查服务器的网络状态是否正常，确认服务器是否能够正常响应请求。如果服务器处于宕机的状态，应当先排除服务器硬件故障或者系统配置错误的问题。
2. 检查Nginx的配置文件：检查Nginx的配置文件中是否正确指定了所有需要负载均衡的后端服务器，并按照负载均衡算法进行分配。可以使用Nginx的命令行工具或者日志文件来查看默认或者自定义的负载均衡算法的状态和效果。
3. 检查Nginx的日志文件：Nginx的日志文件可以记录被分发到每个后端服务器的请求数量和状态，可以使用日志文件来查看是否有服务器没有接收到请求，并可以进一步确认问题的具体原因。
4. 调整负载均衡的配置参数：根据具体情况，可以调整Nginx的负载均衡算法、调整Node间的权重或者调整最大连接数等参数，以优化乱液负载均衡的效果和性能。
希望以上方法对您有所帮助，如有其他问题，请联系Nginx官方技术支持或者社区。
⑻ 13《Nginx 入门教程》Nginx负载均衡(下)
这一小节中，我们将实战 Nginx 的四层和七层负载均衡功能。条件有限，使用一台公网主机，在上面搭建好 Nginx 服务。公网 IP 为 180.76.152.113。
首先会进行简单的四层负载均衡实验，不会涉及多种负载均衡算法，只使用默认的 Round-Robin算法。在后续的七层负载均衡实验中，会重点测试不同的负载均衡策略，完成相关实验。
首先在 nginx.conf 中添加如下 stream 指令块配置:
上述配置用端口3000和3001模拟两个上游服务器，然后在 upstream 指令块中指定这两个上游服务器的地址，同时给第一个设置权重为2。由于默认采用的是加权的 Round-Robin 算法，默认服务器的权重为1。设置为2，表明3次请求中，2次会转发到3000端口，一次会转发到3001端口，下面的测试也验证了这一点。
和四层的配置其实差不多，在七层中除了告亩测试最基本的，我们还将测试前面提到的几种负载均衡策略，进一步熟悉 Nginx 中的负载均衡配置。
在 nginx.conf 中添加如下的 http 指令块:
上述配置中，我们用8000，8001和8002三个端口模拟了3个上游服务器，默认使用轮询负载均衡算法，而且三个的权重均为1。进行如下的 http 请求操作，可以看到 Nginx 转发 http 请求会均匀地分配到3个服务器上。
我们打开 ip_hash 指令的注释，这个时候默认是使用客户端的 ip 地址作为 hash 的 key，然后重启 Nginx 服务并进行如下的命令行操作：
接下来，注释 ip_hash 指令，我们打开 hash user_$arg_username 这行配置的注释， hash 指令可以让我们根据我们设置的 key 进行 hash，然后根据 hash 值选择上游的服务器。具体测试参看下面的 Linux 命令：
这里我们可以看到，在请求中带上 username 参数，Nginx 中配置敬友亩的 hash 算法会根据请求中带的 username 参数作为 key 去进行 hash，然后在根据 hash 结果映射上游服务器。username 相同时，选择的上游亮森服务器肯定是一样的，只有在 username 的值发生变化时，返回的响应才可能有变化。
今天我们完成了几个测试实验，主要是针对 Nginx 的四层和七层的负载均衡功能进行了测试。这个功能在微服务部署中会有较多的应用。因为高流量企业为保证服务的高可用性，往往会水平扩展多个相同功能的服务，部署在多台主机上，这个时候负载均衡技术就能派上用场了，而 Nginx 提供了完善的负载均衡功能以及多种负载均衡算法，能满足大部分企业的需求，如果还不够，可以通过编写内部开发模块并集成到 Nginx，实现相应的需求。所以说 Nginx 是非常值得学习和深入研究的。
⑼ nginx负载均衡轮询算法中,哪个关键字代表权重
本文主要和大家分享nignx负载均衡算法，希望能帮助到大家。
一、Nginx负载均衡算法
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务，如果后端某台服务器死机，自动剔除故障系统，使用户访问不受影响。
2、weight（轮询权值）
weight的值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下。或者仅仅为在主从的情况下设置不同的权值，达到合理有效的地利用主机资源。
3、ip_hash源地址哈希法
源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
4、fair
比 weight、ip_hash更加智能的负搜孝载均衡算法，fair算法可以根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间 来分配请求，响应时间短的优先分配。Nginx本身不支持汪者fair，如果需要这种调度算法，则必须安装upstream_fair模块。
5、url_hash
按访问的URL的哈希结果来分配请求，使每个URL定向到一台后端服务器，可以进一步提高后端缓存服务器的效率。Nginx本身不支持url_hash，如果需要这种调度算法，则必须安装Nginx的hash软件包。
一、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
二、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
例如：
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
三、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
例如：
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
四、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backend {
server server1;
server server2;
fair;
}
五、困漏薯url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法
upstream backend {
server squid1:3128; // 10.0.0.10:7777
server squid2:3128; //10.0.0.11:8888
hash $request_uri;
hash_method crc32; }
二、Nginx负载均衡调度状态
在Nginx upstream模块中，可以设定每台后端服务器在负载均衡调度中的状态，常用的状态有：
1、down，表示当前的server暂时不参与负载均衡
2、backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的访问压力最低
3、max_fails，允许请求失败的次数，默认为1，当超过最大次数时，返回proxy_next_upstream模块定义的错误。
4、fail_timeout，请求失败超时时间，在经历了max_fails次失败后，暂停服务的时间。max_fails和fail_timeout可以一起使用。
如果Nginx没有仅仅只能代理一台服务器的话，那它也不可能像今天这么火，Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。具体配置过程如下：
1. 在http节点下，添加upstream节点。
upstream linuxidc {
server 10.0.6.108:7080;
server 10.0.0.85:8980;
}
2. 将server节点下的location节点中的proxy_pass配置为：http:// + upstream名称，即“
http://linuxidc”.
location / {
root html;
index index.html index.htm;
proxy_pass http://linuxidc;
}
3. 现在负载均衡初步完成了。upstream按照轮询（默认）方式进行负载，每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。虽然这种方式简便、成本低廉。但缺点是：可靠性低和负载分配不均衡。适用于图片服务器集群和纯静态页面服务器集群。
除此之外，upstream还有其它的分配策略，分别如下：
weight（权重）
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。如下所示，10.0.0.88的访问比率要比10.0.0.77的访问比率高一倍。
upstream linuxidc{
server 10.0.0.77 weight=5;
server 10.0.0.88 weight=10;
}
ip_hash（访问ip）
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstream favresin{
ip_hash;
server 10.0.0.10:8080;
server 10.0.0.11:8080;
}
fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。与weight分配策略类似。
upstream favresin{
server 10.0.0.10:8080;
server 10.0.0.11:8080;
fair;
}
url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
注意：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。
upstream resinserver{
server 10.0.0.10:7777;
server 10.0.0.11:8888;
hash $request_uri;
hash_method crc32;
}
upstream还可以为每个设备设置状态值，这些状态值的含义分别如下：
down 表示单前的server暂时不参与负载.
weight 默认为1.weight越大，负载的权重就越大。
max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.
fail_timeout : max_fails次失败后，暂停的时间。
backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
upstream bakend{ #定义负载均衡设备的Ip及设备状态
ip_hash;
server 10.0.0.11:9090 down;
server 10.0.0.11:8080 weight=2;
server 10.0.0.11:6060;
server 10.0.0.11:7070 backup;
}
感兴趣的小伙伴请关注我，我们一起学习，一起成长!
赞
⑽ nginx限流算法
1.令牌桶
算法思想：
*令牌以固定速率产生，并缓存到令牌桶中；
*令牌桶放满时，多余的令牌被丢弃；
*请求要消耗等比例的令牌才能被处理；
*令牌不够时，请求段辩被缓存。
2.漏桶
*来不及流出的水存在水桶中（缓冲），以固定速率流出；
*水桶满后水溢出（丢弃）。
*这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃。
总结：
相比漏桶算法，令牌桶算法不同之处在于它不但有一只“桶”握渣缺，还有个队列，这个桶是用来存放令牌的，队列才是用来存放请求的。 从作用上来说，漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理，漏桶算法能够强行限制数据的实时传输（处理）速率，对突发流量不做额处理；而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程梁埋度的突发传输。
Nginx按请求速率限速模块使用的是漏桶算法，即能够强行保证请求的实时处理速度不会超过设置的阈值。
Nginx主要有两种限速方式：按连接数限速(ngx_http_limit_conn_mole)、按请求速率限速(ngx_http_limit_req_mole)。
用php实现