Haproxy、Nginx、Lvs 负载均衡算法

Lvs

##缺陷
  没有后端主机健康状态检查,但可以通过自己编写脚本来检测
## 轮询(Round Robin)
  轮询,依次向每个服务器发送请求
## 加权轮询(Weight Round Robin)
  根据权重进行请求的发送
## 源地址哈希(Source Hashing)
  根据客户端ip进行hash,实现session绑定
## 目标地址哈希(Destination Hashing)
  把对于同一个IP地址的请求,发送给同一个server
## 最少连接(Least-Connection)
  把新的连接分配到当前活动连接数最小的服务器,active代表当前服务器活动连接,inactive代表当前服务器非活动
  具体算法 active*256+inactive,得到的值,谁的最小,给谁分配
## 加权最少连接(Weighted Least-Connection)
  具体算法 (active*256+inactive)/weight,得到的值,谁的最小,给谁分配,权值标识机器处理性能。
  如果第一个进来的时候,每台服务器算出来的结果都一样,这样可能就要选到性能最差的那台(都一样就轮询),这是一个缺点,加权和不加权都有这个缺点
## 最短期望延迟(Shortest Expected Delay)
  改进的wlc算法
  具体算法 (active+1)*256/weight
  同上一个比较,除去了影响不大的inactive数目,但是在计算活动连接数的时候,先加上1,保证了,即使在活动连接数为0的情况下,还避免使用轮询,随机选择
## 不排队(Never Queue)
  改进的sed算法
  如果有连接为0的主机,则先给此主机,如果没有,则按照sed算法进行分配
## 基于局部性的最少连接(Locality-Based Least Connection)
  类似于dh算法,通常先按照最少连接来分配,然后以后的对应ip的访问就要调度到第一次响应的那台主机上,如果此主机down或者负载到一半以上,则会再按照最少连接找一台服务器,然后发送请求
## 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)
  基于lblc算法,只不过,此算法是将目标ip和后端集群做绑定,其他和lblc一样

Nginx

##以前版本
### 加权轮询(weight)
  根据权重来进行后端主机的分配
### 源地址hash(ip_hash)
  根据访问者ip来进行分配后端主机,固定的IP会被分配到固定的主机上,可以解决session问题,但是会破坏负载均衡特性
### 最小响应时间(fair、第三方)
  按后端主机响应时间来分配请求,响应时间短的优先分配,一般不用,因为网络问题不确定性太多
### 目标地址hash(url_hash、第三方)
  按客户端访问的主机url进行分配客户端,比较适合后端是缓存服务器的场景
##2016-08-17 版本(增加或者改变的)
### 自定义hash内容(hash key [consistent])
  这个不知道在那个版本加入的,可以自己指定hash的键,如果指定为hash $remote_addr 就和ip_hash是一样的,hash 后边的那个变量为nginx可用变量,查手册获得。如果后边的 consistent 被指定,则说明要使用一致性hash代替普通hash,这样的话在后端是缓存服务器的时候,出现down机或者新添加机器的时候,就可以使缓存失效的情况大大减少。(具体原因请百度 一致性hash)
### 最少连接(least_conn)
  显而易见,按照后端主机的最少活动连接数分配,后端主机性能越强,处理能力越强,则越能接受到多的连接(抛开网络因素)
### 最短时间和最少连接(least_time connect | first_byte | last_byte)
  如果参数选择connect,则和least_conn一样,如果是first_byte,则根据第一个字节到达后端主机的时间,如果是last_byte,则根据最后一个字节到达后端主机的时间。

Haproxy

### 最少活动连接 (leaseconn)
  最少的活动连接数,在sql,ldap等服务中使用
### 源地址hash (source)
  按照客户端地址hash值进行分配
### 目标uri hash(uri)
  根据访问的地址的uri进行hash,len基于多少个uri字符,depth基于多少个目录层次
### url参数 (url_params)
  根据访问的地址的参数进行调度,参数指url http://www.baidu.com/index.html?name=lilei  中的name=lilei
### 请求头信息调度(hdr(name))
  根据访问的头信息来调度,比如 hdr(Host) 是根据访问的主机名调度。
### cookie (rdp-cookie)
  根据访问者的cookie信息来调度
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,219评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,363评论 1 293
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,933评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,020评论 0 206
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,400评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,640评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,896评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,597评论 0 199
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,327评论 1 244
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,581评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,072评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,399评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,054评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,083评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,849评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,672评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,585评论 2 270

推荐阅读更多精彩内容