引言
一个简单的请求响应过程：客户端发送多个请求到服务器，服务器处理请求，有一些可能要与数据库进行交互，服务器处理完毕后，再将结果返回给客户端。
这种架构模式对于早期的系统相对单一，并发请求相对较少的情况下是比较适合的，成本也低。但是随着信息数量的不断增长，尤其现在处于大数据时代，访问量和数据量的飞速增长，以及系统业务的复杂度增加，这种架构会造成服务器相应客户端的请求日益缓慢，并发量特别大的时候，还容易造成服务器直接崩溃。很明显这是由于服务器性能的瓶颈造成的问题，那么如何解决这种情况呢/p>
最直观的解决办法就是升级服务器的配置，比如提高CPU执行频率，加大内存等提高机器的物理性能来解决此问题，但是现在硬件的性能提升已经不能满足日益提升的需求了。最明显的一个例子，天猫双十一当天，某个热销商品的瞬时访问量是极其庞大的，那么类似上面的系统架构，将机器都增加到现有的顶级物理配置，还是不能够满足需求的。那么怎么办呢/p>
既然升级服务器的配置已经解决不了问题，那么我们就增加服务器的数量。但是仅仅增加服务器的数量，而请求还是都集中发送到其中一台服务器的话，服务器还是逃脱不了崩溃的命运，于是诞生了负载均衡。
负载均衡基本概念
负载均衡简单来说就是将用户的请求平均地分配到多个服务上，从而达到系统的高可用。
常见的负载均衡软件有：Nginx、LVS等。硬件有F5等。
? 访问页面：
-
修改nginx配置文件
在http块中添加upstream块，配置好服务名为myserver，并添加服务地址
修改server块，修改监听的服务以及代理的服务地址等信息
- 启动nginx测试
? 此时访问同一个资源会得到不同服务器返回的响应。
Nginx负载均衡的几种策略
-
轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器挂掉，能自动剔除。
-
weight （权重）
weight代表权重，默认为1，权重越高被分配的客户端越多 。（类似线程的调度策略，不过线程调度中是称为优先级）
这种方式能够指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
配置也很方便，将之前配置的upstream块中添加weight即可
-
ip_hash
每个请求按访问ip的hash结果分配，这样每个访客总是访问同一个后端服务器，可以解决用户session丢失的问题。
无法将权重（weight）与ip_hash联合使用来分发连接。如果两者都配置了，权重策略不会生效（这里用的1.16.1版本，老版本据说会直接报错）。
配置例如：
-
fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
第三方的负载均衡策略的实现需要安装第三方插件[nginx-upstream-fair]。
配置例如：
来源：椿尼
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！