负载均衡调度算法

① keepalived怎么重新加载配置文件

keepalived.conf内容说明如下

●全局定义块
1、email通知。作用：有故障，发邮件报警。
2、Lvs负载均衡器标识（lvs_id）。在一个网络内，它应该是唯一的。
3、花括号“{}”。用来分隔定义块，因此必须成对出现。如果写漏了，keepalived运行时，不会得到预期的结果。由于定义块内存在嵌套关系，因此很容易遗漏结尾处的花括号，这点要特别注意。
●VRRP定义块
1、同步vrrp组vrrp_sync_group。作用：确定失败切换（FailOver）包含的路由实例个数。即在有2个负载均衡器的场景，一旦某个负载均衡器失效，需要自动切换到另外一个负载均衡器的实例是哪些？
2、实例组group。至少包含一个vrrp实例。
3、Vrrp实例vrrp_instance。实例名出自实例组group所包含的那些名字。
(1) 实例状态state。只有MASTER和BACKUP两种状态，并且需要大写这些单词。其中MASTER为工作状态，BACKUP为备用状态。当 MASTER所在的服务器失效时，BACKUP所在的系统会自动把它的状态有BACKUP变换成MASTER；当失效的MASTER所在的系统恢复 时，BACKUP从MASTER恢复到BACKUP状态。
(2)通信接口interface。对外提供服务的网络接口，如eth0,eth1.当前主流的服务器都有2个或2个以上的接口，在选择服务接口时，一定要核实清楚。
(3)lvs_sync_daemon_inteface。 负载均衡器之间的监控接口，类似于HA HeartBeat的心跳线。但它的机制优于Heartbeat，因为它没有“裂脑”这个问题，它是以优先级这个 机制来规避这个麻烦的。在DR模式中，lvs_sync_daemon_inteface 与服务接口interface 使用同一个网络接口。
(4)虚拟路由标识virtual_router_id。这个标识是一个数字，并且同一个vrrp实例使用唯一的标识。即同一个vrrp_stance，MASTER和BACKUP的virtual_router_id是一致的，同时在整个vrrp内是唯一的。
(5)优先级priority。这是一个数字，数值愈大，优先级越高。在同一个vrrp_instance里，MASTER 的优先级高于BACKUP。若MASTER的priority值为150，那么BACKUP的priority只能是140或更小的数值。
(6)同步通知间隔advert_int。MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位为秒。
(7)验证authentication。包含验证类型和验证密码。类型主要有PASS、AH两种，通常使用的类型为PASS，据说AH使用时有问题。验证密码为明文，同一vrrp实例MASTER与BACKUP 使用相同的密码才能正常通信。
4、 虚拟ip地址virtual_ipaddress。可以有多个地址，每个地址占一行，不需要指定子网掩码。注意：这个ip必须与我们在lvs客户端设定的vip相一致！
●虚拟服务器virtual_server定义块
虚拟服务器定义是keepalived框架最重要的项目了，是keepalived.conf必不可少的部分。
1、虚拟服务器virtual_server。这个ip来自于vrrp定义块的第“4”步，后面一个空格，然后加上端口号。定义一个vip，可以实现多个tcp端口的负载均衡功能。
(1)delay_loop。健康检查时间间隔，单位是秒。
(2)lb_algo。负载均衡调度算法，互联网应用常使用wlc或rr。
(3)lb_kind。负载均衡转发规则。一般包括DR、NAT、TUN3种，在我的方案中，都使用DR的方式。
(4)persistence_timeout。 会话保持时间，单位是秒。这个选项对动态网站很有用处：当用户从远程用帐号进行登陆网站时，有了这个会话保持功能，就能把用户的请求转发给同一个应用服务 器。在这里，我们来做一个假设，假定现在有一个lvs 环境，使用DR转发模式，真实服务器有3个， 负载均衡器不启用会话保持功能。当用户第一次访问的时候，他的访问请求被负载均衡器转给某个真实服务器，这样他看到一个登陆页面，第一次访问完毕；接着他 在登陆框填写用户名和密码，然后提交；这时候，问题就可能出现了---登陆不能成功。因为没有会话保持，负载均衡器可能会把第2次的请求转发到其他的服务器。
(5)转发协议protocol。一般有tcp和udp两种。实话说，我还没尝试过udp协议类的转发。
2、真实服务器real_server，也即服务器池。Real_server的值包括ip地址和端口号，多个连续的真实ip。
(1)权重weight，权重值是一个数字，数值越大，权重越高。使用不同的权重值的目的在于为不同性能的机器分配不同的负载，性能较好的机器，负载分担大些；反之，性能差的机器，则分担较少的负载，这样就可以合理的利用不同性能的机器资源。
(2)Tcp检查tcp_check。

第③版更新内容如下:
每台服务器都有二块网卡，分别连接内外网；后端的mysql数据库与web连接采用内网方式，整个网络环境采用内网；
增加了keepalived.conf语法内容；
删除了lvs.sh脚本内容，直接让keepalived内容更直接明了；
lvs主从机上的keepalived.conf文件我直接从生产服务器上download下来了，可方便大家使用。

※值得注意的是：
1、你必须向你的服务器所在机房IDC多申请一个IP供VIP使用；多关注/var/log/messages和ipvsadm -ln，利用其有效信息排错。
2、服务器的iptables、Selinux均关闭；在生产环境中，我就遇到了iptables的NAT转发问题，导致了lvs失败。
3、 keepalived的启动过程并不会对配置文件进行语法检查，就算没有配置文件，keepalived的守护进程照样能够被运行起来。在默认状态下，即 不指定配置文件的位置--keepalived先查找文件/etc/keepalived/keepalived.conf。
4、session的过程默认是以文件的形式存在，在浏览器关闭或重启时删除；会话保持我建议写成120秒，如果这个值设置得不合理，用户将得到非常糟糕的访问效果。
5、 keepalived是lvs的扩展项目，因此它们之间具备良好的兼容性，这点应该是keepalived部署比其他类似工具能更简洁的原因 吧，lvs+keepalived目前是一个应用于生产环境的成熟架构，实现了真正意义上的负载均衡高可用，尤其适用于bbs和blog(它们均是访问频 繁，用户量大的对象)，建议熟练掌握。

LVS 算法说明

LVS的常见八种调度算法：
一:轮叫调度（Round-Robin Scheling）

轮叫调度（Round Robin Scheling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

二:加权轮叫调度（Weighted Round-Robin Scheling）

加权轮叫调度 （Weighted Round-Robin Scheling）算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，服务器的缺省权值为1。假设服务器A的权值为1，B的权值为2，则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接，权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。

三:最小连接调度（Least-Connection Scheling）

最 小连接调度（Least- Connection Scheling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调 度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。
四:加权最小连接调度（Weighted Least-Connection Scheling）

加权最小连接调 度（Weighted Least-Connection Scheling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

五:基于局部性的最少链接（Locality-Based Least Connections Scheling）

基 于局部性的最少链接调度（Locality-Based Least Connections Scheling，以下简称为LBLC）算法是针对请 求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服 务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和 主存Cache命中率，从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的 且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将 请求发送到该服务器。

六: 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication Scheling）

带 复制的基于局部性最少链接调度（Locality- Based Least Connections with Replication Scheling，以下简称为LBLCR）算法也是针对目标 IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护 从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会 从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站点到这台Cache服务器，很快这台Cache服务器也会超 载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现在所有的Cache服务器上，降低了Cache服务器的使用 效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增加时，会增加集合里的Cache服务 器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器数目。这样，该“热门”站点的映像不太可能出现在所有的 Cache服务器上，从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP 地址找出该目标IP地址对应的服务器组；按“最小连 接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按 “最小连接”原则从整个集群中选出一台服务器，将 该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

七:目标地址散列调度（Destination Hashing Scheling）

目 标地址散列调度 （Destination Hashing Scheling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过 一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分 配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

八:源地址散列调度（Source Hashing Scheling）

源 地址散列调度（Source Hashing Scheling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键 （Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址 散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址，所以这里不一一叙述。在实际应用 中，源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

此文出处抚琴煮酒之网络博客

② 常见的负载均衡技术

四层负责均衡：主要是指通过判断报文的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/haproxy.cfg
Unit file：/usr/lib/systemd/system/haproxy.service

查看配置文件

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

发现日志发送给本机rsyslog的local2的facility，而本机的rsyslog里并没有定义，需要我们自己去配置
所以vim /etc/rsyslog.conf添加一段将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规则，第一条规则表示如果客户端以 www.z.cn 或 z.cn 开头的域名发送请求时，则此规则返回true，同理第二条规则表示如果客户端通过 bbs.z.cn 域名发送请求时，则此规则返回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种可选。这个配置表示使用127.0.0.1上的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地址，如果将其设置为“*”或“0.0.0.0”，将监听当前系统的所有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实现了会话粘性

③ 什么是负载均衡有啥优缺点

一、什么是负载均衡

负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

二、负载均衡的优点

减少服务器的压力，将原本一台服务器索要承受的访问量分给多台，并提高项目的可用性，当一台服务器挂掉的时候不会导致项目瘫痪。

三、四层负载均衡和七层负载均衡



四层负载均衡工作在OSI模型的传输层，主要工作是转发，它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。

七层负载均衡工作在OSI模型的应用层，因为它需要解析应用层流量，所以七层负载均衡在接到客户端的流量以后，还需要一个完整的TCP/IP协议栈。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求流量解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去，因此七层负载均衡的主要工作就是代理。 七层负载均衡 也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

七层负载均衡的优点：这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性；安全性高。

④ U8服务器参数配置中负载均衡如何设置

网络的负载均衡是一种动态均衡技术，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。

⑤ 多台异地服务器如何实现负载均衡

一般用的就用简单的轮询就好了
调度算法
静态方法：仅根据算法本身实现调度；实现起点公平，不管服务器当前处理多少请求，分配的数量一致
动态方法：根据算法及后端RS当前的负载状况实现调度；不管以前分了多少，只看分配的结果是不是公平
静态调度算法(static Sche)（4种）:
(1)rr (Round Robin) :轮叫,轮询
说明：轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器，从1开始，直到N(内部服务器个数)，然后重新开始循环。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。缺点：是不考虑每台服务器的处理能力。
(2)wrr (Weight Round Robin) :加权轮询(以权重之间的比例实现在各主机之间进行调度)
说明：由于每台服务器的配置、安装的业务应用等不同，其处理能力会不一样。所以，我们根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。
(3)sh (Source Hashing) : 源地址hash实现会话绑定sessionaffinity
说明：简单的说就是有将同一客户端的请求发给同一个real server,源地址散列调度算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的并且没有超负荷，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。
(4)dh : (Destination Hashing) : 目标地址hash
说明：将同样的请求发送给同一个server,一般用于缓存服务器，简单的说，LB集群后面又加了一层，在LB与realserver之间加了一层缓存服务器，当一个客户端请求一个页面时,LB发给cache1,当第二个客户端请求同样的页面时，LB还是发给cache1,这就是我们所说的，将同样的请求发给同一个server,来提高缓存的命中率。目标地址散列调度算法也是针对目标IP地址的负载均衡，它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
动态调度算法(dynamic Sche)（6种）:
(1)lc (Least-Connection Scheling): 最少连接
说明：最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时，我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。此算法忽略了服务器的性能问题，有的服务器性能好，有的服务器性能差，通过加权重来区分性能，所以有了下面算法wlc。
简单算法：active*256+inactive (谁的小，挑谁)
(2)wlc (Weighted Least-Connection Scheling):加权最少连接
加权最小连接调度算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权限，加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。由于服务器的性能不同，我们给性能相对好的服务器，加大权重，即会接收到更多的请求。
简单算法：（active*256+inactive）/weight（谁的小，挑谁）
(3)sed (shortest expected delay scheling):最少期望延迟
说明：不考虑非活动连接，谁的权重大，我们优先选择权重大的服务器来接收请求，但会出现问题，就是权重比较大的服务器会很忙，但权重相对较小的服务器很闲，甚至会接收不到请求，所以便有了下面的算法nq。
基于wlc算法，简单算法：（active+1)*256/weight （谁的小选谁）
(4).nq (Never Queue Scheling): 永不排队
说明：在上面我们说明了，由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，所此算法是sed改进，就是说不管你的权重多大都会被分配到请求。简单说，无需队列，如果有台real server的连接数为0就直接分配过去，不需要在进行sed运算。
(5).LBLC(Locality-Based Least Connections) :基于局部性的最少连接
说明：基于局部性的最少连接算法是针对请求报文的目标IP地址的负载均衡调度，主要用于Cache集群系统，因为Cache集群中客户请求报文的目标IP地址是变化的，这里假设任何后端服务器都可以处理任何请求，算法的设计目标在服务器的负载基本平衡的情况下，将相同的目标IP地址的请求调度到同一个台服务器，来提高服务器的访问局部性和主存Cache命中率，从而调整整个集群系统的处理能力。
(6).LBLCR(Locality-Based Least Connections with Replication) :基于局部性的带复制功能的最少连接
说明：基于局部性的带复制功能的最少连接调度算法也是针对目标IP地址的负载均衡，该算法根据请求的目标IP地址找出该目标IP地 址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除， 以降低复制的程度。

⑥ 新的连接被依次分布到各个时服务器的调度算法是

摘要 您好，1、轮询调度

⑦ slb配置详解

我们一起来快速认识一下，负载均衡——SLB。负载均衡SLB是将访问流量根据转发策略分发到后端多台云服务器（ECS实例）的流量分发控制服务。包含两种含义：一是通过流量分发，扩展应用系统的服务能力；二是消除单点故障，提高应用系统的可用性。

应用场景
我们具体来看一看它的使用场景。
第一个使用场景的是用于高访问量的业务。
当你的应用访问量非常大，单台的服务器已经无法承载这个访问量的时候，就可以使用负载均衡，将流量分发到不同的服务器上去。
第二个场景是横向扩张系统。
当你已经使用了负载均衡，在业务有波动时可以在后端非常方便的添加和减少ECS来调整自己应用的服务能力。
第三个应用场景是消除单点故障。
当我们在使用负载均衡时，后端有多台ECS在同时工作的。一旦其中一台ECS上的应用发生了故障，那么负载均衡会通过一个健康检查的机制来及时的发现这个故障，并且能屏蔽对这台ECS的流量转发，然后将用户的请求转发到另一台正常工作的ECS实例上。
同城的容灾
阿里云负载均衡可以实现同地域多可用区之间同地域容灾，当主可用区出现故障是，可以在短时间内切换到另一备用可用区，以恢复服务能力。同时，主可用区恢复访问时，它会自动切换到主可用区。


跨地域容灾
跨地域容灾通过云解析做智能DNS，将域名解析到不同地域的负载均衡实例地址下，以实现全局负载均衡，当某个地域出现不可用时，暂停对应解析即可实现所有用户访问不受影响。

配置负载均衡
下面我们来演示一下负载均衡该如何去配置。
首先要做好准备工作，我们需要开通一台负载均衡实例和与负载均衡同一个地域的两台ECS服务器。

创建好以后，我们就可以在负载均衡的控制台看到这样一台实例了。
接下来，我们要给这个负载均衡创建一个监听。“监听”可以简单的理解为对应后端服务器里面的一个应用，比如一个网站我们来点击监听，然后点击添加监听。


假设我们的后端服务器里面有一个http的网站前端协议端口，我们可以将前后端协议端口TCP都写成80，然后根据自己的需要来选择调度算法，其实就是流量的转发方式。

下一步是健康检查，我们可以选择TCP方式。

健康检查端口会默认的和后端服务器的端口保持一致，直接确认就好了。现在，一个监听就配置好了。
接下来要去规定这台负载均衡的后端服务器是哪些。点击后端服务器，然后点击未添加服务器，将我们刚才创建的两台服务器勾选，然后批量添加就可以了。

这里有一个权重需要大家注意一下，这里的权重就是一个比例的概念，如果两台服务器写的都是100，流量将会以1:1的方式被转发到后端的两台服务器上。

⑧ 如何配置Web服务器实现负载均衡

网络的负载均衡是一种动态均衡技术，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把任务合理均衡地分配出去。这种技术基于现有网络结构，提供了一种扩展服务器带宽和增加服务器吞吐量的廉价有效的方法，加强了网络数据处理能力，提高了网络的灵活性和可用性。

以四台服务器为例实现负载均衡：

安装配置LVS

1. 安装前准备：

(1)首先说明，LVS并不要求集群中的服务器规格划一，相反，可以根据服务器的不同配置和负载状况，调整负载分配策略，充分利用集群环境中的每一台服务器。如下表：

Srv Eth0 Eth0：0 Eth1 Eth1：0

vs1 10.0.0.1 10.0.0.2 192.168.10.1 192.168.10.254

vsbak 10.0.0.3 192.168.10.102

real1 192.168.10.100

real2 192.168.10.101

其中，10.0.0.2是允许用户访问的IP。

(2)这4台服务器中，vs1作为虚拟服务器(即负载平衡服务器)，负责将用户的访问请求转发到集群内部的real1，real2，然后由real1，real2分别处理。
Client为客户端测试机器，可以为任意操作系统。

(3)所有OS为redhat6.2，其中vs1 和vsbak 的核心是2.2.19， 而且patch过ipvs的包， 所有real
server的Subnet mask 都是24位， vs1和vsbak 的10.0.0. 网段是24 位。

2.理解LVS中的相关术语

(1) ipvsadm ：ipvsadm是LVS的一个用户界面。在负载均衡器上编译、安装ipvsadm。

(2) 调度算法： LVS的负载均衡器有以下几种调度规则：Round-robin，简称rr;weighted
Round-robin，简称wrr;每个新的连接被轮流指派到每个物理服务器。Least-connected，简称lc;weighted
Least-connected，简称wlc，每个新的连接被分配到负担最小的服务器。

(3) Persistent client
connection，简称pcc，(持续的客户端连接，内核2.2.10版以后才支持)。所有来自同一个IP的客户端将一直连接到同一个物理服务器。超时时间被设置为360秒。Pcc是为https和cookie服务设置的。在这处调度规则下，第一次连接后，所有以后来自相同客户端的连接(包括来自其它端口)将会发送到相同的物理服务器。但这也会带来一个问题，因为大约有25%的Internet
可能具有相同的IP地址。

(4) Persistent port
connection调度算法：在内核2.2.12版以后，pcc功能已从一个调度算法(你可以选择不同的调度算法：rr、wrr、lc、wlc、pcc)演变成为了一个开关选项(你可以让rr、
wrr、lc、wlc具备pcc的属性)。在设置时，如果你没有选择调度算法时，ipvsadm将默认为wlc算法。 在Persistent port
connection(ppc)算法下，连接的指派是基于端口的，例如，来自相同终端的80端口与443端口的请求，将被分配到不同的物理服务器上。不幸的是，如果你需要在的网站上采用cookies时将出问题，因为http是使用80端口，然而cookies需要使用443端口，这种方法下，很可能会出现cookies不正常的情况。

(5)Load Node Feature of Linux Director：让Load balancer 也可以处理users 请求。

(6)IPVS connection synchronization。

(7)ARP Problem of LVS/TUN and LVS/DR：这个问题只在LVS/DR，LVS/TUN 时存在。

3. 配置实例

(1) 需要的软件包和包的安装：

I. piranha-gui-0.4.12-2*.rpm (GUI接口cluster设定工具);

II. piranha-0.4.12-2*.rpm;

III. ipchains-1.3.9-6lp*.rpm (架设NAT)。

取得套件或mount到光盘，进入RPMS目录进行安装:

# rpm -Uvh piranha*

# rpm -Uvh ipchains*

(2) real server群：

真正提供服务的server(如web
server)，在NAT形式下是以内部虚拟网域的形式，设定如同一般虚拟网域中Client端使用网域：192.168.10.0/24
架设方式同一般使用虚拟IP之局域网络。

a. 设网卡IP

real1 ：192.168.10.100/24

real2 ：192.168.10.101/24

b.每台server均将default gateway指向192.168.10.254。
192.168.10.254为该网域唯一对外之信道，设定在virtual server上，使该网域进出均需通过virtual server 。

c.每台server均开启httpd功能供web server服务，可以在各real server上放置不同内容之网页，可由浏览器观察其对各real
server读取网页的情形。

d.每台server都开启rstatd、sshd、rwalld、ruser、rsh、rsync，并且从Vserver上面拿到相同的lvs.conf文件。

(3) virtual server：

作用在导引封包的对外主机，专职负责封包的转送，不提供服务，但因为在NAT型式下必须对进出封包进行改写，所以负担亦重。

a.IP设置：

对外eth0：IP：10.0.0.1 eth0：0 ：10.0.0.2

对内eth1：192.168.10.1 eth1：0 ：192.168.10.254

NAT形式下仅virtual server有真实IP，real server群则为透过virtual server.

b.设定NAT功能

# echo 1 >; /proc/sys/net/ipv4/ip_forward

# echo 1 >; /proc/sys/net/ipv4/ip_always_defrag

# ipchains -P forward MASQ

c.设定piranha 进入X-window中 (也可以直接编辑/etc/lvs.cf )

a).执行面板系统piranha

b).设定“整体配置”(Global Settings) 主LVS服务器主机IP：10.0.0.2， 选定网络地址翻译(预设) NAT路径名称：
192.168.10.254， NAT 路径装置： eth1：0

c).设定虚拟服务器(Virtual Servers) 添加编辑虚拟服务器部分：(Virtual
Server)名称：(任意取名);应用：http;协议： tcp;连接：80;地址：10.0..0.2;装置：eth0：0; 重入时间：180
(预设);服务延时：10 (预设);加载监控工具：ruptime (预设);调度策略：Weighted least-connections; 持续性：0
(预设); 持续性屏蔽： 255.255.255.255 (预设); 按下激活：实时服务器部分：(Real Servers); 添加编辑：名字：(任意取名);
地址： 192.168.10.100; 权重：1 (预设) 按下激活

另一架real server同上，地址：192.168.10.101。

d). 控制/监控(Controls/Monitoring)
控制：piranha功能的激活与停止，上述内容设定完成后即可按开始键激活piranha.监控器：显示ipvsadm设定之routing table内容
可立即更新或定时更新。

(4)备援主机的设定(HA)

单一virtual server的cluster架构virtual server 负担较大，提供另一主机担任备援，可避免virtual
server的故障而使对外服务工作终止;备份主机随时处于预备状态与virtual server相互侦测

a.备份主机：

eth0： IP 10.0.0.3

eth1： IP 192.168.10.102 同样需安装piranha，ipvsadm，ipchains等套件

b.开启NAT功能(同上面所述)。

c.在virtual server(10.0.0.2)主机上设定。

a).执行piranha冗余度 ;

b).按下“激活冗余度”;

冗余LVS服务器IP： 10.0.0.3;HEARTBEAT间隔(秒数)： 2 (预设)

假定在…秒后进入DEAD状态： 5 (预设);HEARTBEAT连接端口： 539 (预设)

c).按下“套用”;

d).至“控制/监控”页，按下“在当前执行层添加PULSE DEAMON” ，按下“开始”;

e).在监控器按下“自动更新”，这样可由窗口中看到ipvsadm所设定的routing table，并且动态显示real
server联机情形，若real server故障，该主机亦会从监视窗口中消失。

d.激活备份主机之pulse daemon (执行# /etc/rc.d/init.d/pulse start)。

至此，HA功能已经激活，备份主机及virtual server由pulse daemon定时相互探询，一但virtual
server故障，备份主机立刻激活代替;至virtual server 正常上线后随即将工作交还virtual server。

LVS测试

经过了上面的配置步骤，现在可以测试LVS了，步骤如下：

1. 分别在vs1，real1，real2上运行/etc/lvs/rc.lvs_dr。注意，real1，real2上面的/etc/lvs
目录是vs2输出的。如果您的NFS配置没有成功，也可以把vs1上/etc/lvs/rc.lvs_dr复制到real1，real2上，然后分别运行。确保real1，real2上面的apache已经启动并且允许telnet。

2. 测试Telnet：从client运行telnet 10.0.0.2，
如果登录后看到如下输出就说明集群已经开始工作了：(假设以guest用户身份登录)

[guest@real1 guest]$——说明已经登录到服务器real1上。

再开启一个telnet窗口，登录后会发现系统提示变为：

[guest@real2 guest]$——说明已经登录到服务器real2上。

3. 测试http：从client运行iexplore http://10.0.0.2

因为在real1 和real2 上面的测试页不同，所以登录几次之后，显示出的页面也会有所不同，这样说明real server 已经在正常工作了。

⑨ 接触过的Nginx的负载均衡算法有哪些

Nginx 官方默认的几种负载均衡的算法
①Round-Robin RR轮询（默认） 一次一个的来（理论上的，实际实验可能会有间隔）
②weight 权重 权重高多分发一些 服务器硬件更好的设置权重更高一些
③ip_hash 同一个IP，所有的访问都分发到同一个web服务器
第三方模块实现的调度算法 需要编译安装第三方模块
④fair 根据后端服务器的繁忙程度 将请求发到非繁忙的后端服务器
⑤url_hash 如果客户端访问的url是同一个，将转发到同一台后端服务器
看你在学习Nginx的知识，推荐你去看黑马程序员视频库，里面有它的学习视频，讲解的很详细哦！

⑩ 链路负载均衡的链路负载均衡包括以下几个基本元素：

l LB device：负责将内网到外网流量分发到多条物理链路的设备。
l 物理链路：运营商提供的实际链路。
l DIP：用户发送报文的目的网段。
l 链路带宽：运营商提供给此链路的实际带宽。
l 链路阈值：流量超过此链路阈值时会进行相应带宽调度。
l 链路权重：多条链路在同一调度策略中，根据加权调度算法将目标流量根据权重比进行分发。
l 健康检查：检查运营商链路的质量。
l 所属运营商：确定此条链路所属哪个运营商。
l 路由模式：确定此条链路需要下发哪些路由。
l 目的IP组：确定去往此目的运营商IP所走的链路。
l 源地址组：确定哪些内网用户能匹配此条链路。
l 协议：确定哪些协议能匹配此条链路。
l 入接口：确定从哪些接口流入的流量能匹配此条链路。
l 策略动作：当所选物理链路都超阈值后，设备对超阈值流量的处理方式。
l 会话保持：匹配源目ip的同一会话在老化时间内走同一条链路。
l DNS透明代理：内网用户向外网域名请求时，设备将此报文拦截重新选择负载最小的链路转发。
CDN是个很庞大的概念和体系.全世界CDN服务提供商屈指可数.
我们熟悉的Google就是某CDN的最大客户.我们今天只选取其中一小部分来讨论.
说了半天.看上去似乎很复杂.鉴于经典的大多是搞WEB的.接触的最多的是WEB服务器/数据库等.既然是浅谈.我就举个简单的例子.