㈠ 分布式系统常用的一致性算法有哪些
在做服务器负载均衡时候可供选择的负载均衡的算法有很多，包括： 轮循算法（Round Robin）、哈希算法（HASH）、最少连接算法（Least Connection）、响应速度算法（Response Time）、加权法（Weighted ）等。其中哈希算法是最为常用的算法. 典型的应用场景是： 有N台服务器提供缓存服务，需要对服务器进行负载均衡，将请求平均分发到每台服务器上，每台机器负责1/N的服务。 常用的算法是对hash结果取余数 (hash() mod N)：对机器编号从0到N-1，按照自定义的hash()算法，对每个请求的hash()值按N取模，得到余数i，然后将请求分发到编号为i的机器。但这样的算法方法存在致命问题，如果某一台机器宕机，那么应该落在该机器的请求就无法得到正确的处理，这时需要将当掉的服务器从算法从去除，此时候会有(N-1)/N的服务器的缓存数据需要重新进行计算；如果新增一台机器，会有N /(N+1)的服务器的缓存数据需要进行重新计算。对于系统而言，这通常是不可接受的颠簸（因为这意味着大量缓存的失效或者数据需要转移）。那么，如何设计一个负载均衡策略，使得受到影响的请求尽可能的少呢？ 在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了Consistent Hashing算法，可以说Consistent Hashing 是分布式系统负载均衡的首选算法。 1、Consistent Hashing算法描述 下面以Memcached中的Consisten Hashing算法为例说明。 由于hash算法结果一般为unsigned int型，因此对于hash函数的结果应该均匀分布在[0,232-1]间，如果我们把一个圆环用232 个点来进行均匀切割，首先按照hash(key)函数算出服务器（节点）的哈希值， 并将其分布到0～232的圆上。 用同样的hash(key)函数求出需要存储数据的键的哈希值，并映射到圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器（节点）上。 Consistent Hashing原理示意图 新增一个节点的时候，只有在圆环上新增节点逆时针方向的第一个节点的数据会受到影响。删除一个节点的时候，只有在圆环上原来删除节点顺时针方向的第一个节点的数据会受到影响，因此通过Consistent Hashing很好地解决了负载均衡中由于新增节点、删除节点引起的hash值颠簸问题。 Consistent Hashing添加服务器示意图 虚拟节点（virtual nodes）：之所以要引进虚拟节点是因为在服务器（节点）数较少的情况下（例如只有3台服务器），通过hash(key)算出节点的哈希值在圆环上并不是均匀分布的（稀疏的），仍然会出现各节点负载不均衡的问题。虚拟节点可以认为是实际节点的复制品（replicas），本质上与实际节点实际上是一样的（key并不相同）。引入虚拟节点后，通过将每个实际的服务器（节点）数按照一定的比例(例如200倍)扩大后并计算其hash(key)值以均匀分布到圆环上。在进行负载均衡时候，落到虚拟节点的哈希值实际就落到了实际的节点上。由于所有的实际节点是按照相同的比例复制成虚拟节点的州胡氏，因此解决了节点数较少的情况下哈希值在圆环上均匀分布的问题。 虚拟节点对Consistent Hashing结果的影响 从上图可以看出，在节点数为10个的情况下，每个实际节点的虚拟节点数为实际做团节点的100-200倍的时候，结果还是很均衡的。 第3段中有这些文字：“但这样的算法方法存在致命问题，如果某一台机器宕机，那么应该落在该机器的请求就无法册散得到正确的处理，这时需要将当掉的服务器从算法从去除，此时候会有(N-1)/N的服务器的缓存数据需要重新进行计算；” 为何是 (N-1)/N 呢？解释如下： 比如有 3 台机器，hash值 1-6 在这3台上的分布就是： host 1: 1 4 host 2: 2 5 host 3: 3 6 如果挂掉一台，只剩两台，模数取 2 ，那么分布情况就变成： host 1: 1 3 5 host 2: 2 4 6 可以看到，还在数据位置不变的只有2个： 1，2，位置发生改变的有4个，占共6个数据的比率是 4/6 = 2/3这样的话，受影响的数据太多了，势必太多的数据需要重新从 DB 加载到 cache 中，严重影响性能 【consistent hashing 的办法】 上面提到的 hash 取模，模数取的比较小，一般是负载的数量，而 consistent hashing 的本质是将模数取的比较大，为 2的32次方减1，即一个最大的 32 位整数。然后，就可以从容的安排数据导向了，那个图还是挺直观的。 以下部分为一致性哈希算法的一种PHP实现。点击下载
㈡ 负载均衡算法 — 轮询
在分布式系统中，为了实现负载均衡，必然会涉及到负载调度算法，如 Nginx 和 RPC 服务发现等场景。常见的负载均衡算法有 轮询 、 源地址 Hash 、 最少连接数 ，而 轮询 是最简单且应用最广的算法。
3 种常见的唤晌轮询调度算法，分别为 简单轮询 、 加权轮询 、 平滑加权轮询 。本文将用如下 4 个服务，来详细说明轮询调度过程。
简单轮询是轮询算法中最简单的一种，但扒桥由于它不支持配置负载，所以应用较少。
假设有 N 台实例 S = {S1, S2, …, Sn}，指示变量 currentPos 表示当前选择的实例 ID，初始化为 -1。算法可以描述为：
1、调度到下一个实例；
2、若所有实例已被 调度 过一次，则从头开始调度；
3、每次调度重复步骤 1、2；
调度过程，如下：
这里使用 PHP 来实现，源码见 fan-hao/load-balance 部分。
首先，定义一个统一的操作接口，主要有 init() 和 next() 这 2 个方法。
然后，根据简单轮询算法思路，实现上述接口：
其中， total 为总实例数量，春链猛 services 为服务实例列表。由于简单轮询不需要配置权重，因此可简单配置为：
在实际应用中，同一个服务会部署到不同的硬件环境，会出现性能不同的情况。若直接使用简单轮询调度算法，给每个服务实例相同的负载，那么，必然会出现资源浪费的情况。因此为了避免这种情况，一些人就提出了下面的 加权轮询 算法。
加权轮询算法引入了“权”值，改进了简单轮询算法，可以根据硬件性能配置实例负载的权重，从而达到资源的合理利用。
假设有 N 台实例 S = {S1, S2, …, Sn}，权重 W = {W1, W2, ..., Wn}，指示变量 currentPos 表示当前选择的实例 ID，初始化为 -1；变量 currentWeight 表示当前权重，初始值为 max(S)；max(S) 表示 N 台实例的最大权重值，gcd(S) 表示 N 台实例权重的最大公约数。
算法可以描述为：
1、从上一次调度实例起，遍历后面的每个实例；
2、若所有实例已被遍历过一次，则减小 currentWeight 为 currentWeight - gcd(S)，并从头开始遍历；若 currentWeight 小于等于 0，则重置为 max(S)；
3、 直到 遍历的实例的权重大于等于 currentWeight 时结束，此时实例为需调度的实例；
4、每次调度重复步骤 1、2、3；
例如，上述 4 个服务，最大权重 max(S) 为 4，最大公约数 gcd(S) 为 1。其调度过程如下：
这里使用 PHP 来实现，源码见 fan-hao/load-balance 部分。
其中， getMaxWeight() 为所有实例的最大权重值； getGcd() 为所有实例权重的最大公约数，主要是通过 gcd() 方法（可用 gmp_gcd() 函数）求得 2 个数的最大公约数，然后求每一个实例的权重与当前最大公约数的最大公约数。实现如下：
需要注意的是，在配置 services 服务列表时，需要指定其权重：
加权轮询 算法虽然通过配置实例权重，解决了 简单轮询 的资源利用问题，但是它还是存在一个比较明显的 缺陷 。例如：
服务实例 S = {a, b, c}，权重 W = {5, 1, 1}，使用加权轮询调度生成的实例序列为 {a, a, a, a, a, b, c}，那么就会存在连续 5 个请求都被调度到实例 a。而实际中，这种不均匀的负载是不被允许的，因为连续请求会突然加重实例 a 的负载，可能会导致严重的事故。
为了解决加权轮询调度不均匀的缺陷，一些人提出了 平滑加权轮询 调度算法，它会生成的更均匀的调度序列 {a, a, b, a, c, a, a}。对于神秘的平滑加权轮询算法，我将在后续文章中详细介绍它的原理和实现。
轮询算法是最简单的调度算法，因为它无需记录当前所有连接的状态，所以它是一种 无状态 的调度算法，这些特性使得它应用较广。
轮询调度算法并不能动态感知每个实例的负载，它完全依赖于我们的工程经验，人为配置权重来实现基本的负载均衡，并不能保证服务的高可用性。若服务的某些实例因其他原因负载突然加重，轮询调度还是会一如既往地分配请求给这个实例，因此可能会形成小面积的宕机，导致服务的局部不可用。
相关文章 »