互联网接入系统内的负载均衡系统可以解决哪些问题

互联网接入系统内的负载均衡系统可以解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；提供故障转移，实现高可用；通过添加或减少服务器数量，提供网站伸缩性（扩展性）；安全防护（负载均衡设备上做一些过滤，黑白名单等处理）。

实现负载均衡可以从硬件和软件两方面着手，在硬件上我们可以使用F5等负载均衡器，在软件上我们可以使用LVS、Nginx、HaProxy等负载均衡软件。使用硬件性能强悍，使用软件灵活智能。

用户请求数据包，到达负载均衡服务器后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法得到一台真实服务器地址，然后将请求目的地址修改为获得的真实IP地址，不需要经过用户进程处理。 真实服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器，再将数据包源地址修改为自身的IP地址，发送给用户浏览器。

负载均衡的原理

1、利用DNS，通过使用域名解析实现负载均衡

配置多个A 记录，这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析，作为第一级负载均衡。 显而易见，使用这种方式的负载均衡的控制权在域名商那里，不易拓展，并且用这种方式的负载不能很好的分流，有可能造成所有的请求都集中到一个节点上。不过，若作为第一层的负载均衡的确是个好办法。

2、利用HTTP进行负载均衡

当HTTP代理（比如浏览器）向WEB服务器请求某个URL后，WEB服务器可以通过HTTP响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理需要继续请求这个新的URL，完成自动跳转。

数通如何判断实现了负载均衡

一、前言

在互联网雄起的时代，随着各个网络请求量的不断增大，利用负载分化请求量，从而达到优化硬件负荷量的目的，一般负载分为软件负载和硬件负载，比如软件中使用nginx等工具实现负载均衡，而F5负载均衡器就是硬件网络性能优化设备。

二、何为负载均衡器

那么什么是F5负载均衡器呢，通俗的讲就是将客户端请求量通过F5负载到各个服务器，增加吞吐量，从而降低服务器的压力，他不同于交换机、路由器这些网络基础设备，而是建立在现有网络结构上用来增加网络带宽和吞吐量的的硬件设备

三、工作原理

1、客户发出服务请求到VIP

2、BIGIP接收到请求，将数据包中目的IP地址改为选中的后台服务器IP地址，然后将数据包发出到后台选定的服务器

3、后台服务器收到后，将应答包按照其路由发回到BIGIP

4、BIGIP收到应答包后将其中的源地址改回成VIP的地址，发回客户端，由此就完成了一个标准的服务器负载平衡的流程。

四、负载均衡涉及到算法

轮询算法：按照顺序将每个请求分发到每个服务器，相当于ngixn负载的轮训算法一个道理，当其中某个服务器发生第二到第7层的故障，BIGIP就把其从顺序循环队列中拿出，不参与下一次的轮训。

比率：指的是给每个服务器分配一个加权值，类似于权重，轮训会根据和这个权重去访问具体要到哪台服务器。

优先权：给所有服务器分组，BIGIP用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中所有服务器出现故障，BIGIP才将请求送给次优先级的服务器组。

最快模式：传递连接给那些响应最快的服务器。当发生异常故障时，BIGIP就会将其拿出来作为当前相应服务器，此时就不参与其他用户的请求轮训分配。

观察模式：以连接数和相应时间为准，当放生故障时BIGIP会将其拿出来作为请求的相应服务器，并且也不参与其他用户请求，直至恢复正常为止。

预测模式：BIGIP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。

动态性能分配:BIGIP收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。

动态服务器补充:当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。

服务质量：按不同的优先级对数据流进行分配。

服务类型：按不同的服务类型（在Type of Field中标识）对数据流进行分配。

规则模式：针对不同的数据流设置导向规则，用户可自行编辑流量分配规则，BIGIP利用这些规则对通过的数据流实施导向控制。

五。结尾

总之F5负载均衡器涉及到的原理内容多而杂，重点用户硬件负载方面，目前理解到此，还有很多不足之处希望一起发文讨论。

springgateway故障切换

负载均衡可以通过以下几个方面来进行判断：

1 请求分配均匀：如果负载均衡实现得好，那么在高负载情况下，每个服务器都应该承受相同数量的请求，没有服务器会被过度负载。

2 故障转移：负载均衡器应该能够检测到服务器的故障并将请求转移到其他可用的服务器，以确保服务的连续性。

3 负载监测：负载均衡器应该能够监测服务器的负载情况，以便在需要时调整流量分配。

4 可扩展性：负载均衡器应该能够支持添加更多的服务器来扩展应用程序的负载能力，而不会影响应用程序的性能。

综上所述，负载均衡的实现需要考虑多个方面，包括请求分配均匀、故障转移、负载监测和可扩展性等，只有在这些方面都得到了很好的处理，才能算是实现了负载均衡。

ribbon负载均衡详解

您好，我可以为您提供关于Spring Gateway故障切换的一些信息。

Spring Gateway是基于Spring框架开发的一款网关服务，主要用于构建微服务架构中的API网关。当微服务应用出现故障时，网关的故障切换机制可以帮助应对这种情况，防止整个系统崩溃。

Spring Gateway提供了一种名为“熔断器”的机制，它可以监控网关与后端服务之间的流量、响应时间和错误率等指标，一旦检测到某个服务出现故障，就可以触发熔断器，将请求自动切换到备用服务上，以保障系统的可用性。

以下是一些实现故障切换的步骤：

1 配置熔断。在网关配置文件中，添加相关的路由配置，设定熔断阈值、超时时间、失败率等参数。

2 配置备用服务。当主服务出现故障时，备用服务可以自动接手处理请求。需要注意的是，备用服务应该具备与主服务相同的接口定义和数据格式。

3 实现故障切换。在服务出现故障时，Spring Gateway会自动触发熔断器，将请求切换到备用服务上进行处理。同时，系统还应该记载并报告故障信息，以便进行及时修复和调试。

总之，Spring Gateway提供了灵活的故障切换机制，可以帮助构建高可用、健壮的微服务架构。要实现故障切换，需要综合考虑网络环境、服务负载、安全防护等多个因素，进行系统设计和配置。该过程需要有一定的技术能力和实践经验的支持。

RabbitMQ 镜像集群 宕机恢复、负载均衡、跨机房多活

服务端负载均衡：在客户端和服务端中间使用代理，lvs  和 nginx。

硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。

客户端负载均衡：根据自己的情况做负载。Ribbon。

客户端负载均衡和服务端负载均衡最大的区别在于 服务端地址列表的存储位置，以及负载算法在哪里。

2、Spring Cloud的负载均衡机制的实现

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Ribbon实现客户端的负载均衡，负载均衡器提供很多对http和tcp的行为控制。Spring cloud Feign已经集成Ribbon，所以注解@FeignClient的类，默认实现了ribbon的功能。

Ribbon主要包括如下功能

1支持通过DNS和IP和服务端通信

2可以根据算法从多个服务中选取一个服务进行访问

3通过将客户端和服务器分成几个区域（zone）来建立客户端和服务器之间的关系。客户端尽量访问和自己在相同区域(zone)的服务，减少服务的延迟

4保留服务器的统计信息，ribbon可以实现用于避免高延迟或频繁访问故障的服务器

5保留区域(zone)的统计数据，ribbon可以实现避免可能访问失效的区域(zone)

Ribbon负载均衡主要是通过LoadBalancerClient类实现的，而LoadBalancerClient又将具体处理委托给ILoadBalancer处理；

每个服务都有一个ILoadBalancer，ILoadBalancer里面有该服务列表。

每个服务 Map<服务名，ILoadBalancer>

ILoadBalancer通过配置IRule、IPing等信息，并通过ServerList获取服务器注册列表的信息，默认以每10s的频率想服务列表中每个服务实例发送ping请求，检测服务实例是否存活，最后使用负责均衡策略对ServerListFilter过滤得到最终可用的服务实例列表进行处理，然后交给服务调用器进行调用；

ILoadBalance也是一个接口，提供了3个具体实现，分别是DynamicServerListLoadBalancer、ZoneAwareLoadBalancer和NoOpLoadBalancer；

DynamicServerListLoadBalancer继承自ILoadBalancer基础实现baseLoadBalancer，在基础的负载均衡功能上增加了运行期间对服务实例动态更新和过滤的功能；

NoOpLoadBalancer没有操作的实现；

ZoneAwareLoadBalancer（ILoadBalancer的默认的实现类是：ZoneAwareLoadBalancer。）则是继承DynamicServerListLoadBalancer，在此基础上增加防止跨区域访问的问题；

首先它会剔除符合这些规则的Zone区域：所属实例数位零的Zone区域；Zone区域内实例等平均负载小于零，或者实例故障率（断路器断开次数／实例数）大于等于阀值（默认为099999）。

然后根据Zone区域等实例平均负载计算出最差的Zone区域，这里的最差指的是实例平均负载最高的Zone区域。

如果在上面的过程中没有符合剔除要求的区域，同时实例最大平均负载小于阀值（默认为20%），就直接返回所有Zone区域为可用区域。否则，从最坏Zone区域集合中随机选择一个，将它从可用Zone区域集合中剔除。

 ▪️当获得的可用Zone区域集合不为空，并且个数小于Zone区域总数，就随机选择一个Zone区域。

▪️在确定了某个Zone区域后，则获取了对应Zone区域的服务均衡器，并调用chooseServer来选择具体的服务实例，而在chooseServer中将使用IRule接口的choose函数来选择具体的服务实例。在这里，IRule接口的实现会使用ZoneAvoidanceRule来挑选出具体的服务实例。

服务列表就是客户端负载均衡所使用的(同一注册中心集群)各服务的服务实例列表。Ribbon在实现上支持以下几种服务列表方式

静态服务器列表：通过Ribbon的baseLoadBalancer所提供的setServerList()方法，初始化时直接进行动态设置指定；

基于配置的服务器列表：需要在项目配置文件中通过<服务名称>ribbonlistOfServers进行设置。（如user-serviceribbonlistOfServers=http://127001:8082,http://127001:8083）

基于服务发现的服务器列表：同时使用Ribbon和Eureka时，默认使用该方式，在应用启动时Ribbon就会从Eureka服务器中获取所有注册服务的列表数据，并保持同步。

该组件会对原始服务列表使用一定策略进行过滤返回有效可用的服务器列表给客户端负载均衡器使用。常用服务列表过滤器如下：ZoneAffinityServerListFilter：基于区域感知的方式，实现对服务实例的过滤，仅返回与本身所处区域一直的服务提供者实例列表；ServerListSubsetFilter：该过滤器继承自ZoneAffinityServerListFilter，在进行区域感知过滤后，仅返回一个固定大小的服务列表。默认将返回20个服务实例，可以通过ribbonServerListSubsetFiltersize进行设置；

ZonePreferenceServerListFilter：使用Eureka和Ribbon时默认的过滤器。实现通过配置或者Eureka所属区域来过滤出同区域的服务实例列表。

它实现了通过配置或者Eureka实例元数据的所属区域（Zone）来过滤出同区域的服务实例。如下面的源码所示，它的实现非常简单，首先通过父类ZoneAffinityServerListFilter的过滤器来获得“区域感知”的服务实例列表，然后遍历这个结果，取出根据消费者配置预设的区域Zone来进行过滤，如果过滤掉结果是空就直接返回父类获取的结果，如果不为空就返回通过消费者配置的Zone过滤后的结果。

用来检测一个微服务实例是否存活是否有响应，Ribbon通过该组件来判断所持有的服务实例列表中各服务可用情况，如果检测到某服务实例不存在/一定时间未响应，则会从持有服务列表中及时移除。

PingUrl：通过定期访问指定的URL判断；

PingConstant：不做任何处理，只返回一个固定值，用来表示该服务是否可用，默认值为true；

NoOpPing：不做任何处理，直接返回true，表示该服务器可用，默认策略；

DummyPing：直接返回true，但实现了initWithNiwsConfig方法；

NIWSDiscoverPing：根据DiscoveryEnabledServer中InstanceInfo的InstanceStatus属性判断，如果该属性的值为InstanceStatusUP，则表示服务器可用；

作用就是选择一个最终服务实例地址作为负载均衡处理结果。Ribbon提供的选择策略有随机 (Random)、轮询 (RoundRobin)、一致性哈希 (ConsistentHash)、哈希 (Hash)、加权（Weighted）。

IRule负载均衡策略：通过实现该接口定义自己的负载均衡策略。它的choose方法就是从一堆服务器列表中按规则选出一个服务器。

默认实现：

ZoneAvoidanceRule（区域权衡策略）：复合判断Server所在区域的性能和Server的可用性，轮询选择服务器。

其他规则：

BestAvailableRule（最低并发策略）：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务。逐个找服务，如果断路器打开，则忽略。

RoundRobinRule（轮询策略）：以简单轮询选择一个服务器。按顺序循环选择一个server。

RandomRule（随机策略）：随机选择一个服务器。

AvailabilityFilteringRule（可用过滤策略）：会先过滤掉多次访问故障而处于断路器跳闸状态的服务和过滤并发的连接数量超过阀值得服务，然后对剩余的服务列表安装轮询策略进行访问。

WeightedResponseTimeRule（响应时间加权策略）：据平均响应时间计算所有的服务的权重，响应时间越快服务权重越大，容易被选中的概率就越高。刚启动时，如果统计信息不中，则使用RoundRobinRule(轮询)策略，等统计的信息足够了会自动的切换到WeightedResponseTimeRule。响应时间长，权重低，被选择的概率低。反之，同样道理。此策略综合了各种因素（网络，磁盘，IO等），这些因素直接影响响应时间。

RetryRule（重试策略）：先按照RoundRobinRule(轮询)的策略获取服务，如果获取的服务失败则在指定的时间会进行重试，进行获取可用的服务。如多次获取某个服务失败，就不会再次获取该服务。主要是在一个时间段内，如果选择一个服务不成功，就继续找可用的服务，直到超时。

1 <clientName>：这是调用ribbon的客户端名称，如果此值为没有配置，则此条属性会作用到所有的客户端。

2 <nameSpace>：默认值为 “ribbon”

3 <propertyName>：所有的可用的属性都在comnetflixclientconfCommonClientConfigKey。

<clientName><nameSpace>NFLoadBalancerClassName=xx

<clientName><nameSpace>NFLoadBalancerRuleClassName=xx

<clientName><nameSpace>NFLoadBalancerPingClassName=xx

<clientName><nameSpace>NIWSServerListClassName=xx

<clientName><nameSpace>NIWSServerListFilterClassName=xx

comnetflixclientconfigIClientConfig：Ribbon的客户端配置，默认采用comnetflixclientconfigDefaultClientConfigImpl实现。

comnetflixloadbalancerIRule：Ribbon的负载均衡策略，默认采用comnetflixloadbalancerZoneAvoidanceRule实现，该策略能够在多区域环境下选出最佳区域的实例进行访问。

comnetflixloadbalancerIPing：Ribbon的实例检查策略，默认采用comnetflixloadbalancerNoOpPing实现，该检查策略是一个特殊的实现，实际上它并不会检查实例是否可用，而是始终返回true，默认认为所有服务实例都是可用的。

comnetflixloadbalancerServerList：服务实例清单的维护机制，默认采用comnetflixloadbalancerConfigurationbasedServerList实现。

comnetflixloadbalancerServerListFilter：服务实例清单过滤机制，默认采orgspringframeworkcloudnetflixribbonZonePreferenceServerListFilter，该策略能够优先过滤出与请求方处于同区域的服务实例。

comnetflixloadbalancerILoadBalancer：负载均衡器，默认采用comnetflixloadbalancerZoneAwareLoadBalancer实现，它具备了区域感知的能力。

上面的配置是在项目中没有引入spring Cloud Eureka，如果引入了Eureka和Ribbon依赖时，自动化配置会有一些不同。

通过自动化配置的实现，可以轻松的实现客户端的负载均衡。同时，针对一些个性化需求，我们可以方便的替换上面的这些默认实现，只需要在springboot应用中创建对应的实现实例就能覆盖这些默认的配置实现。

@Configuration

public class MyRibbonConfiguration {

    @Bean

    public IRule ribbonRule(){

        return new RandomRule();

    }

}

这样就会使用P使用了RandomRule实例替代了默认的comnetflixloadbalancerZoneAvoidanceRule。

也可以使用@RibbonClient注解实现更细粒度的客户端配置

对于Ribbon的参数通常有二种方式：全局配置以及指定客户端配置

全局配置的方式很简单

只需要使用ribbon<key>=<value>格式进行配置即可。其中，<key>代表了Ribbon客户端配置的参数名，<value>则代表了对应参数的值。比如，我们可以想下面这样配置Ribbon的超时时间

ribbonConnectTimeout=250

ribbonServerListRefreshInterval=2000   ribbon获取服务定时时间

全局配置可以作为默认值进行设置，当指定客户端配置了相应的key的值时，将覆盖全局配置的内容

指定客户端的配置方式

<client>ribbon<key>=<value>的格式进行配置<client>表示服务名，比如没有服务治理框架的时候（如Eureka），我们需要指定实例清单，可以指定服务名来做详细的配置，

user-serviceribbonlistOfServers=localhost:8080,localhost:8081,localhost:8082

对于Ribbon参数的key以及value类型的定义，可以通过查看comnetflixclientconfigCommonClientConfigKey类。

当在spring Cloud的应用同时引入Spring cloud Ribbon和Spring Cloud Eureka依赖时，会触发Eureka中实现的对Ribbon的自动化配置。这时的serverList的维护机制实现将被comnetflixniwsloadbalancerDiscoveryEnabledNIWSServerList的实例所覆盖，该实现会讲服务清单列表交给Eureka的服务治理机制来进行维护。IPing的实现将被comnetflixniwsloadbalancerNIWSDiscoveryPing的实例所覆盖，该实例也将实例接口的任务交给了服务治理框架来进行维护。默认情况下，用于获取实例请求的ServerList接口实现将采用Spring Cloud Eureka中封装的orgspringframeworkcloudnetflixribboneurekaDomainExtractingServerList，其目的是为了让实例维护策略更加通用，所以将使用物理元数据来进行负载均衡，而不是使用原生的AWS AMI元数据。在与Spring cloud Eureka结合使用的时候，不需要再去指定类似的user-serviceribbonlistOfServers的参数来指定具体的服务实例清单，因为Eureka将会为我们维护所有服务的实例清单，而对于Ribbon的参数配置，我们依然可以采用之前的两种配置方式来实现。

此外，由于spring Cloud Ribbon默认实现了区域亲和策略，所以，可以通过Eureka实例的元数据配置来实现区域化的实例配置方案。比如可以将不同机房的实例配置成不同的区域值，作为跨区域的容器机制实现。而实现也非常简单，只需要服务实例的元数据中增加zone参数来指定自己所在的区域，比如：

eurekainstancemetadataMapzone=shanghai

在Spring Cloud Ribbon与Spring Cloud Eureka结合的工程中，我们可以通过参数禁用Eureka对Ribbon服务实例的维护实现。这时又需要自己去维护服务实例列表了。

ribboneurekaenabled=false

由于Spring Cloud Eureka实现的服务治理机制强调了cap原理的ap机制（即可用性和可靠性），与zookeeper这类强调cp（一致性，可靠性）服务质量框架最大的区别就是，Eureka为了实现更高的服务可用性，牺牲了一定的一致性，在极端情况下宁愿接受故障实例也不要丢弃"健康"实例。

比如说，当服务注册中心的网络发生故障断开时候，由于所有的服务实例无法维护续约心跳，在强调ap的服务治理中将会把所有服务实例剔除掉，而Eureka则会因为超过85%的实例丢失心跳而触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数服务的正常消费。

在Camden版本，整合了spring retry来增强RestTemplate的重试能力，对于我们开发者来说，只需要简单配置，即可完成重试策略。

springcloudloadbalancerretryenabled=true

hystrixcommanddefaultexecutionisolationthreadtimeoutInMilliseconds=10000

user-serviceribbonConnectTimeout=250

user-serviceribbonReadTimeout=1000

user-serviceribbonOkToRetryOnAllOperations=true

user-serviceribbonMaxAutoRetriesNextServer=2

user-serviceribbonmaxAutoRetries=1

springcloudloadbalancerretryenabled:该参数用来开启重试机制，它默认是关闭的。

hystrixcommanddefaultexecutionisolationthreadtimeoutInMilliseconds：断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试。

user-serviceribbonConnectTimeout：请求连接超时时间。

user-serviceribbonReadTimeout：请求处理的超时时间

user-serviceribbonOkToRetryOnAllOperations：对所有操作请求都进行重试。

user-serviceribbonMaxAutoRetriesNextServer：切换实例的重试次数。

user-serviceribbonmaxAutoRetries：对当前实例的重试次数。

根据以上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由maxAutoRetries配置），如果不行，就换一个实例进行访问，如果还是不行，再换一个实例访问（更换次数由MaxAutoRetriesNextServer配置），如果依然不行，返回失败

项目启动的时候会自动的为我们加载LoadBalancerAutoConfiguration自动配置类，该自动配置类初始化条件是要求classpath必须要有RestTemplate这个类，必须要有LoadBalancerClient实现类。

LoadBalancerAutoConfiguration为我们干了二件事，第一件是创建了LoadBalancerInterceptor拦截器bean，用于实现对客户端发起请求时进行拦截，以实现客户端负载均衡。创建了一个

RestTemplateCustomizer的bean，用于给RestTemplate增加LoadBalancerInterceptor拦截器。

每次请求的时候都会执行orgspringframeworkcloudclientloadbalancerLoadBalancerInterceptor的intercept方法，而LoadBalancerInterceptor具有LoadBalancerClient（客户端负载客户端）实例的一个引用，

在拦截器中通过方法获取服务名的请求url（比如http://user-service/user），及服务名（比如user-service），然后调用负载均衡客户端的execute方法。

执行负载客户端RibbonLoadBalancerClient（LoadBalancerClient的实现）的execute方法，得到ILoadBalancer（负载均衡器）的实现ZoneAwareLoadBalancer，并且通过调用其chooseServer方法获得服务列表中的一个实例，比如说user-service列表注册到eureka中一个实例。然后向其中的一个具体实例发起请求，得到结果。

Ribbon详解 

https://wwwjianshucom/p/1bd66db5dc46

Spring cloud系列六 Ribbon的功能概述、主要组件和属性文件配置  

https://blogcsdnnet/hry2015/article/details/78357990

Ribbon的ZoneAwareLoadBalancer  

https://blogcsdnnet/chengqiuming/article/details/81209131

Ribbon的实际使用

https://wwwjianshucom/p/f86af82fa782

本人有道云笔记中记录的参考文章

文档：04_ribbon 负载均衡note

链接：http://noteyoudaocom/noteshareid=74e2434f21c3e96fb106be44fd8ed0b9&sub=2516B0E6DFEE4786B26D9528AF522928

常见的负载均衡技术

起因：在实际项目开发过程中，需要使用RabbitMQ来实现消息队列的功能，但仅仅实现功能之后并不能对自己满足，既然学一次，就要更深的了解她，吃一吃架构方面的相关内容，提升自己。

RabbitMQ在镜像集群中，机器其实是平行关系，所有的节点都是互相复制的

场景描述：

A是Master

B是Slave

A正常运行，B宕机了，只需要启动B即可，B就会自动加入集群

A和B都宕机了，只要A在B之前启动就可以了

A和B都宕机了，A启动不起来了，即便是B启动了，有可以B直接启动不了啦

B和C都加入了A为Master的集群，这个时候都需要将B和C从A的集群中forget，B和C启动不起来了

RabbitMQv32版本以后提供了一个离线清除集群节点的命令参数，也就是节点无法启动状态下

HAProxy是一款提供高可用的负载均衡器（之前大家都是使用的Nginx居多，upstream反向代理实现负载均衡非常容易），HAProxy可以基于TCP四层（Lvs也是TCP四层的），HTTP七层（Nginx是HTTP七层）的负载均衡应用代理软件，免费高速可靠的一种LBS解决方案

HAProxy的并发连接完全可以支持以万为单位的

Nginx

优点：

1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。

2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。

3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。

4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量。

5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。

6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。可作为静态网页和服务器，在高流量环境中稳定性也很好。

7、可作为中层反向代理使用。

缺点：

1、适应范围较小，仅能支持http、https、Email协议。

2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测

3、负载均衡策略比较少：轮询、权重、IP_hash、url_hash

HAProxy

优点：

1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段)

2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。

3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。

4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡。

5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种

缺点：

1、不支持POP/SMTP协议

2、不支持SPDY协议

3、不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。

4、重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。

5、多进程模式支持不够好

HAProxy+Keepalived（负载均衡节点的高可用）

将上面的配置文件内容放入 /etc/haproxy/haproxycfg中

启动HAProxy

启用成功后可以到控制台进行验证

通过federation的配置来进行数据通道搭建

这个时候你需要自己定义一个上游节点upstream(166节点)，一个下游节点downstream(167节点)，federation是单向发送的，相当于消息发送到upstream的一个exchange上，然后转发到downstream的queue上

1、 在下游节点创建一个exchage和一个queue和binding的routingkey，用来进行数据接收

2、 在下游节点建立federation upstream规则和上游节点进行数据同步

3、 进入下游节点的federation status没有任何数据，需要建立策略来保证通道连通

4、 进入下游节点的Policy菜单，Pattern是个正则表达式，这里表示以down开头的exchange和queue都匹配

5、 这个时候看exchange和queue，规则就应用上了

6、 这个时候去federation status看，发现上游连接已经连接上了

7、 这个时候我们先去看上游的overview

8、 再看上游的exchange和queue就已经根据下游配置的upstream和policy规则将exchange和queue创建好了

灰色的这个重定向exchange不能发送消息，如果要发送则在down-exchange上进行发送

9、 我们在上游的down-exchange发送一条消息，进行测试

可以在下游查看这条消息

10、 因为上游及节点只是一个中转，如果上游及诶单也要消息down-exchange里的消息怎么办？

只需要在本地建立一个binding关系就好

不要以为每天把功能完成了就行了，这种思想是要不得的，互勉~！

四层负责均衡：主要是指通过判断报文的IP地址和端口并通过一定的负载均衡算法来决定转发到哪个指定目标，主要工作在OSI模型的第四层。四层负载均衡对数据包只是起一个数据转发的作用，并不会干预客户端与服务器之间应用层的通信（如：三次握手等）。所以能对数据所进行的操作也就很少，但相对于七层负载均衡来讲效率会高上很多

七层负载均衡：也被称为“内容交换”，指的是负载均衡设备通过报文中的应用层信息(URL、HTTP头部等信息)和负载均衡算法，选择到达目的的内部服务器。七层负载均衡可以“智能化”地筛选报文中 应用层信息，然后根据不同的信息进行特定的负载均衡调度。这种方式提升了应用系统在网络层上的灵活性，另外也在一定程度上提升了后端系统的安全性。因为像网络常见的DoS攻击，这些攻击在七层负载均衡的环境下通常都在负载均衡设备上就截止了，不会影响到后台服务器的正常运行。

前网络中常见的负载均衡主要分为硬件负载均衡和软件负载均衡。硬件负载均衡比较知名的产品有F5 Big-IP、Cirtix Netscaler等等。而软件负载均衡就有着众多的开源项目，常见的有Haproxy、nginx、lvs等。

Haproxy：

lvs:

nginx:

Haproxy可以做代理服务相对于nginx而言有很多相同之处，统一可以基于mode tcp进行四层代理也可以基于mode http进行七层代理，但不同的是其无法使用location和if等进行匹配判断。突出优势在于有会话绑定，web管理界面，状态统计非常详细。官方推荐只启用一个进程，相对于nginx多进程架构工作并不理想，更多的线程可能会受到系统内存的一些限制。

程序环境：

主程序：/usr/sbin/haproxy

主配置文件：/etc/haproxy/haproxycfg

Unit file：/usr/lib/systemd/system/haproxyservice

查看配置文件

重要的几个参数，及性能调优，多数无需修改

发现日志发送给本机rsyslog的local2的facility，而本机的rsyslog里并没有定义，需要我们自己去配置

所以vim /etc/rsyslogconf添加一段将local2的所有信息记录在对应日志文件中

由于HAProxy可以工作在七层模型下，因此，要实现HAProxy的强大功能，一定要使用强大灵活的ACL规则，通过ACL规则可以实现基于HAProxy的智能负载均衡系统。HAProxy通过ACL规则完成两种主要的功能，分别是：

1）通过设置的ACL规则检查客户端请求是否合法。如果符合ACL规则要求，那么将放行；如果不符合规则，则直接中断请求。

2）符合ACL规则要求的请求将被提交到后端的backend服务器集群，进而实现基于ACL规则的负载均衡。HAProxy中的ACL规则经常使用在frontend段中，使用方法如下：

acl 自定义的acl 名称 acl 方法 -i [ 匹配的路径或文件] 其中：

·acl：是一个关键字，表示定义ACL规则的开始。后面需要跟上自定义的ACL名称。

·acl方法：这个字段用来定义实现ACL的方法，HAProxy定义了很多ACL方法，经常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。

·-i：表示不区分大小写，后面需要跟上匹配的路径或文件或正则表达式。与ACL规则一起使用的HAProxy参数还有use_backend，use_backend后面需要跟上一个backend实例名，表示在满足ACL规则后去请求哪个backend实例，与use_backend对应的还有default_backend参数，它表示在没有满足ACL条件的时候默认使用哪个后端

这些例子定义了www_policy、bbs_policy、url_policy三个ACL规则，第一条规则表示如果客户端以 wwwzcn 或 zcn 开头的域名发送请求时，则此规则返回true，同理第二条规则表示如果客户端通过 bbszcn 域名发送请求时，则此规则返回true，而第三条规则表示如果客户端在请求的URL中包含“buy_sid=”字符串时，则此规则返回true。

第四、第五、第六条规则定义了当www_policy、bbs_policy、url_policy三个ACL规则返回true时要调度到哪个后端backend，例如，当用户的请求满足www_policy规则时，那么HAProxy会将用户的请求直接发往名为server_www的后端backend，其他以此类推。而当用户的请求不满足任何一个ACL规则时，HAProxy就会把请求发往由default_backend选项指定的server_cache这个后端backend。

与上面的例子类似，本例中也定义了url_static、host_www和host_static三个ACL规则，其中，第一条规则通过path_end参数定义了如果客户端在请求的URL中以gif、png、jpg、css或js结尾时返回true，第二条规则通过hdr_beg（host）参数定义了如果客户端以www开头的域名发送请求时则返回true，同理，第三条规则也是通过hdr_beg（host）参数定义了如果客户端以img、video、download或ftp开头的域名发送请求时则返回true。

第四、第五条规则定义了当满足ACL规则后要调度到哪个后端backend，例如，当用户的请求同时满足host_static规则与url_static规则，或同时满足host_www和url_static规则时，那么会将用户请求直接发往名为static的后端backend，如果用户请求满足host_www规则，那么请求将被调度到名为www的后端backend，如果不满足所有规则，那么将用户请求默认调度到名为server_cache的这个后端backend。

log：全局的日志配置，local0是日志设备，info表示日志级别。其中日志级别有err、warning、info、debug4种可选。这个配置表示使用127001上的rsyslog服务中的local0日志设备，记录日志等级为info。

maxconn：设定每个HAProxy进程可接受的最大并发连接数，此选项等同于Linux命令行选项“ulimit -n”。

user/group：设置运行HAProxy进程的用户和组，也可使用用户和组的uid和gid值来替代。

daemon：设置HAProxy进程进入后台运行。这是推荐的运行模式。

nbproc：设置HAProxy启动时可创建的进程数，此参数要求将HAProxy运行模式设置为daemon，默认只启动一个进程。该值的设置应该小于服务器的CPU核数。创建多个进程，能够减少每个进程的任务队列，但是过多的进程可能会导致进程崩溃。

pidfile：指定HAProxy进程的pid文件。启动进程的用户必须有访问此文件的权限。

mode：设置HAProxy实例默认的运行模式，有tcp、http、health三个可选值。

retries：设置连接后端服务器的失败重试次数，如果连接失败的次数超过这里设置的值，HAProxy会将对应的后端服务器标记为不可用。此参数也可在后面部分进行设置。

timeout connect：设置成功连接到一台服务器的最长等待时间，默认单位是毫秒，但也可以使用其他的时间单位后缀。

timeout client：设置连接客户端发送数据时最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

timeout server：设置服务器端回应客户端数据发送的最长等待时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

timeout check：设置对后端服务器的检测超时时间，默认单位是毫秒，也可以使用其他的时间单位后缀。

bind：此选项只能在frontend和listen部分进行定义，用于定义一个或几个监听的套接字。bind的使用格式为： bind [<address>:<port_range>] interface <interface>其可以为主机名或IP地址，如果将其设置为“”或“0000”，将监听当前系统的所有IPv4地址。port_range可以是一个特定的TCP端口，也可是一个端口范围，小于1024的端口需要有特定权限的用户才能使用。interface为可选选项，用来指定网络接口的名称，只能在Linux系统上使用。

option httplog：在默认情况下，HAProxy日志是不记录HTTP请求的，这样很不方便HAProxy问题的排查与监控。通过此选项可以启用日志记录HTTP请求。

option forwardfor：如果后端服务器需要获得客户端的真实IP，就需要配置此参数。由于HAProxy工作于反向代理模式，因此发往后端真实服务器的请求中的客户端IP均为HAProxy主机的IP，而非真正访问客户端的地址，这就导致真实服务器端无法记录客户端真正请求来源的IP，而X-Forwarded-For则可用于解决此问题。通过使用forwardfor选项，HAProxy就可以向每个发往后端真实服务器的请求添加X-Forwarded-For记录，这样后端真实服务器日志可以通过“X-Forwarded-For”信息来记录客户端来源IP。

option httpclose：此选项表示在客户端和服务器端完成一次连接请求后，HAProxy将主动关闭此TCP连接。这是对性能非常有帮助的一个参数。

log global：表示使用全局的日志配置，这里的global表示引用在HAProxy配置文件global部分中定义的log选项配置格式。

default_backend：指定默认的后端服务器池，也就是指定一组后端真实服务器，而这些真实服务器组将在backend段进行定义。这里的htmpool就是一个后端服务器组。

option redispatch：此参数用于cookie保持的环境中。在默认情况下，HAProxy会将其请求的后端服务器的serverID插入cookie中，以保证会话的session持久性。而如果后端的服务器出现故障，客户端的cookie是不会刷新的，这就会出现问题。此时，如果设置此参数，就会将客户的请求强制定向到另外一台健康的后端服务器上，以保证服务正常。

option abortonclose：如果设置了此参数，可以在服务器负载很高的情况下，自动结束当前队列中处理时间比较长的连接。

-balance：此关键字用来定义负载均衡算法。目前HAProxy支持多种负载均衡算法，常用的有如下几种：

cookie：表示允许向cookie插入SERVERID，每台服务器的SERVERID可在下面的server关键字中使用cookie关键字定义。

option httpchk：此选项表示启用HTTP的服务状态检测功能。HAProxy作为一个专业的负载均衡器，它支持对backend部分指定的后端服务节点的健康检查，以保证在后端backend中某个节点不能服务时，把从frotend端进来的客户端请求分配至backend中其他健康节点上，从而保证整体服务的可用性。

option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各个参数的含义如下：

check：表示启用对此后端服务器执行健康状态检查。

inter：设置健康状态检查的时间间隔，单位为毫秒。

rise：设置从故障状态转换至正常状态需要成功检查的次数，例如，“rise 2”表示2次检查正确就认为此服务器可用。

fall：设置后端服务器从正常状态转换为不可用状态需要检查的次数，例如，“fall 3”表示3次检查失败就认为此服务器不可用。

cookie：为指定的后端服务器设定cookie值，此处指定的值将在请求入站时被检查，第一次为此值挑选的后端服务器将在后续的请求中一直被选中，其目的在于实现持久连接的功能。上面的“cookie server1”表示web1的serverid为server1。同理，“cookie server2”表示web2的serverid为server2。

weight：设置后端真实服务器的权重，默认为1，最大值为256。设置为0表示不参与负载均衡。

backup：设置后端真实服务器的备份服务器，仅仅在后端所有真实服务器均不可用的情况下才启用。

用nginx反代后端的两台tomcat主机，做动静分离，如果是jsp结尾的就发往后端，否则就交给nginx处理。

在两台tomcat主机上创建应用

nginx配置

则动静分离就实现了，并且我们还基于uri实现了会话粘性