34.1 算法介绍

ipvs scheduler

ipvs scheduler：根据其调度时是否考虑各RS当前的负载状态
两种：静态方法和动态方法
静态方法：仅根据算法本身进行调度
1、RR：roundrobin，轮询

2、WRR：Weighted RR，加权轮询

3、SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定 #根据ip来固定，传输层；而cookie不支持，应用层

4、DH：Destination Hashing；目标地址哈希，将发往同一个目标地址的请求 始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡， 如：宽带运营商

动态方法：主要根据每RS当前的负载状态及调度算法进行调度Overhead=value 较小的RS将被调度
1、LC：least connections 适用于长连接应用 #最小连接数
Overhead=activeconns*256+inactiveconns

2、WLC：Weighted LC，默认调度方法 #带权重的最少连接数，当连接数为0时，则wlc算法失效
Overhead=(activeconns*256+inactiveconns)/weight

3、SED：Shortest Expection Delay,初始连接高权重优先 #解决wlc连接数为0时的问题，但初始连接均向权重高的服务器上连接，也不太合适

4、NQ：Never Queue，第一轮均匀分配，后续SED #解决SED初始连接偏重于权重高的服务器连接问题

5、LBLC：Locality-Based LC，动态的DH算法，使用场景：根据负载状态实现正向代理

6、LBLCR：LBLC with Replication，带复制功能的LBLC，解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS

---

ngx_http_upstream_module

即nginx做反向代理模块

upstream name { … }
定义后端服务器组，会引入一个新的上下文
默认调度算法是wrr #rr
Context: http
upstream httpdsrvs {
server …
server… …
}

算法总结
1、rr
2、wrr
3、ip_hash 源地址hash调度方法
4、least_conn 最少连接调度算法，当server拥有不同的权重时其为wlc，当所有后端主机连接数相同时，则使用wrr，适用于长连接，
5、hash key [consistent] 基于指定的key的hash表来实现对请求的调度， 此处的key可以直接文本、变量或二者组合
作用：将请求分类，同一类请求将发往同一个upstream server，使用consistent参数，将使用ketama一致性hash算法，适用于后端是Cache服务器 （如varnish）时使用

---

haproxy

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-balance
balance

roundrobin 
static-rr
leastconn
first
source
uri 
url_param
hdr(<name>)   如hdr(user-agent)
rdp-cookie
rdp-cookie(<name>)

http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-hash-type
hash-type：哈希算法

 hash-type <method> <function> <modifier>
        method：
              map-based：除权取余法，哈希数据结构是静态数组  
              consistent：一致性哈希，哈希数据结构是一棵树  
        function : 哈希函数，取值：sdbm，djb2，wt6  
        modifier： 取值avalanche时，将修改哈希值，而非直接使用 
  default_backend <backend>
        无use_backend 匹配时，使用默认的backend，用于frontend中 
  default-server [param*]
        为backend中的各server设定默认选项 

---

tomcat 的http前端做调度

[root@cos27 ~ ]#httpd -M 参见35.1tomcat实验
lbmethod_bybusyness_module (shared) #类似lc(least connection)
lbmethod_byrequests_module (shared) #类似轮询roundrobin
lbmethod_bytraffic_module (shared) #根据链路流量调度
lbmethod_heartbeat_module (shared)

---

一致性hash

百度百科
一致性hash起源于解决路由问题；而keepalived高可用性使用的vrrp，亦来源于H3C中的vrrp协议

H3C中路由vrrp协议如下
VRRP是一种容错协议，它保证当主机的下一跳路由器出现故障时，由另一台路由 器来代替出现故障的路由器进行工作，从而保持网络通信的连续性和可靠性。
VRRP具有如下优点：
z 简化网络管理。在具有多播或广播能力的局域网（如以太网）中，借助VRRP 能在某台设备出现故障时仍然提供高可靠的缺省链路，有效避免单一链路发生故障后网络中断的问题，而无需修改动态路由协议、路由发现协议等配置信息，也无需修改主机的默认网关配置。
z 适应性强。VRRP 报文封装在 IP 报文中，支持各种上层协议。
z 网络开销小。VRRP 只定义了一种报文——VRRP 通告报文，并且只有处于 Master 状态的路由器可以发送 VRRP 报文。

一致性hash简单说明
需求描述
在企业部署集群时，为了提供用户体验，减轻后端服务器压力等因素考量，往往会部署缓存服务器，如varnish作为图片缓存，memcache作为数据库缓存等。如果拿web服务器上的图片来说，缓存到缓存服务器中，当上万用户访问时，图片如何缓存，如何查找等问题，需要解决，按照目前技术，一般都是hash(键)，即用hash算法对一个键值对中的键做运算，此结果由于hash算法的特性决定了其唯一性，通过hash对键或者关键字做运算，实现需求目的，如nginx做反向代理时的hash key中的参数consistent。但在对大量图片hash运算后放到缓存服务器，一般采用hash(key)mod(p),p为一个数值，如缓存服务器的数量，当缓存服务器的数量为3时，如图1，假设均匀分布：

但使用上述hash算法时，是假设的理想状态，即对3台服务器取模，才能均匀分布在hash环上，但3台缓存服务器一旦有一台宕机时或者新增缓存服务器时，则直接导致hash(key)mod(3)变为hash(key)mod(2)，导致缓存的图片对应的服务器号码发生变化，引起服务器大量缓存不可用，客户需要从新去后端服务器请求图片，且缓存服务器从新缓存图片(需要计算)，导致后台服务器压力骤增，而剩余的缓存服务器也面临着性能的考验。在这种情况下，意外发生的可能性比较大，如后台服务器宕机，正常缓存服务器宕机，导致无法为用户提供服务。显然，这种解决思路并不完善

提出一致性hash算法解决问题的基本概念
经过科学家的努力，实际一致性hash算法采用取模的方法，只是其模为2的32次方，即hash(key)mod(2^32),这样一来，由于2^32次方数值较大，在实际中hash(key)moe(2^32)时，可以解决缓存服务器数量增加或者减少带来缓存图片失效的问题，即缓存服务器的数量相比于2^32，一个天上，一个地下，相差太大，故而，上述问题当宕机一台缓存服务器时，或者新增缓存服务器时，由于算法决定，影响的只是较少的缓存付服务器上的图片缓存失效，如图2
相比于图1的结果：为0放在缓存服务器1上；为1放在缓存服务器2上，为2放在缓存服务器3上的各自区间，0到2^32-1结果：0到2^32-1/3的结果放在缓存服务器1的区间等，自然缓存服务器数量变化对整体影响较小;

缺点：hash换偏斜
图中均是把缓存服务器均匀映射在hash换上，如果如图3,3个缓存服务器被映射在hash环比较集中的地方，则按照顺时针方向缓存图片，服务器1将缓存大量图片，显然不合理

虚拟节点
解决hash换偏斜问题，即(hash(key)+10000)mod(2^32)