负载均衡一二三

一、前言

这段时间看了一些关于负载均衡的论文和博客，对一些系统负载均衡算法有了一些浅见，在此记录总结，希望可以便人便己。

二、说明

“负载均衡”这个词在不同的场景下有不同的含义，这里所说的负载均衡指的是服务器端的负载均衡调度算法，主要在下图红圈所示的地方起作用：如何把客户端的请求更“好”的转发给server端。

这里还要稍微注意一点：对于有些应用服务器来说，如分布式的数据库服务器，客户端发来的请求是具有状态的（和以前的某个请求有关系）。也就是说，客户端请求一个key，只能由后端对应存储此key的数据库服务器来处理。此时的负载均衡无法做出太多的选择，除非存储此key的数据库服务器也不止一台。 这种情况下，为了后端数据库的负载能均衡些，我们希望在写入数据时，能够尽量达到数据分布的平衡性（其实，由于有冷热数据的存在，更准确的说，我们希望写入之后的数据在将来的请求负载能够相对来说均衡些。） 为了下文中好区分，这种需求，我们把它叫做对数据平衡的需求。

三、一些具体的负载均衡算法

3.1 轮询法

将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

3.2 加权轮询

在轮询的基础上，按照配置的权重将请求分发到每个服务器上，高性能的服务器能分配到更多的请求

3.3 随机方法

通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。

3.4 加权随机法

与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器。

3.5 最小连接数法

最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器 当前的连接情况，动态地选取其中当前 积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

但是，这种方式一般需要lLB保持和后端结点的通信（或者采取临时通信的方式）来判别后端的服务器是否处于空闲的状态。

3.6 the power of k random choices

这种方式和算是前面随机和最小连接数两种方式的折中，首先选择选择k个结点，然后在这k个节点中再负载较小的一个结点，把请求发送给它。 一般来说，k取2的居多。 虽然只做了一旦改进，但是据相关paper的研究，效果还不错呢。

详细的证明可以参照《The Power of Two Choices in Randomized Load Balancing》，公式有点多，我看的有些晕晕的╮(╯▽╰)╭ 还可以参考【1】中的介绍。

3.7 异步动态负载均衡

与上面介绍的最小连接数法类似，这种方式也是根据后端服务器当前的负载动态处理请求的资源。不同的是，前者采用的是 “推” 模型， 需要负载均衡器把请求推到后端可用的服务器上。而这里采用的是“拉” 模型， 将所有的用户请求发到消息队列中（这里的消息队列相当于请求的缓冲区），所有的下游结点谁空闲，谁上来取数据处理；转为拉模型之后，消除了对下行结点负载的问题。

这种方式本质上是把用户的请求缓存在请求队列中，等后端的某个服务器空闲了，再从队列中取出对应当前请求，从某种程度上保护了后端系统，也不需要负载均衡器和后端服务器进行通信（我甚至怀疑都不需要负载均衡器），但是容易使得client的请求无法得到实时的相应。

3.8 源地址哈希

根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在一个服务器上处理。

3.9 根据请求的key进行哈希

根据key来hash计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上； 相同key一定落在同一个结点上，这种方式可以用于有状态的数据读写请求场景，如果hash函数得当的话，数据在后端结点的分布相对来说也是均匀的。

但是，这种方式也有缺点，当新增结点、或者因为节点故障而减少结点之时，会造成hash键值重新分布，会造成原来存储的大规模数据失效。如果应用的缓存场景则需要重新从实际的数据库中读取失效的数据；如果应用的是在真实的数据库中，则需要进行大规模的数据迁移。后面介绍的一致性hash可以解决上面的这个问题。 具体的介绍可以参照【2】。

3.10 一致性哈希

关于具体一致性hash的原理，这里就不详述了。可以参照以下【2】【3】【4】。

一致性哈希最重要的优势就是在服务器结点进行增删之时，只影响一部分数据，最大程度的保证了命中率(或者说保证了最少的数据迁移)。

关于一致性hash的缺点，研究了好久发现其好像没有明显的缺陷，；有人说其不适用于多副本的策略，但我看感觉给物理结点弄个集群也可以达到多副本可用性的效果；有人说其不适合底层异构的存储，我和舍友讨论了一下，发现如果根据不同的底层存储配置，使用不同的物理结点和虚拟节点的对应比例(即，配置高的磁盘映射多些虚拟节点，配置低的磁盘映射少些) 。 如果小伙伴有啥新的见解，可以告诉我 (^▽)？

注：以上介绍的几种hash 方法，大都用于数据分布平衡类的操作，对于无状态的数据请求，效果感觉和普通的随机选择算法差不了太多（hash从某种程度上来说也是一种随机选择）。

3.11 CRUSH算法

CRUSH算法是Ceph中的核心算法， 它主要是ceph用来控制数据分布的， 其通过这种算法把数据分布的查询变成了计算，一定程度上提高了服务器端的效率。关于具体的crush算法网上有很多优秀的资料，我这里就不详述了。 可以参照以【6】-【8】。

下面crush算法和一致性hash 和做以下对比：

1. 可扩展性相对较高，当增删结点是只会有少量的数据失效（或者只需要少量的数据迁移）。从某种程度上说，一致性hash也从另一个层面上做到了这点（通过把hash值映射成2 32-1 个槽，并把它们编成一个环），它也不需要全局进行数据迁移（但是盲猜效果可能没有crush要好）。

   对于数据迁移来说，这里稍微多说两句。 就我目前理解，在一个数据库集群中如果新增了一个结点，最好的方式其他的结点平均的把部分数据迁移给新增的结点。 而这种数据迁移过程，crush算法（straw方式）和一致性hash分别是通过以下方式实现的。
   
   cursh 算法的迁移示意图

一致性hash数据迁移示意图

2. 对于数据分布平衡性这点来说，CURSH 算法使用权重对各个结点进行伪随机映射数据，对于规模体量大的数据来说，其数据的大致分布和各个节点的权重大致相同； 同时，对于一致性hash算法来说，它的数据分布的平衡性是靠着虚拟节点的数据来完成的，只有虚拟节点的数据相对较多时，数据分布才会相对平衡些。
3. 从可靠性来说，crush算法原生配备了各种副本存放策略，而原生的一致性hash就我了解目前还没有。
4. 就底层存储的异构性(这里的异构性只要是指结点的配置，如磁盘的容量等)来看，crush 也是利用每个bucket和osd 的权重匹配底层结点的异构性，而一致性hash 目前就是靠物理节点映射不同数量的虚拟节点来实现。效果上来说，cursh可能更好些（同样是猜测）。
   

3.12 其他

以上就是基本的、比较常见的一些负载均衡的方式。 还有一些其他负载均衡方式是通过别的架构实现的。 如paper 《Small Cache, Big Effect》中提到的使用一层cache 来“过滤”热点数据，从而使到达后端的请求相对来说均衡些。 如下图所示。

这里面还有很多干货，具体的可以参照【9】-【13】。

四、参考资料

1. The Power of Two Random Choices
2. 一致性 hash 算法（ consistent hashing ）
3. 一致性 Hash 算法分析
4. A Guide to Consistent Hashing
5. 白话分布式系统中的一致性哈希算法
6. 大话Ceph–CRUSH那点事儿
7. Ceph Crush算法详解
8. 从一致性 hash 到 ceph crush
9. Small Cache, Big Effect
10. The Power of Two Random Choices
11. FAST19 | DistCache：分布式缓存
12. FAST 2019 DistCache
13. [Paper Review]FAST’19 DistCache