Nginx量化接口,负载均衡配置
简单的配置实例
详解
2-1项目实际应用案例
2-1-1启动两个后端服务
// 这里准备了两个springboot工程,编写2个测试的后端接口,以端口号区分
// 后端服务1 ,端口8082
@RestController
@RequestMapping("/api")
public class NginxController1 {
@GetMapping
public String test1(){
return "success test1 8082";
}
}
// 后端服务2 ,端口8081
@RestController
@RequestMapping("/api")
public class NginxController1 {
@GetMapping
public String test1(){
return "success test1 8081";
}
}
2-1-2nginx.conf进行配置
2-1-3重新启动Nginx,访问localhost:80,会轮询访问8081和8082服务器
2-2量化接口,负载均衡配置说明
默认情况下,直接按照上面的配置后,
如果后端有多个服务,采用的是轮询策略;
常用的可选配置包括:
weight ==> 多台服务时,供配置权重值,权重高的服务将会优先被访问
down ==> 某个服务配置down之后,这台服务将不会被访问
backup ==> 配置这个参数后,除非其他的服务都挂掉了,否则这台服务将不会被访问到
以 weight 为例做简单的说明,在上面的配置中,补充weight参数
upstream webservers{
server 192.168.9.134:8081 weight=8;
server 192.168.9.134:8082 weight=2;
}
重新加载配置,按照上面的测试步骤再次刷新页面,
这时候可以发现,8081服务将会被更多的访问到;
2-3其他负载均衡配置策略
# 1. ip_hash
# 每个请求按访问IP的hash结果进行分配,
# 这样每个访客就可以固定访问一个后端服务,一定程度上可以解决session问题;
upstream webservers {
<!--{cke_protected}{C}%3C!%2D%2D%20%2D%2D%3E-->
ip_hash;
server 192.168.9.134:8081;
server 192.168.9.134:8082;
}
# 2. weight
# weight代表权重,默认为1,权重越高,被分配的客户端请求就会越多
upstream webservers{
server 192.168.9.134:8081 weight=8;
server 192.168.9.134:8082 weight=2;
}
# 3. fair(第三方)
# 按后端服务器的响应时间来分配请求,响应时间短的将会被优先分配
upstream webservers{
server 192.168.9.134:8081;
server 192.168.9.134:8082;
fair;
}
# 4. url_hash
# 按访问URL的hash结果分配。这样相同的url会被分配到同一个节点,
# 主要为了提高缓存命中率。比如,为了提高访问性能,服务端有大量数据或者资源文件需要被缓存。
# 使用这种策略,可以节省缓存空间,提高缓存命中率
upstream webservers{
hash &request_uri;
server 192.168.9.134:8081;
server 192.168.9.134:8082;
}
# 5. least_conn
# 按节点连接数分配,把请求优先分配给连接数少的节点。
# 该策略主要为了解决,各个节点请求处理时间长短不一造成某些节点超负荷的情况。
upstream webservers{
least_conn;
server 192.168.9.134:8081;
server 192.168.9.134:8082;
}
# 以上不同的负载均衡策略均有各自不同的使用场景,请结合自身的实际情况进行合理的选择,
# 同时,各自配置策略在实际使用的时候也不是孤立的,比如最小连接数可以搭配权重数一起使用
文章为作者独立观点,不代表 股票程序化软件自动交易接口观点