负载均衡hash算法

⑴ 负载均衡是怎么做的~

1、服务直接返回：这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。

2、桥接模式：桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。

3、路由模式：路由模式的部署方式，服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。

(1)负载均衡hash算法扩展阅读

负载均衡的算法:

1、随机算法：Random随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

2、哈希算法：一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

3、URL散列：通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。

参考资料

网络-负载均衡

⑵ nginx 负载均衡之一致性hash，普通hash

哈希负载均衡原理
  ngx_http_upstream_hash_mole支持普通的hash及一致性hash两种负载均衡算法，默认的是普通的hash来进行负载均衡。
  nginx 普通的hash算法支持配置http变量值作为hash值计算的key，通过hash计算得出的hash值和总权重的余数作为挑选server的依据；nginx的一致性hash(chash)算法则要复杂一些。这里会对一致性hash的机制原理作详细的说明。
一致性hash算法的原理
一致性hash用于对hash算法的改进，后端服务器在配置的server的数量发生变化后，同一个upstream server接收到的请求会的数量和server数量变化之间会有变化。尤其是在负载均衡配置的upstream server数量发生增长后，造成产生的请求可能会在后端的upstream server中并不均匀，有的upstream server负载很低，有的upstream server负载较高，这样的负载均衡的效果比较差，可能对upstream server造成不良的影响。由此，产生了一致性hash算法来均衡。
   那么为什么一致性hash算法能改善这种情况呢？这里引用网上资料的一致性hash算法的图例。
因为对于hash(k)的范围在int范围，所以我们将0~2^32作为一个环。其步骤为：
1，求出每个服务器的hash（服务器ip）值，将其配置到一个 0~2^n 的圆环上（n通常取32）。
2，用同样的方法求出待存储对象的主键 hash值，也将其配置到这个圆环上，然后从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
其分布如图：

除了上边的优点，其实还有一个优点：对于热点数据，如果发现node1访问量明显很大，负载高于其他节点，这就说明node1存储的数据是热点数据。这时候，为了减少node1的负载，我们可以在热点数据位置再加入一个node，用来分担热点数据的压力。
雪崩效应

接下来我们来看一下，当有节点宕机时会有什么问题。如下图：

如上图，当B节点宕机后，原本存储在B节点的k1，k2将会迁移到节点C上，这可能会导致很大的问题。如果B上存储的是热点数据，将数据迁移到C节点上，然后C需要承受B+C的数据，也承受不住，也挂了。。。。然后继续CD都挂了。这就造成了雪崩效应。
上面会造成雪崩效应的原因分析：
如果不存在热点数据的时候，每台机器的承受的压力是M/2(假设每台机器的最高负载能力为M)，原本是不会有问题的，但是，这个时候A服务器由于有热点数据挂了，然后A的数据迁移至B，导致B所需要承受的压力变为M（还不考虑热点数据访问的压力），所以这个失败B是必挂的，然后C至少需要承受1.5M的压力。。。。然后大家一起挂。。。
所以我们通过上面可以看到，之所以会大家一起挂，原因在于如果一台机器挂了，那么它的压力全部被分配到一台机器上，导致雪崩。

怎么解决雪崩问题呢，这时候需要引入虚拟节点来进行解决。
虚拟节点

虚拟节点，我们可以针对每个实际的节点，虚拟出多个虚拟节点，用来映射到圈上的位置，进行存储对应的数据。如下图：

如上图：A节点对应A1，A2，BCD节点同理。这时候，如果A节点挂了，A节点的数据迁移情况是:A1数据会迁移到C2，A2数据迁移到D1。这就相当于A的数据被C和D分担了，这就避免了雪崩效应的发送，而且虚拟节点我们可以自定义设置，使其适用于我们的应用。

ngx_http_upstream_consistent_hash
该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器，比如：

指令
语法：consistent_hash variable_name
默认值：none
上下文：upstream

配置upstream采用一致性hash作为负载均衡算法，并使用配置的变量名作为hash输入。

参考文档：
https://www.cnblogs.com/FengGeBlog/p/10615345.html
http://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-mole/

⑶ 负载均衡算法 — 轮询

在分布式系统中，为了实现负载均衡，必然会涉及到负载调度算法，如 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}。对于神秘的平滑加权轮询算法，我将在后续文章中详细介绍它的原理和实现。

轮询算法是最简单的调度算法，因为它无需记录当前所有连接的状态，所以它是一种 无状态 的调度算法，这些特性使得它应用较广。

轮询调度算法并不能动态感知每个实例的负载，它完全依赖于我们的工程经验，人为配置权重来实现基本的负载均衡，并不能保证服务的高可用性。若服务的某些实例因其他原因负载突然加重，轮询调度还是会一如既往地分配请求给这个实例，因此可能会形成小面积的宕机，导致服务的局部不可用。

相关文章 »

⑷ 负载均衡的几种常用方式

理解负载均衡，必须先搞清楚正向代理和反向代理。

注：

正向代理，代理的是用户。

反向代理，代理的是服务器

什么是负载均衡

当一台服务器的单位时间内谨陪毕的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。

我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。

负载均衡是用反向代理的原理实现的。

1、轮询（默认）

每个请求 按时间顺序逐一分配 到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstreambackserver {server192.168.0.14;server192.168.0.15;}

2、weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均乱隐的

情况。

upstreambackserver {server192.168.0.14weight=3;server192.168.0.15weight=7;}

权重越高，在被访问的概率越大，如上例，分别是30%，70%。

3、上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。

我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstreambackserver{ip_hash;server192.168.0.14:88;server192.168.0.15:80;}

4、fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstreambackserver {serverserver1;serverserver2;fair;}

5、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

upstream backserver {    server squid1:3128;    server squid2:3128;    hash$request_uri;    hash_method crc32;}123456

每个设备的状态设置为:

down 表示单前的server暂时不参与负载

weight 默认为1.weight越大，负载的权重就祥芹越大。

max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回 proxy_next_upstream模块定义的错误

fail_timeout:max_fails次失败后，暂停的时间。

backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

配置实例：

#user  nobody;worker_processes4;events {# 最大并发数worker_connections1024;}http{# 待选服务器列表upstream myproject{# ip_hash指令，将同一用户引入同一服务器。ip_hash;        server125.219.42.4fail_timeout=60s;        server172.31.2.183;        }    server{# 监听端口listen80;# 根目录下location / {# 选择哪个服务器列表proxy_pass http://myproject;                }            }

摘自https://www.cnblogs.com/lcword/p/12513155.html

⑸ 哈希算法从原理到实战

引言 

       将任意长度的二进制字符串映射为定长二进制字符串的映射规则我们称为散列（hash）算法，又叫哈希（hash）算法，而通过原始数据映射之后得到的二进制值称为哈希值。哈希表（hash表）结构是哈希算法的一种应用，也叫散列表。用的是数组支持按照下标随机访问数据的特性扩展、演化而来。可以说没有数组就没有散列表。

哈希算法主要特点

        从哈希值不能反向推导原始数据，也叫单向哈希。

        对输入数据敏感，哪怕只改了一个Bit，最后得到的哈希值也大不相同。

        散列冲突的概率要小。

        哈希算法执行效率要高，散列结果要尽量均衡。

哈希算法的核心应用

         安全加密 ：对于敏感数据比如密码字段进行MD5或SHA加密传输。

         唯一标识 ：比如图片识别，可针对图像二进制流进行摘要后MD5，得到的哈希值作为图片唯一标识。

         散列函数 :是构造散列表的关键。它直接决定了散列冲突的概率和散列表的性质。不过相对哈希算法的其他方面应用，散列函数对散列冲突要求较低，出现冲突时可以通过开放寻址法或链表法解决冲突。对散列值是否能够反向解密要求也不高。反而更加关注的是散列的均匀性，即是否散列值均匀落入槽中以及散列函数执行的快慢也会影响散列表性能。所以散列函数一般比较简单，追求均匀和高效。

        *负载均衡 ：常用的负载均衡算法有很多，比如轮询、随机、加权轮询。如何实现一个会话粘滞的负载均衡算法呢？可以通过哈希算法，对客户端IP地址或会话SessionID计算哈希值，将取得的哈希值与服务器列表大小进行取模运算，最终得到应该被路由到的服务器编号。这样就可以把同一IP的客户端请求发到同一个后端服务器上。

        *数据分片 ：比如统计1T的日志文件中“搜索关键词”出现次数该如何解决？我们可以先对日志进行分片，然后采用多机处理，来提高处理速度。从搜索的日志中依次读取搜索关键词，并通过哈希函数计算哈希值，然后再跟n(机器数)取模，最终得到的值就是应该被分到的机器编号。这样相同哈希值的关键词就被分到同一台机器进行处理。每台机器分别计算关键词出现的次数，再进行合并就是最终结果。这也是MapRece的基本思想。再比如图片识别应用中给每个图片的摘要信息取唯一标识然后构建散列表，如果图库中有大量图片，单机的hash表会过大，超过单机内存容量。这时也可以使用分片思想，准备n台机器，每台机器负责散列表的一部分数据。每次从图库取一个图片，计算唯一标识，然后与机器个数n求余取模，得到的值就是被分配到的机器编号，然后将这个唯一标识和图片路径发往对应机器构建散列表。当进行图片查找时，使用相同的哈希函数对图片摘要信息取唯一标识并对n求余取模操作后，得到的值k，就是当前图片所存储的机器编号，在该机器的散列表中查找该图片即可。实际上海量数据的处理问题，都可以借助这种数据分片思想，突破单机内存、CPU等资源限制。

        *分布式存储 ：一致性哈希算法解决缓存等分布式系统的扩容、缩容导致大量数据搬移难题。

         JDK集合工具实现 ：HashMap、 LinkedHashMap、ConcurrentHashMap、TreeMap等。Map实现类源码分析，详见  https://www.jianshu.com/p/602324fa59ac

总结

        本文从哈希算法的原理及特点，总结了哈希算法的常见应用场景。

        其中基于余数思想和同余定理实现的哈希算法（除留取余法），广泛应用在分布式场景中（散列函数、数据分片、负载均衡）。由于组合数学中的“鸽巢”原理，理论上不存在完全没有冲突的哈希算法。（PS:“鸽巢”原理是指有限的槽位，放多于槽位数的鸽子时，势必有不同的鸽子落在同一槽内，即冲突发生。同余定理：如果a和b对x取余数操作时a%x = b%x，则a和b同余）

        构造哈希函数的常规方法有：数据分析法、直接寻址法、除留取余法、折叠法、随机法、平方取中法等  。

        常规的解决哈希冲突方法有开放寻址法（线性探测、再哈希）和链表法。JDK中的HashMap和LinkedHashMap均是采用链表法解决哈希冲突的。链表法适合大数据量的哈希冲突解决，可以使用动态数据结构（比如：跳表、红黑树等）代替链表，防止链表时间复杂度过度退化导致性能下降；反之开放寻址法适合少量数据的哈希冲突解决。

⑹ 哈希（hash） - 哈希算法的应用

通过之前的学习，我们已经了解了哈希函数在散列表中的应用，哈希函数就是哈希算法的一个应用。那么在这里给出哈希的定义： 将任意长度的二进制值串映射为固定长度的二进制值串，这个映射规则就是哈希算法，得到的二进制值串就是哈希值 。
要设计一个好的哈希算法并不容易，它应该满足以下几点要求：

哈希算法的应用非常广泛，在这里就介绍七点应用：

有很多着名的哈希加密算法：MD5、SHA、DES...它们都是通过哈希进行加密的算法。
对于加密的哈希算法来说，有两点十分重要：一是很难根据哈希值反推导出原始数据；二是散列冲突的概率要很小。
当然，哈希算法不可能排除散列冲突的可能，这用数学中的 鸽巢原理 就可以很好解释。以MD5算法来说，得到的哈希值为一个 128 位的二进制数，它的数据容量最多为 2 ¹²⁸ bit，如果超过这个数据量，必然会出现散列冲突。
在加密解密领域没有绝对安全的算法，一般来说，只要解密的计算量极其庞大，我们就可以认为这种加密方法是较为安全的。

假设我们有100万个图片，如果我们在图片中寻找某一个图片是非常耗时的，这是我们就可以使用哈希算法的原理为图片设置唯一标识。比如，我们可以从图片的二进制码串开头取100个字节，从中间取100个字节，从结尾取100个字节，然后将它们合并，并使用哈希算法计算得到一个哈希值，将其作为图片的唯一标识。
使用这个唯一标识判断图片是否在图库中，这可以减少甚多工作量。

在传输消息的过程中，我们担心通信数据被人篡改，这时就可以使用哈希函数进行数据校验。比如BT协议中就使用哈希栓发进行数据校验。

在散列表那一篇中我们就讲过散列函数的应用，相比于其它应用，散列函数对于散列算法冲突的要求低很多（我们可以通过开放寻址法或链表法解决冲突），同时散列函数对于散列算法是否能逆向解密也并不关心。
散列函数比较在意函数的执行效率，至于其它要求，在之前的我们已经讲过，就不再赘述了。

接下来的三个应用主要是在分布式系统中的应用

复杂均衡的算法很多，如何实现一个会话粘滞的负载均衡算法呢？也就是说，我们需要在同一个客户端上，在一次会话中的所有请求都路由到同一个服务器上。

最简单的办法是我们根据客户端的 IP 地址或会话 ID 创建一个映射关系。但是这样很浪费内存，客户端上线下线，服务器扩容等都会导致映射失效，维护成本很大。

借助哈希算法，我们可以很轻松的解决这些问题：对客户端的 IP 地址或会话 ID 计算哈希值，将取得的哈希值域服务器的列表的大小进行取模运算，最后得到的值就是被路由到的服务器的编号。

假设有一个非常大的日志文件，里面记录了用户的搜索关键词，我们想要快速统计出每个关键词被搜索的次数，该怎么做呢？

分析一下，这个问题有两个难点：一是搜索日志很大，没办法放到一台机器的内存中；二是如果用一台机器处理这么大的数据，处理时间会很长。

针对这两个难点，我们可以先对数据进行分片，然后使用多台机器处理，提高处理速度。具体思路：使用 n 台机器并行处理，从日志文件中读出每个搜索关键词，通过哈希函数计算哈希值，然后用 n 取模，最终得到的值就是被分配的机器编号。
这样，相同的关键词被分配到了相同的机器上，不同机器只要记录属于自己那部分的关键词的出现次数，最终合并不同机器上的结果即可。

针对这种海量数据的处理问题，我们都可以采用多机分布式处理。借助这种分片思路，可以突破单机内存、CPU等资源的限制。

处理思路和上面出现的思路类似：对数据进行哈希运算，对机器数取模，最终将存储数据（可能是硬盘存储，或者是缓存分配）分配到不同的机器上。

你可以看一下上图，你会发现之前存储的数据在新的存储规则下全部失效，这种情况是灾难性的。面对这种情况，我们就需要使用一致性哈希算法。

哈希算法是应用非常广泛的算法，你可以回顾上面的七个应用感受一下。

其实在这里我想说的是一个思想： 用优势弥补不足 。
例如，在计算机中，数据的计算主要依赖 CPU ，数据的存储交换主要依赖内存。两者一起配合才能实现各种功能，而两者在性能上依然无法匹配，这种差距主要是： CPU运算性能对内存的要求远高于现在的内存能提供的性能。
也就是说，CPU运算很快，内存相对较慢，为了抹平这种差距，工程师们想了很多方法。在我看来，散列表的使用就是利用电脑的高计算性能（优势）去弥补内存速度（不足）的不足，你仔细思考散列表的执行过程，就会明白我的意思。

以上就是哈希的全部内容