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负载均衡详解”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！