文章宜信技术学院,宜信支付结算团队技术分享第一期——宜信支付结算八方数据团队高级技术经理周恒《Nginx的细枝末节》
分享者:宜信支付结算八方数据团队高级技术经理周恒
原文首发于支付结算技术团队公号:野指针
前篇 Nginx专题(1):Nginx之反向代理及配置详细介绍了Nginx功能之一,反向代理。本篇文章将重点介绍Nginx功能之二——负载均衡。
为了增加对负载均衡的好感,我们先了解负载均衡能实现什么。
<李>将多个服务器节点绑定在一起提供统一的服务入口。 <李>故障转移,在意外发生的时候,可以增加一层保险,减少损失。 <李>降低上线运维复杂度,实现平滑上线。运维和开发同学都喜欢。
下面正式进入主题。
一、Nginx的负载均衡策略
负载均衡就是将请求”均衡”地分配到多台业务节点服务器上。这里的“均衡”是依据实际场景和业务需要而定的。
对于Nginx来说,请求到达Nginx, Nginx作为反向代理服务器,有绝对的决策权,可以按照规则将请求分配给它知道的节点中的一个,通过这种分配,使得所有节点需要处理的请求量处于相对平均的状态,从而实现负载均衡。
Nginx支持的负载均衡策略很多,比较重点的如下:
<李>轮循(轮询) <李>随机(随机) <李>重量(权重) <李>公平(按响应时长,三方插件) <李> url_hash (url的散列值) <李> ip_hash (ip的散列值) <李> least_conn(最少连接数)
这么多的策略,非常不利于记忆和选择,我们不妨将这些常见的策略归类,分而化之,方便挑选。
第一类最佳实现
<李>重量(权重) <李>随机(随机)
最佳实践,其实就是最常见,最普通的默认配置,当然也是在一定程度上最好用的配置。不知道用什么方式的时候,就可以选择用这一类型。
轮询不用多说。这里的随机,其实在大量请求的情况下,按照概率的理论等同于轮询的方式。
轮询配置参考:
#默认配置就是轮询策略 upstream server_group { ,,server backend1.example.com; ,,server backend2.example.com; }随机配置参考:
{upstream server_group ,,,随机; ,,server backend1.example.com,, ,,server backend2.example.com,, ,,server backend3.example.com,, ,,server backend4.example.com; }第二类性能优先
<李>重量(权重) <李>公平(按响应时长,三方插件) <李> least_conn(最少连接数)
让业务节点中性能更强的机器得到更多请求,这也是一个比较好的分配策略。
什么是性能更好的机器?这个问题也有很多的维度去考量。
<李>从经验或硬件上分为高权重,低权重的机器。 <李>按照节点请求的响应时长来决定是多分配请求,还是少分配请求。 <李>按照保持的连接数。一般来说保持的连接数越多说明处理的任务越多,也是最繁忙的,可以将请求分配给其他机器处理。
权重的配置参考:
<>以前upstream server_group { ,,,server backend1.example.com 体重=5; ,,,#默认为不配置权重为1 ,,,server backend2.example.com; }响应的时长(公平)配置参考:需要在Nginx编译时加入nginx-upstream-fair模块。
<>以前upstream server_group { ,,公平; ,,server backend1.example.com,, ,,server backend2.example.com,, ,,server backend3.example.com,, ,,server backend4.example.com; }最少连接数(least_conn)配置参考:
<>以前upstream server_group { ,,,least_conn; ,,,server backend1.example.com; ,,,server backend2.example.com; }第三类保持稳定
<李> ip_hash李 <李> url_hash
很多请求都是有状态的,上一次请求到哪个业务节点,这次还要请求到哪台机器。比如常见的会话就是这样一种有状态的业务。
这里Nginx提供了按照客户端ip的散列来作为用户的标示分配,url的散列作为分配标示的规则。本质上还是要找到用户的请求中不变的要素,抽离出来,这样就可以进行分配了。
Nginx专题(2):Nginx的负载均衡策略及其配置
