本文共 5159 字，大约阅读时间需要 17 分钟。

刚才基本认识haproxy基本工作逻辑和配置模式

进程管理和安全 性能调整 每个参数，官方文档都有说明 如果haproxy生成的日志信息非常的长，但不需要完成记录下来，可以指定最大只记录多长

len是关键字，length是指明的字节长度，len 100 表示只记录前100个字节信息

<facility这个是必选的，指定设施，[指明最高级别和最低级别]，仅把这个范围的级别日志记录，而级别分为7个（debug，info，warn，error，pritical）当指定某一个级别，通常意味着，这个级别，以及比它更高等级的级别，都要被记录下来 对于haproxy而言，每个配置下来的log，可指明两个目标位置 进程数量， nginx工作在masterworker下，启动几个worker要有workprocess来定义

而haproxy，官方建议工作在单进程模式下，意味着没有两级级别，master之类，而仅仅是单进程模式并且有一个进程处理所有的用户请求 ulimit是用来设置最大资源限制的。-n则是限制每个进程，所能打开的最大文件描述符数量

一个代理服务器，为客户端一侧维持一个套接字文件，为服务端一次维持一个套接字文件，因此文件数应该是我们所允许使用的最大并发连接数 客户端和服务端一侧使用短连接的话，乘以2用不了那么多，而且这个数值到底多少合适，haproxy会根据最大并发连接数的数字自动调整，因此无需手动指定， 最重要的maxconn，所能接受的最大并发连接数，应该是maxconn乘以nbproc 每个进程每秒所能创建的最大连接数

rate速率 一次如果突然接进来2000个请求，就要设定一个处理的速率，第一秒处理200个，逐个逐个处理

说白了就是每秒能新进来的连接数量 每秒钟能创建的会话数，连接的时候可以理解为在传输层构建的tcp链接，然后在连接之上，可以去创建会话，一个链接如果保持链接的化，可以创建多个会话 这是每个进程所能处理的最大ssl链接数量

面向客户端可能是https，面向服务器就可能是http 使用ssl，要比纯明文的http消耗的资源多的多 所以这个速率和其他的明文tcp链接还是有所不同的 下面两个指的是tcp的链接数量，和会话速率，（包括http，和https） **spread 散开的意思 check 检查 对后端主机的状态做检查 ** 后端主机如果数量过大时，发送健康状态检测发生 了很大流量

如果发送健康检测这个过程是一同发出的，很可能百分之50的带宽都拿来做检测了 就可以用散开来实现，就指明 这个散开的时间前后可以提前或延迟，整个检查周期的多长时间

0-50，单位百分比 debug的性能参数多数来讲，是用不到的 haproxy配置参数非常精细 最大使用多少cpu资源都可以定义但是都不可能在这些情况下，调整这么精细，除了给对方做反代时，haproxy按量计费的资源，比如在公有云创建一个LBAS（负载均衡及服务），是按照调用哪个服务的流量，而且对于cpu的占用是按照一定配额的，很多用到的调度器其实是haproxy，一个用户买了一个LBAS就是给你创建个对应的haproxy的进程实例，并配置各种参数来使用，而通常背后用 的是容器或者是一个单独的虚拟机

在公有云就不需要自己创建了，直接买就可以了 重点部分，代理服务配置部分，而每一个配置部分都需要用一个关键字来引用 frontend 类似nginx的server可以出现多次，但是每个server的套接字可能是不同的

listen表示某一个backend恩后frontend二者第一个已绑定的时候可以直接使用，或者是某一个listen，只需向前端监听，而无需后端处理时也可以 nginx有一个status页面，输出nginx自己的状态信息的，而这个状态页可以把他单独定义称为一个server来提供，而对于这个状态页来讲，既不需要本地系统中的文件也不需要代理，这种情况就可以定义成一个listen一样的效果

只有前端没有后端的时候，使用listen也是比较妥当的 <name是必须给的，这个标识符仅能使用，包含upper，lower，case letters大小写字母，digits数字，dash或者符号，

下划线underscore，dot,点好，colon冒号，并且区分字符大小写，

有点类似变量的命名方式，仅能使用字母数字下划线

所以配置文件应该有，global，defaults，各个多个forntend，backend，一个或多个listen组成

而proxy中，frontend和backend每一个都并非是必须的，有listen，没有frontend，backend都是可以的，listen和frontend只能有一个，不然谁去接收请求，同样道理backend和listen只能有一个，不然谁去处理请求 代理配置段的配置参数，接下来，你找字母表中的次序以及重要程度来说明

1.bind可以在前端中国定义监听的地址和端口的，多个套接字之间用,号分隔开即可 第三类，bind。unit的socket路径通常都是本机到本机发送的请求的 在listen和forntend都可以使用bind，用来表明监听地址和端口 只有一个的时候，可以直接写在下面 第二个关键字叫balance，是定义后端服务器组内的调度算法的，既然是调度后端服务器组内的调度算法，应该有backend和listen组，不能用在frontend上

每个关键字都有适合用在哪个部分上面 balance，多个backend可以重复使用同一个调度算法，所以可以使用defaults，写错了位置会出现语法错误 balance指明调度算法，（有些调度算法可能还有自己的参数

有一个特殊的算法叫url_param，必须给明param是什么 roundrobin轮询有两种格式，（

加权轮询，每个服务器选择的比例取决于权重，但是roundrobin是动态算法，（静态算法static-rr是只根据算法本身进行计算，动态算法，不但根据算法本身进行计算，每个用户调度到哪台主机上时，如果要追踪，既然轮询，为何要追踪，对于轮询来讲，有另外个需要慢启动‘

所以动态算法：支持权重的运行适合调整，支持慢启动；追踪每一个服务器的链接数量，而且根据数量本身来完成，所谓的调度，每个后端中最多支持4095个server

轮询，和静态轮询 慢启动，新加了一台服务器，调度器不可能一下子把几千个并发链接调度过去，是需要慢慢加载起来的，为了支持慢启动的逻辑，有可能需要在内存中维持一段动态追踪的会话数量，但为了避免追踪数量太多，这个空间是有限的,可以理解为就是考虑后端服务器负载进行调度的，但是事实上这种算法仅仅是对调度算法本身进行计算追踪得来的，既然要在内存追踪，就最多支持4095个后端server，避免占用资源过多 first代表先到先得，不是负载均衡，而是将服务器资源用完，根据后端服务器在列表中的位置，自上而下进行调度，第一台服务器用完了才用第二台，这就是调度概念了，但是有些时候就是这么玩的，我们要尽可能压榨服务器性能，就可以用这种，比如做弹性调度时，最大化利用服务器，而不是最大化用户体验就可以用这种 相当于lvs的sh，nginx的hash，根据源地址来绑定后端服务器，

这个算法到底是动态还是静态，取决于另外一个参数，哈希算法hash-type的类型

如果是取模法就认为是静态的（map-based），静态的哈希就认为是一个静态数组

一致性哈希算法，是一个树，可以动态调整的，则认为是动态的

加入有三台服务器，权重各不相同，需要把每台服务器虚拟成虚拟节点

映射逻辑上是虚的，并不真是虚拟服务器，跟算法有关，跟服务器没有关系 对映射法来讲，随着服务器增加或者减少其算法复杂度是恒定的，2000台和200台从中找 一个映射消耗的时间是等同的，所以算法复杂度是最理想状态，因此消耗的时间并不会随你的服务器增加或减少而做改变

这个方式有个问题就是服务器增减势必会导致整个数组发生抖动，抖动的结果就会造成服务器数量变化和映射逻辑都会全局发生变化，如果所有链接都是短连接，那就没什么问题，但是为了命中后端的缓存的话就会有问题的，重新调度的话，缓存就没用了

所以跟算法没关系跟业务有关系，所以并非算法天生就是有问题的，这个算法敲好比一致性哈希复杂度更低，更高效，因为只是对全部服务器数量取模的，而一致性hash需要对2的32次方取模，这样的计算量肯定更大，但是有一个好处，就是起码不会服务器数量增减，而导致整个映射表全局抖动，只会影响一个局部或者多个局部而已

通过消耗更大的计算量而换来的好处，

好处是如何换来的，把节点分布在hash环上，hash的时候不再是对于总权重取模，而是固定的2 的32次方取模，对服务器取模以后，还要给请求取模。对服务器取模以后，就对服务器分布在hash环上，而后来的请求取模以后，也在hash环上，顺时针找到服务器最近的节点，进行处理

但是有个坏处，就是服务器数量过少，会导致偏斜（有点服务器处理了大量的请求，有的没有），所以就可以做虚拟节点，这个时候对服务器做加盐计算以后，多出很多虚拟节点，但这个节点只是虚拟，对于服务器本身没有关系，服务器数量没有增减，只不过是吧服务器节点不连续地放在一起，而不是连续放在一起

2 的32次方，40多亿，每个数组元素都需要一个字节，这就是64G内存

所以用更高效的结构，树状结构来进行组织，二叉树，平衡数，红黑树，haproxy的坐标就是用来自己研发的弹性二叉树来解决的 树状结构的维持比一维数组要麻烦多了，因此算法复杂度要增加了，而映射逻辑可以支持动态当中的慢启动和运行时权重的运行调整，不用重启haproxy，调整一权重，reload，而一旦重启haproxy，所以的配置都需要重新配的 下一步算法url，这个类似于nginx的hash $request-url，能够把同一个url的请求，始终发往一个后端服务器

只不过对haproxy而言，这个url算法，是如何绑定的，也是取决于hash-type，是动态还是静态的 **如果是静态，有个巨大的害处，绑定的主要目的就是提高缓存命中率，任何服务器的增删调整，都会导致映射失效，所以此时建议使用consistent 一致性哈希的 只有hash-type是consistent，你的url算法才会更加有效，不会随着权重调整和服务器数量的改变而剧烈抖动 ** 现在实现一下source 默认hash-type是map-based，要使用静态映射逻辑 现在试试，访问地址就绑定了 如果要使用url算法，通常是基于web服务器的缓存时才进行url，为了保障命中率足够高，而不会随着权重变化而导致，变化过于剧烈，使用consistent 对某一个url的请求，一旦调度到某个主机以后，就固定发往这个主机 无论来自哪个客户端的请求都发往这台主机了 不管哪台主机访问都是69.因为访问的url是同一个，不管哪台客户端 ，只要url相同，都会用同一台服务器响应 现在给后端主机上多生成几个页面 到前台服务器上去请求第一个页面 只要页面是同一个就是中在一个服务器上，不管是哪个客户端都一样 第一台服务器访问这个url，后面发服务器访问url也会跳转到这个服务器上进行访问

;打头的部分叫参数 也可以根据url_Param来决定请求，根据用户所指定的url参数中的值来调度，值相同。第一次发往给服务器，后面都会发往服务器，值不同的就进行调度，但一旦第一次进行敲完以后所有的都始终绑定在一台主机上，很多电商站点涉及到调度的，对付费用户来讲，或者有些站点有vip，vip用户调度到一组可用性较高，服务器性能较好的主机上来，而且得到的服务体验也好很多，其他非付费用户就另当别论了

url是动态静态的取决于hash-type nginx有一个指令叫hash。可以根据hash的任何首部来进行调度，指定hdr，绑定你所使用的首部也可以 如果使用手机访问站点，acl在识别时用到哪些地方，可能会被用到

rdp，远程桌面协议，3389端口，相当的不安全

但是微软出现了一个新功能，可以直接在appstore当中下载一个linux，应用玩，等于再windows创建了一个虚拟机，在hyper-v引擎中启动linux 从名字上就可以看出默认的，在前端中定义调用哪个服务器

haproxy中，用户访问的归类要依靠ACL用户访问控制列表来实现 定义后端主机的个服务器及其选项，每个服务器可以有很多参数

转载地址：http://bbkgn.baihongyu.com/