吉利德三代:HAProxy 配置手册 4.2 balance 相关

balance [ ]
balance url_param [check_post []]
  定义选择后端服务的负载均衡算法
  May be used in sections :   defaults | frontend | listen | backend
                                               yes   |    no    |   yes  |   yes
  Arguments :
    是负载均衡时选择服务器的算法，没有持续信息时可用，或连接重定向到另一个服务器。 可以是以下几种：
      roundrobin  每个服务器根据权重轮流使用，如果服务器的处理时间平均分布，这是最流畅和公平的算法。算法是动态的，对于实例启动慢的服务器的权重会在运行中调整。每个backend的活动服务器在设计上限制为4128个。在一些大的群里面， 当服务器很短的宕机后恢复回来，有时会有几百个请求被重新整合到群当中，并开始接收处理。尽管很少发生，但是很正常。这也说明了有机会监视它们，所以不必担心。

      static-rr  每个服务器根据权重轮流使用，类似roundrobin，但它是静态的，意味着运行时修改权重是无效的。另一方面，它对服务器的数量没有设计上的限制，服务器启动后便会立即进到群中，整个分发方案会重新计算。这会略微降低CPU的运行（约1%）。

      leastconn  连接数最低的服务器优先接收连接。Round-robin用于负载相同的服务器，使每台服务器都被使用。leastconn建议用于长会话服务，例如LDAP, SQL, TSE等，而不是很适合短会话协议，如HTTP。算法是动态的，对于实例启动慢的服务器的权重会在运行中调整。

      source    对源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一台服务器。如果哈希的结果随可用服务器数量而变化，那么有的客户端会定向到不同的服务器。该算法一般用于不能插入cookie的TCP模式。它还可以用于广域网上，为拒绝使用会话cookie的客户端提供最有效的粘连。该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type"的变化做调整。

      uri        对URI左端(问号之前)进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个URI地址总是访问同一台服务器。一般用于代理缓存和反病毒代理，以最大限度的提高缓存的命中率。该算法只能用于HTTP后端。该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type"的变化做调整。
                  算法支持两个可选参数"len" 和 "depth"， 都是后跟正整数。“len”参数指定算法只处理URI从头开始的字符数，据此计算哈希。因为大多URI以"/"开头，所以"len"最好不要设为1。"depth" 参数指定URI中最大的路径深度，据此计算哈希。请求中的每个斜线为一级。如果同时声明了这两个参数，则截取URI时必须同时满足。

      url_param  在HTTP GET请求的查询串中查找中指定的URL参数。
                 若使用了修饰符"check_post"，如果在URL问号('?')后面的查询串中找不到参数，就会搜索HTTP POST 请求实体。或者在指定的一些字节后面尝试搜索消息体。如果搜索不到实体， 则使用round robin算法。例如，假设客户端总是在前128个字节发送LB参数，就可以指定它。默认为48。如果到达网关的字节数量不够，实体数据是检索不到的，至少有：（default/max_wait, Content-Length or first chunk length）。如果Content-Length没有或为0，就不需要等待客户端发送更多的数据。当Content-Length有值且大于，则等待仅限于，并假设有足够的数据用于搜索参数的存在。万一Transfer-Encoding被用了，则只能检查第一个块。如果参数值被块边界分隔开，则只能随机均衡负载了。
                  如果参数后面跟着 ('=') 和一个值，则可以根据这个值进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。
                  还可用于跟踪请求中的用户身份，只要服务器正常，同一个用户ID的请求总是发给同一台服务器。如果没有参数或参数没有值，则使用轮询算法。该算法只用于HTTP后端。该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type"的变化做调整。

      hdr(name)  在每个HTTP请求中查找HTTP头。与ACL函数'hdr()'一样。括号括起来的头名字不区分大小写。如果缺少头或头没有任何值，则使用roundrobin算法代替。                 
                       启用参数'use_domain_only'，哈希算法将只用于一些类似'Host'的特定头的主域部分。例如主机值"haproxy.1wt.eu"，则只考虑 "1wt"。该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type"的变化做调整。

      rdp-cookie
      rdp-cookie(name)
                  为每个进来的TCP请求查询并哈希RDP cookie (或“mstshash”如果省略) 。与ACL函数 'req_rdp_cookie()'一样，name不区分大小写。该机制用于退化的持久模式，可以使同一个用户（或同一个会话ID）总是发送给同一台服务器。如果没有cookie， 则使用roundrobin算法代替。
                  必须注意该声明要生效，前端必须确保在请求缓冲中已经有RDP cookie，所以必须使用规则tcp-request content accept' 和ACL 'req_rdp_cookie_cnt'相结合。
                  该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据"hash-type"的变化做调整。

    是用于一些算法的可选参数列表，目前只有"url_param" 和 "uri" 用到，例如：
                balance uri [len ] [depth ]
                balance url_param [check_post []]

  如果没有其他算法、模式或选项的设置，后端的负载均衡算法默认为roundrobin。每个后端只能设置一种。
  Examples :
        balance roundrobin
        balance url_param userid
        balance url_param session_id check_post 64
        balance hdr(User-Agent)
        balance hdr(host)
        balance hdr(Host) use_domain_only

  注意:  以下的警告和限制是使用“check_post“扩展和”url_param”所必须考虑 ：
    - 所有POST请求都要考虑，因为在包含二进制数据的体或实体中，没有办法决定是否会找到参数。因此需要另一种方法，限制POST请求的体中不含有URL参数 (见 acl reqideny http_end)

    - 大于请求缓冲大小的 值是没用的。在build时设置缓冲大小，默认16KB。
    - 不支持Content-Encoding, 参数搜索会失败；负载均衡会改用 Round Robin。
    - 预计: 不支持100-continue,负载均衡会改用 Round Robin。
    - Transfer-Encoding (RFC2616 3.6.1) 只在第一个块中支持。如果在第一个块中的参数值不完整，选择的服务器就没有定义。（实际上取决于在第一个块中定义的有多小）
    - 该特性不支持生成100, 411 或 501 响应。
    -  有的情况下，需要"check_post"只是要查看整个消息体的内容。检查一般会停在任意数量的空格（LWS: linear
      white space）或控制符上，表示这可能是一个URL参数列表。这可能不是一个关于SGML的类型消息体。

  See also : "dispatch", "cookie", "appsession", "transparent", "hash-type" and "http_proxy".

hash-type
  将哈希映射到服务器的方法。Specify a method to use for mapping hashes to servers
  May be used in sections :   defaults | frontend | listen | backend
                                               yes   |    no    |   yes  |   yes
  Arguments :
    map-based  哈希表是包含所有在线服务器的静态数组。哈希结果很平滑，并考虑了权重，但是会忽略服务器启动时的权重变化，也就是说不能慢启动。另外，服务器是根据数组中的位置所选择的，所以服务器数量变化时，大部分映射也会变化。当一台服务器启动或关闭，或服务器加入到群中，大部分连接会再分配给不同的服务器，这对有缓存的实例会比较麻烦。

    consistent  哈希表是由每个服务器构成的树，会在树上查找哈希Key，并选择最近的服务器。这种哈希是动态的，支持服务器启动时修改权重，所以可以慢启动。它有一个好处是当服务器启动或关闭时，只有其本身的关系被移除，当服务器加入群时，只有一小部分的映射会被重新分配，所以是一个比较理想的支持缓存的算法。但是根据其原理，算法不会非常平滑，有时候必须调整服务器的权重或ID来获得更平衡的分布。要保持多次负载均衡时的相同分布，服务器ID是绝对不能变的。（roloand:haproxy根据服务器的ID初始化其哈希值）
   默认值是"map-based"，建议大部分情况下使用。

  See also : "balance", "server"

dispatch