nginx负载均衡详解
这篇文章主要介绍“nginx负载均衡详解”,在日常操作中,相信很多人在nginx负载均衡详解问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”nginx负载均衡详解”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
成都创新互联秉承实现全网价值营销的理念,以专业定制企业官网,成都网站建设、网站制作,小程序设计,网页设计制作,成都做手机网站,成都全网营销帮助传统企业实现“互联网+”转型升级专业定制企业官网,公司注重人才、技术和管理,汇聚了一批优秀的互联网技术人才,对客户都以感恩的心态奉献自己的专业和所长。
核心功能
上面简短的定义中我们大致可以看到两个内容:将请求分发,操作单元;其实就是控制器+执行器模式、Master+Worker模式等等,是不是很熟悉;当然一个成熟的负载均衡器不光有这两个核心功能,还有一些其他的功能,下面看看都有哪些核心功能:
操作单元配置 这里的操作单元其实就是上游的服务器,是真正来处理业务的执行者,这个需要可配置的(最好能支持动态配置),方便用户添加和删除操作单元;这些操作单元就是负载均衡器分发消息的对象;
负载均衡算法 既然需要分发,那具体通过何种方式把消息分给配置的执行器,这就需要有相关的分发算法了,比如我们常见的轮询、随机、一致性哈希等等;
失败重试 既然配置了多个执行单元,所以某台服务器宕机是大概率事件,这样我们在分发请求给某台已经宕机的服务器时,需要有失败重试功能,将请求重新分发给正常的执行器;
健康检查 上面的失败重试是只有真正转发的时候才知道服务器宕机了,是一种惰性策略,健康检查就是提前将宕机的机器排除掉,比如常见的通过心跳的方式去检查执行器是否还存活;
有了以上几个核心的功能,一个负载均衡器大致就形成了,可以把这几个原则用在很多地方,形成不同的中间件或者说内嵌在各种中间件中,比如接入层的LVS,F5,Nginx等,服务层各种RPC框架,消息队列RocketMQ、Kafka,分布式缓存redis、memcached,数据库中间件shardingsphere、mycat等等,这种分而治之的思路在各种中间件中广泛使用,下面对一些常见的中间件是如何做负载均衡的进行分析,大体上可以分为有状态和无状态两种类型;
无状态
执行单元本身没有状态,其实是更加容易去做负载均衡,每个执行单元都是一样的,常见的无状态的中间件有Nginx,RPC框架,分布式调度等;
接入层
Nginx可以说是我们最常见的接入层中间件了,提供四层到七层的负载均衡功能,提供了高性能的转发,对以上的几个核心功能提供了支持;
操作单元配置 Nginx提供了简单的静态的操作单元配置,如下:
upstream tomcatTest { server 127.0.0.1:8081; #tomcat-8081 server 127.0.0.1:8082; #tomcat-8082 } location / { proxy_pass http://tomcatTest; }
以上配置是静态的,如果需要添加或者删除,需要对Nginx重启,很不方便,当然也提供了动态的单元配置,需要借助第三方的服务注册中心比如Consul,etcd等;原理大致如下:
操作单元启动就会注册到Consul中,同样宕机会从Consul中移除;Nginx侧会启动一个Consul-template监听程序,监听Consul上操作单元的变更,然后更新Nginx的upstream,最好重加载upstream;
负载均衡算法 常见的比如:ip_hash,round-robin,hash;配置也很简单:
upstream tomcatTest { ip_hash //根据ip负载均衡,也就是常说的ip绑定 server 127.0.0.1:8081; #tomcat-8081 server 127.0.0.1:8082; #tomcat-8082 }
失败重试
upstream tomcatTest { server 127.0.0.1:8081 max_fails=2 fail_timeout=20s; } location / { proxy_pass http://tomcatTest; proxy_next_upstream error timeout http_500; }
当在fail_timeout内出现了max_fails次失败,表示此执行单元不可用;通过proxy_next_upstream配置,当出现配置的错误时,会重试下一台执行单元;
健康检查 Nginx通过集成nginx_upstream_check_module模块来进行健康检查;支持TCP心跳和Http心跳检测;
upstream tomcatTest { server 127.0.0.1:8081; check interval=3000 rise=2 fall=5 timeout=5000 type=tcp; }
interval:检测间隔时间; rise:检测成功多少次后,操作单元标识为可用; fall:检测失败多少次后,操作单元标识为不可用; timeout:检测请求超时时间; type:检测类型包括tcp,http;
服务层
服务层主要的就是微服务框架比如Dubbo,Spring Cloud等,内部都集成了负载均衡策略,使用起来也是非常方便;
操作单元配置 RPC框架一般都依赖注册中心组件,其实和Nginx通过注册中心来动态改变操作单元是一样的,RPC框架默认就已经依赖注册中心了,服务启动就注册到中心,服务不可用就移除,并且会自动同步到消费端,用户完全无感知,消费端要做的就是根据注册中心提供的服务列表,然后使用分发算法进行负载均衡;
负载均衡算法 Spring Cloud提供了Ribbon组件来实现负载均衡,而Dubbo直接内置均衡策略,常见的算法包括:轮询,随机,最少活跃调用数,一致性 Hash等等;比如dubbo配置轮询算法:
Ribbon配置随机规则:
@Bean public IRule loadBalancer(){ return new RandomRule(); }
失败重试 对于RPC框架来说其实就是容错机制,比如Dubbo内置了多种容错机制包括:Failover、Failfast、Failsafe、Failback、Forking、Broadcast;默认的容错机制就是Failover失败自动切换,当出现失败重试其它服务器;配置容错机制也很简单:
健康检查 注册中心一般都有健康检查功能,会实时检测服务器是否可用,如果不可用会移除,同时将更新推送给消费端;对用户来说完全无感知;
分布式调度将调度器和执行器分离,执行器也是通过注册中心的方式提供给调度器,然后由调度器进行负载均衡操作,流程已基本相似,此处不再一一介绍; 可以发现无状态的负载均衡其实更多情况以来注册中心,通过注册中心来动态的增减执行单元,从而很方便的达到扩容缩容;
有状态
有状态的执行单元相对于无状态来说更加有难度,因为每个节点的状态是整个系统的一部分,不是能随意增减的节点的;常见的有状态中间件有:消息队列,分布式缓存,数据库中间件等;
消息队列
现在高吞吐量,高性能的消息队列越来越成为主流,比如RocketMQ,Kafka等,有强大的水平扩展能力;RocketMQ中引入Message Queue机制,Kafka引入分区(Partition),一个Topic对应多个分区,采用分而治之的思路来提高吞吐量,性能;可以看一个RocketMQ的简易图:
操作单元配置 消息队列里面的操作单元其实就是这里的分区或者说Message Queue,比如RocketMQ是可以动态去修改读写队列的数量;RocketMQ还提供了rocketmq-console控制台,可以直接修改;
负载均衡算法 消息队列一般都有生产端和消费端,生产端默认是轮流给每个Message Queue发送消息,当然也可以自定义发送策略可以通过MessageQueueSelector来实现;消费端分配策略包括:分页模式(随机分配模式)、手动配置模式、指定机房模式、就近机房模式、统一哈希模式、环型模式;
失败重试 对于有状态的执行单元来说,不是说宕机就可以直接移除的,需要保证数据的完整性,正常来说一般都会做主备处理,主机挂了备机接管;以RocketMQ为例,每个分区都有各自的备份,RocketMQ采取的策略是,备区仅仅是做数据的完整性保证,消费者能消息备区的数据,但是并不会重新来接收数据;
健康检查 消息队列也有一个核心组件,可以理解为协调者,或者可以理解为注册中心,Kafka使用zookeeper,RocketMQ使用NameServer,里面其实就是保存了相关的对应信息比如Topic对应Message Queue,如果发现某台broker不可用,会将信息告知生产者,方式和注册中心类似;
分布式缓存
常见的分布式缓存有redis、memcached,为了能够容纳更多的数据一般都会做分片处理,分片的方式也是多种多样,就拿redis来说可以客户端做分片,基于代理的分片,还有官方提供的Cluster方案;
操作单元配置 缓存虽然也有有状态的,但是有其特殊性,其更多关注的是命中率,其实是可以容忍数据丢失的,比如基于代理的分片中间件codis,对客户端全透明不影响服务的情况下可以完成增减redis实例;
负载均衡算法 基于保证命中率的前提下,基于代理分片的方式一般都会采用一致性哈希算法;而redis官方提供的Cluster方案,因为其内置有16384个虚拟槽,所以直接使用取模即完成分片;
失败重试 有状态的分片一般都有会备区,在主区宕机后,备区接管实现故障迁移,比如redis的哨兵模式,或者codis这种中间件内置的功能;也无需去切换其他分区,对用户来说这种接管完全是无感知的;
健康检查 以redis为例,哨兵模式中,sentinel通过心跳的方式实时监测节点,通过客观下线来实施故障迁移;可以发现健康检查基本都是通过心跳来检测的方式;
数据库层
数据库层做均衡处理应该说是最复杂的,首先是有状态的,其次是数据的安全性至关重要,常见的数据库中间件包括:mycat,shardingjdbc等;
操作单元配置 以分表为例,这里的操作单元其实就是一个个分片数据表,数据量有时候往往出乎我们的预料,一般很少说固定给它分配多少个分片,最好是通过负载算法自动生成数据表,而且最好事先就评估好某种负载算法,不然后期如果想改变是很难的;
负载均衡算法 以mycat为例提供了多种负载算法:范围约定,取模,按日期分片,hash,一致性hash,分片枚举等等;比如下面的按天分区配置:
create_time sharding-by-date yyyy-MM-dd 2021-01-01 2051-01-01 10
指定了开始时间,结束时间,以及分区的天数;因为数据是随时间连续的,所以这种方式扩展性是很好的;如果是取模的方式就要考虑清楚分片的数量了,后面如果想改变分片数量就很麻烦了,不像缓存可以使用一致性hash来保证命中率就行了;
失败重试 有状态的节点,备库是少不了的,比如mycat提供了故障的主从切换功能,主宕机切换到从,基本都是这个套路,数据是不能丢的;
健康检查 同样的主动检测也必不可少,一般也是基于心跳语句去定时检测,然后做故障主从切换;
到此,关于“nginx负载均衡详解”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注创新互联网站,小编会继续努力为大家带来更多实用的文章!
网页题目:nginx负载均衡详解
网页URL:http://scyanting.com/article/jojsgo.html