负载均衡的几种常用方案

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

Round Robin 轮询调度

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

针对服务器的性能差异可分配不同的负载；
当需要将某个结点剔除时，只需要将其权重设置为0即可；

优点：实现简单、高效；易水平扩展；
缺点：请求到目的结点的不确定，造成其无法适用于有写的场景（缓存，数据库写）
应用场景：数据库或应用服务层中只有读的场景；

随机方式

请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；
优点：实现简单、易水平扩展；
缺点：同Round Robin，无法用于有写的场景；
应用场景：数据库负载均衡，也是只有读的场景；

哈希方式

根据key来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上；
优点：相同key一定落在同一个结点上，这样就可用于有写有读的缓存场景；
缺点：在某个结点故障后，会导致哈希键重新分布，造成命中率大幅度下降；
解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来；
应用场景：缓存，有读有写；

一致性哈希

在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率；
如twemproxy中的ketama方案；
生产实现中还可以规划指定子key哈希，从而保证局部相似特征的键能分布在同一个服务器上；
优点：结点故障后命中率下降有限；
应用场景：缓存；

根据键的范围来负载

根据键的范围来负载，前1亿个键都存放到第一个服务器，1~2亿在第二个结点；
优点：水平扩展容易，存储不够用时，加服务器存放后续新增数据；
缺点：负载不均；数据库的分布不均衡；（数据有冷热区分，一般最近注册的用户更加活跃，这样造成后续的服务器非常繁忙，而前期的结点空闲很多）
适用场景：数据库分片负载均衡；

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

根据键对服务器结点数取模来负载；比如有4台服务器，key取模为0的落在第一个结点，1落在第二个结点上。
优点：数据冷热分布均衡，数据库结点负载均衡分布；
缺点：水平扩展较难；
适用场景：数据库分片负载均衡；

纯动态结点负载均衡

根据CPU、IO、网络的处理能力来决策接下来的请求如何调度；
优点：充分利用服务器的资源，保证个结点上负载处理均衡；
缺点：实现起来复杂，真实使用较少；

不用主动负载均衡；

使用消息队列转为异步模型，将负载均衡的问题消灭
负载均衡是一种推模型，一直向你发数据，那么，将所有的用户请求发到消息队列中，所有的下游结点谁空闲，谁上来取数据处理；转为拉模型之后，消除了对下行结点负载的问题；
优点：通过消息队列的缓冲，保护后端系统，请求剧增时不会冲垮后端服务器；
水平扩展容易，加入新结点后，直接取queue即可；
缺点：不具有实时性；
应用场景：不需要实时返回的场景；
比如，12036下订单后，立刻返回提示信息：您的订单进去排队了...等处理完毕后，再异步通知；