负载均衡算法的几种经常使用方案

总结下负载均衡的经常使用方案及适用场景

轮询调度

以轮询的方式依次请求调度不一样的服务器；实现时，通常为服务器带上权重；这样有两个好处：

1. 针对服务器的性能差别可分配不一样的负载；
2. 当须要将某个结点剔除时，只须要将其权重设置为0便可；

优势：实现简单、高效；易水平扩展；

缺点：请求到目的结点的不肯定，形成其没法适用于有写的场景（缓存，数据库写）

应用场景：数据库或应用服务层中只有读的场景；

随机方式

请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；

优势：实现简单、易水平扩展；

缺点：同Round Robin，没法用于有写的场景；

应用场景：数据库负载均衡，也是只有读的场景；

哈希：

根据key来计算须要落在的结点上，能够保证一个同一个键必定落在相同的服务器上；

优势：相同key必定落在同一个结点上，这样就可用于有写有读的缓存场景；

缺点：在某个结点故障后，会致使哈希键从新分布，形成命中率大幅度降低；

解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来；

应用场景：缓存，有读有写；

一致性哈希：

在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率；

如twemproxy中的ketama方案；

生产实现中还能够规划指定子key哈希，从而保证局部类似特征的键能分布在同一个服务器上；

优势：结点故障后命中率降低有限；

应用场景：缓存；

根据键的范围来负载：

根据键的范围来负载，前1亿个键都存放到第一个服务器，1~2亿在第二个结点；

优势：水平扩展容易，存储不够用时，加服务器存放后续新增数据；

缺点：负载不均；数据库的分布不均衡；（数据有冷热区分，通常最近注册的用户更加活跃，这样形成后续的服务器很是繁忙，而前期的结点空闲不少）

适用场景：数据库分片负载均衡；

根据键对服务器结点数取模来负载：

根据键对服务器结点数取模来负载；好比有4台服务器，key取模为0的落在第一个结点，1落在第二个结点上。

优势：数据冷热分布均衡，数据库结点负载均衡分布；

缺点：水平扩展较难；

适用场景：数据库分片负载均衡；

纯动态结点负载均衡：

根据CPU、IO、网络的处理能力来决策接下来的请求如何调度；

优势：充分利用服务器的资源，保证个结点上负载处理均衡；

缺点：实现起来复杂，真实使用较少；

不用主动负载均衡：

使用消息队列转为异步模型，将负载均衡的问题消灭

负载均衡是一种推模型，一直向你发数据，那么，将全部的用户请求发到消息队列中，全部的下游结点谁空闲，谁上来取数据处理；转为拉模型以后，消息了负载的问题；

优势：经过消息队列的缓冲，保护后端系统，请求剧增时不会冲垮后端服务器；

水平扩展容易，加入新结点后，直接取queue便可；

缺点：不具备实时性；

应用场景：不须要实时返回的场景；

好比，12036下订单后，马上返回提示信息：您的订单进去排队了…等处理完毕后，再异步通知；