负载均衡

最近要搭建一个高并发的网站。所以，得设计负载均衡这一块。从大的方向上讲，负载均衡分为硬负载均衡，和软负载均衡。下面依次简要说明一下： 硬负载均衡 ： 硬负载均衡，也就是使用专用的负载均衡设备。主流的硬负载均衡器有如下几种： F5 ：最主流的硬负载均衡器。便宜的20万以上，贵的100多万。 深信服 ：乞丐版低配12万元起价。 A10 ：基本都在100万元以上。 Array ：16-100万。 看这价格就知道，硬负载均衡，一般的中小公司，都会被价格折磨、然后犹豫、最后放弃。 软负载均衡 ： 软软负载均衡，也就是，不使用专用的负载均衡设备，而是通过软件来实现负载均衡。常用的有如下几种： DNS ：最原始的负载均衡方式，名字就已经说明了一切，不用细说了。 LVS ：最常用的软件负载均衡。我见过的国内百万级用户的架构，基本都是靠它顶的。 Nginx ：也是现在流行的、常用的负载均衡方案之一。 转载于:https://www.cnblogs.com/welcomer/p/5068349.html 来源： https://blog.csdn.net/weixin_30832143/article/details/98753863

负载均衡 负载均衡是我们大流量网站要做的一个东西，下面我来给大家介绍在Nginx服务器上进行负载均衡配置方法，希望对有需要的同学有所帮助哦。 先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。 负载均衡的类别 轮询 -应用程序轮流来响应请求(nginx默认采用) 最少连接 -请求被分配到活动连接最少的服务器上 ip-hash -通过一个hash函数决定哪个服务器来响应用户的请求（依据客户端的请求ip） 准备测试环境 由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。 测试域名 ：a.com A服务器IP ：192.168.5.149 （主） B服务器IP ：192.168.5.27 C服务器IP ：192.168.5.126 部署思路 A服务器做为主服务器，域名直接解析到A服务器（192.168.5.149）上，由A服务器负载均衡到B服务器（192.168.5.27）与C服务器（192.168.5.126）上。 域名解析 由于不是真实环境，域名就随便使用一个a.com用作测试，所以a.com的解析只能在hosts文件设置。 打开：C

阿里云负载均衡目前支持设置4层的【端口后端健康ECS实例数】的规则告警和【7层协议端口5XX状态码】 和 【7层协议端口Upstream 5XX状态码】 的规则告警，Upstream的这个是基于rs返回给slb的5xx状态码统计，这个可以满足我们之前提到的那个监控需求，详情参考： https://help.aliyun.com/document_detail/28588.html 来源： https://www.cnblogs.com/robinunix/p/11315825.html

随着越来越多的应用架构解耦变为分布式的，在组件横向扩展能力提高的同时对负载均衡设备的要求和依赖性也越来越高，同时更要求负载均衡设备有强大的横向扩展能力。负载均衡集群技术变得越来越重要。虽然很多厂商提供各种Cluster技术，但是能够真正简化管理、实现智能流量调度的唯有Netscaler是做的最独特的。 在讨论集群技术之前，我们先聊一下负载均衡高可用技术： 高可用技术包含以上这么几大类 主/备：很常见的方案，就是两台ADC做双机部署，同一时间只有一台工作，另一台做热备。缺点是有点浪费资源，不支持同时故障2台以上的设备。 主/主：基于VRRP的技术，相对较少的方案。如果还是2台设备，只是心里上感觉设备利用率提高了，殊不知每台的吞吐量依旧不能超越50%，否则故障一台会出现丢弃业务的情况。如果是多台的话可以做所谓的M:N，但是配置复杂，业务切换受网络收敛时间（arp表老化及交换机卡死）的影响，存在短时丢失业务的风险。 GSLB：基于Site的高可用，不能解决站点内部的高可用。 Cluster：新兴的高可用技术。 首先了解一下什么是集群？这个就很简单了，不清楚的请问一下度娘。今天重点要讨论的是Netscaler的集群。 Netscaler于2007年将架构彻底转变为nCore，尽管当时依旧是传统的HA部署模式，但这已转变为日后Cluster的技术领先奠定了坚实的技术基础

说明 构建RabbitMQ集群来确保可用性和性能只是保障弹性消息通信基础架构的一半，另一半则是编写当集群节点发生故障时知道如何重连到集群的应用程序。 处理到集群的重连有多种策略，这篇wiki所关注的这种是使用负载均衡来处理节点的选择。 使用负载均衡的意义 通过使用负载均衡，不仅可以减少应用程序处理节点故障代码的复杂性，又能确保在集群中连接的平均分布。 但是即便使用了负载均衡，编写处理节点故障的应用程序也要比建立到集群的连接复杂的多，应用程序需要准备好重新创建交换器和队列以应对初始节点故障。 为Rabbit做负载均衡 当为RabbitMQ添加负载均衡时，集群节点就作为负载均衡背后的服务器，而生产者和消费者就是客户了。应用程序只需要知道负载均衡器的ip（或域名），负载均衡就会以最小的连接负载透明地将客户端连接到集群节点。 如果想要为集群增强性能，则无须更改应用程序，只需要新增rabbit节点并挂到负载均衡上即可，无须修改应用程序。 如果没有负载均衡的话，应用程序就不得不对每一个集群节点的IP做手工配置，同时也不得不自行处理集群节点的选择和故障服务器检测。由于每个应用程序需要自行选择节点，因此你就无法在集群内将负载平均分配。 通过将负载均衡放置在Rabbit集群的前端，就可以让负载均衡器自行处理节点选择（轮询或者最小连接、rabbit节点挂掉后自行摘除）。

七层负载均衡 简单解说： ============================================================== 一、集群的分类：（cluster） 1、高可用集群 HA high availability 避免单节点故障 软件：keepalived 2、负载均衡集群 LB load balance 提高负载，提高并发量 软件：nginx反向代理 lvs 硬件：硬件负载均衡器 F5(BigIP)和redware 3、 HPC高性能运算集群 4、分布式存储集群 极大的提升存储容量，提供数据高可用，保证数据安全 软件：ceph glusterfs hdfs 二、Nginx proxy 是 Nginx 的王牌功能,利用 proxy 基本可以实现一个完整的 7 层负载均。 功能强大,性能卓越,运行稳定。 配置简单灵活。 能够自动剔除工作不正常的后端服务器。 上传文件使用异步模式。 支持多种分配策略,可以分配权重,分配方式灵活。 三、七层负载均衡与四层负载均衡： lvs和nginx的区别： nginx： nginx可以用来做http的反向代理，在配置文件中使用upstream实现http请求的多种方式的均衡转发。 由于采用的是 异步转发 可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止

需求： 现在有个需求：两台服务器，建立负载均衡。 A服务器：IP：localhost；负载均衡主服务器；代理本地文件夹D:\\SampleData B服务器：IP：10.10.10.10；代理本地文件夹D:\\SampleData 解决方案： 本来想启动一个nginx搞定问题，但是搜集资料发现，nginx负载均衡指向的都是ip地址，没有本地+ip的负载均衡方式。（不知到底有没有这样的方法） 故本文采用主服务器上启两个nginx，分别给不同端口，一个代理本地文件夹，一个做负载均衡。 操作： 1、A服务器上启动一个nginx代理，端口改为8088；（代理设置不会的，参看前一篇博文 https://www.cnblogs.com/giser-s/p/11308680.html ） 2、B服务器上启动一个nginx代理，端口改为8088； 3、A服务器上重新复制粘贴一份到另外的位置，再启动一个nginx代理，端口默认80，修改nginx.conf； 4、A服务器上重新读取一下配置文件，并重启 5、A服务器上输入http://localhost进行验证 说明： 负载均衡有不同的设置： 1、热备：当A服务器出故障时，才会切到B服务器。AAA中断BBB upstream mysvr { 　　server A; 　　server B backup; } 2、轮询：默认服务器会默认按顺序调用服务

1.由于要撤销一组负载均衡，所以需要更改阿里云域名解析台里某个域名由原来绑定的负载均衡公网IP换到服务器公网IP 2.在服务器上nginx指定了域名访问，开启nginx服务 3.暂时关闭该组负载均衡服务 4.实现通过服务器IP可以访问项目，域名访问不了 5.在本机上域名解析出来的IP还是原来负载均衡的IP 6. 7.按照以上方式，清空本地DNS缓存之后再对域名进行解析 本文转自 guowang327 51CTO博客，原文链接：http://blog.51cto.com/guowang327/1856503，如需转载请自行联系原作者 来源： CSDN 作者： weixin_33966365 链接： https://blog.csdn.net/weixin_33966365/article/details/89770460

Nginx其中一大特性就是负载均衡，它可以通过扩展它代理的连接来保护你的上游服务器免于过载等问题。 负载均衡算法 upstream模块能够使用3种负载均衡： 1. 轮询 rountd-robin ）: 在默认情况下，使用轮询算法，它可以不需要配置指令来启用它。该算法选择下一个服务器，基于先前选择，在配置文件中哪一个是下一个服务器，以及每一个服务器的负载权重。轮询算法是基于在队列中谁是下一个的原理确保将访问量均匀地分配给每一个上游服务器的。 2. IP哈希（IP hash）： 通过ip_hash指令启用它，从而将某些IP地址映射到同一个上游服务器。Nginx通过IPv4地址的前3个字节或整个IPv6地址作为哈希键来实现，同一个IP地址池地址总是被映射到同一个上游服务器，所以，这个机制的目的不是要确保公平分配给每一个上游服务器，而是在客户端和上游服务器之间实现一致映射，在上游服务器中，主要应用在具有会话的应用中非常有用。 3. 最少连接数（Least Connection）： 通过least_conn指令启用，该算法的目的是通过选择一个活跃的最少连接数服务器，然后将负载均衡均匀分配给上游服务器。如果上游服务器服务器的处理器能力不相同，那么可以为server指令使用weight参数来控制权重，该算法主要应用在不同服务器配置中。 示例如下： upstream servers {

一、 先准备两个jar ；用的是sprinboot 打包两个jar，一个端口为8081 一个为8082,两个tomcat也是可以的； 二、 打包的步骤如下 ： 只需要把yml的配置文件的端口号 改一下，打包两次即可 三、打包成后之后如下图： 四、用rz命令 进行将jar上传 ps:有些同学可能执行rz命令 则提示找不到该命令，则 执行如下：yum install lrzsz -y 参考网址：https://blog.csdn.net/gosenkle/article/details/81197362 五、用命令依次启动这个两个jar包：命令如下： nohup java -Xms24M -Xmx24M -jar 8081.jar > 8081.log 2>&1 & tail -f 8081.log nohup java -Xms24M -Xmx24M -jar 8082.jar > 8082.log 2>&1 & tail -f 8082.log 六 、以上工作准备完成之后，进入到Nginx的配置文件进行配置； 　　进入目录：cd /usr/local/nginx/conf ---》》 vim nginx.conf 七、 找到htpp块，进行如下配置 八、 如果用 http:ip:80这样 如： http://192.168.1.20 会报如下错误： 使用阿里云的同学们