什么是hash函数

哈希函数（Hash Function），也称为散列函数，给定一个输入 x ，它会算出相应的输出 H(x) 。哈希函数的主要特征是：

另外哈希函数一般还要求以下两种特点：

1、免碰撞 ：即不会出现输入 x≠y ，但是H(x)=H(y) 的情况，其实这个特点在理论上并不成立，比如目前比特币使用的 SHA256 算法，会有 2^256 种输出，如果我们进行 2^256 + 1 次输入，那么必然会产生一次碰撞，事实上，通过 理论证明 ，通过 2^130 次输入就会有99%的可能性发生一次碰撞，不过即使如此，即便是人类制造的所有计算机自宇宙诞生开始一直运算到今天，发生一次碰撞的几率也是极其微小的。

2、隐匿性 ：也就是说，对于一个给定的输出结果 H(x) ，想要逆推出输入 x ，在计算上是不可能的。如果想要得到 H(x) 的可能的原输入，不存在比穷举更好的方法。

hash 算法的原理是试图将一个空间的数据集映射到另外一个空间（通常比原空间要小），并利用质数将数据集能够均匀的映射。目前主流的 hash 算法有： md4 、 md5 、 sha系列 。

MD4是麻省理工学院教授 Ronald Rivest 于1990年设计出来的算法。其摘要长度为128位，一般用32位的十六进制来表示。

2004年8月清华大学教授王小云，指出在计算MD4时可能发生杂凑冲撞。不久之后，Dobbertin 等人发现了MD4在计算过程中第一步和第三步中的漏洞，并向大家演示了如何利用一部普通电脑在几分钟内找到MD4中的冲突，毫无疑问，MD4就此被淘汰掉了。

1991年，Rivest 开发出技术上更为趋近成熟的MD5算法，它在MD4的基础上增加了"安全-带子"（safety-belts）的概念。虽然 MD5 比 MD4 复杂度大一些，但却更为安全。这个算法很明显的由四个和 MD4 设计有少许不同的步骤组成。

MD5 拥有很好的抗修改性，即对原数据进行任何改动，哪怕只修改1个字节，所得到的MD5值都有很大区别。

MD5很好的用在了大文件的断点续传上：如果有一个 5MB 的文件 客户端把它分割成5片 1MB 的文件 在上传的时候上传两个 MD5 值，一个是当前上传的文件片的 MD5 还有一个就是拼接之后的 MD5 (如果现在上传的是第二片 这个MD5就应该是第一片加上第二片的MD5)， 通过这样的方式能保证文件的完整性。

当如果文件传到一半断了，服务器可以通过验证文件 MD5 值就可以得知用户已经传到了第几片，并且知道之前上传的文件有没有发生变化，就可以判断出用户需要从第几片开始传递。

不过在2004年8月的国际密码学会议（Crypto’2004），王小云提出了一种快速找到 MD5 碰撞的方法（参见其 论文 ），降低了 MD5 的安全性，人们开始寻求更加可靠的加密算法。

SHA的全称是Secure Hash Algorithm(安全hash算法)，SHA系列有五个算法，分别是 SHA-1、SHA-224、SHA-256、SHA-384，和SHA-512，由美国国家安全局（NSA）所设计，并由美国国家标准与技术研究院（NIST）发布，是美国的政府标准。后四者有时并称为 SHA-2。SHA-1在许多安全协定中广为使用，包括 TLS/SSL 等，是 MD5 的后继者。

最初该算法于1993年发布，称做安全散列标准 (Secure Hash Standard)，最初这个版本被称为"SHA-0"，它在发布之后很快就被NSA撤回，因为有很大的安全缺陷，之后在1995年发布了修订版本，也就是SHA-1。

SHA-0 和 SHA-1 会从一个最大 2^64 位元的讯息中产生一串 160 位元的摘要，然后以 MD4 及 MD5 算法类似的原理来加密。

2017年，谷歌发布了最新的研究成功，宣布攻破了SHA-1，并详细描述了成功的SHA1碰撞攻击方式，使用这种方式，可以在亚马逊的云计算平台上，耗时10天左右创建出SHA-1碰撞，并且成本可以控制在11万美元以内。

即使如此，对于单台机器来说攻击的成本依然很高，发生一次SHA-1碰撞需要超过 9,223,372,036,854,775,808 个SHA1计算，这需要使用你的机器进行6500年计算。

SHA2包括了SHA-224、SHA-256、SHA-384，和SHA-512，这几个函数都将讯息对应到更长的讯息摘要，以它们的摘要长度（以位元计算）加在原名后面来命名，也就是说SHA-256会产生256位长度摘要。

SHA-2相对来说是安全的，至今尚未出现对SHA-2有效的攻击！

由于目前大量的网站使用的SSL数字证数都是使用SHA-1签名的，而SHA-1又已经不安全，各大浏览器厂商均宣布了弃用SHA-1的时间表：

可以看出，在时间表之后，如果检测到网站的证书使用的还是SHA-1，就会d出警告：

为了防止网站因出现上面的警告而显得不专业，我们需要尽快的申请使用跟安全放心的基于SHA-2签名的证书。

redis cluster 有固定的 16384 个 hash slot，对每个 key 计算 CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。

为什么选择mod 16384呢？

官网说：在测试中发现，使用CRC16算法计算出来的key可以在16384个槽中均匀分布。

用一个例子看看hash slot是怎么实现的：

我们假设现在有3个节点已经组成了集群，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用hash slot的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

节点上使用 bitmap 记录各自的hash slot。

那么，现在我想设置一个key, 比如叫 my_name :

hash slot: CRC16('my_name')%16384 = 2412 。 那么就会把这个key 的存储分配到 A 上了。

我想获取my_name

会出现两种情况：

ps: client也可以缓存各节点的hash slot map

新增一个Node D:

从各个节点的前面各拿取一部分slot到Node D上

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

环割法（一致性 hash）环割法的原理如下：

1 初始化的时候生成分片数量 X × 环割数量 N 的固定方式编号的字符串，例如 SHARD-1-NODE-1，并计算所有 X×N 个字符串的所有 hash 值。

2 将所有计算出来的 hash 值放到一个排序的 Map 中，并将其中的所有元素进行排序。

3 输入字符串的时候计算输入字符串的 hash 值，查看 hash 值介于哪两个元素之间，取小于 hash 值的那个元素对应的分片为数据的分片。

跳跃法（jumpstringhash）跳跃法的原理如下：1 根据公式：

将数据落在每一个节点的概率进行平均分配。

2 对于输入的字符串进行计算 hash 值，通过判断每次产生的伪随机值是否小于当前判定的节点 1/x，最终取捕获节点编号最大的作为数据的落点。3 在实际使用中使用倒数的方法从最大节点值进行反向判断，一旦当产生的伪随机值大于 x 则判定此节点 x 作为数据的落点。

数据比较

下面将通过测试对环割法和跳跃法的性能及均衡性进行对比，说明 DBLE 为何使用跳跃法代替了环割法。

数据源：现场数据 350595 条

测试经过：

1 通过各自的测试方法执行对于测试数据的分片任务。

2 测试方法：记录分片结果的方差；记录从开始分片至分片结束的时间；记录分片结果与平均数的最大差值。

3 由于在求模法 PartitionByString 的方法中要求分片的数量是 1024 的因数，所以测试过程只能使用 2 的指数形式进行测试，并在 PartitionByString 方法进行测试的时候不对于 MAC 地址进行截断，取全量长度进行测试。

使用。

设定一个圆环上 0-2^3̂2-1 的点，每个点对应一个缓存区，每个键值对存储的位置也经哈希计算后对应到环上节点。但现实中不可能有如此多的节点，所以倘若键值对经哈希计算后对应的位置没有节点，那么顺时针找一个节点存储它。

1、考虑增加服务器节点的情况，该节点顺时针方向的数据仍然被存储到顺时针方向的节点上，但它逆时针方向的数据被存储到它自己。这时候只有部分数据会失效，被映射到新的缓存区。

2、考虑节点减少的情况。该缺失节点顺时针方向上的数据仍然被存储到其顺时针方向上的节点，设为 beta，其逆时针方向上的数据会被存储到 beta 上。同样，只有有部分数据失效，被重新映射到新的服务器节点。

扩展资料：

一致性哈希算法

这种方法可以应对节点失效的情况，当某个分布式集群节点宕机，服务请求可以通过hash算法重新分配到其他可用的服务器上。避免了无法处理请求的状况出现  。

但这种方法的缺陷也很明显，如果服务器中保存有服务请求对应的数据，那么如果重新计算请求的hash值，会造成大量的请求被重定位到不同的服务器而造成请求所要使用的数据失效，这种情况在分布式系统中是非常糟糕的。

一个设计良好的分布式系统应该具有良好的单调性，即服务器的添加与移除不会造成大量的哈希重定位，而一致性哈希恰好可以解决这个问题。

ip_hash主要为了解决后端session不共享问题。
也就是说不可避免的会出现负载不能完美均衡的情况。
因为如果讲这个用户分配到另一台后端服务器上他的session就没了。
当然对于这种也有解决办法也很多。
说一个我正在用的方式。
1用户请求进来通过鉴权中心（通过node以及redis实现）给用户session换成userid。
2经过负载均衡服务器分配到随机的一台后端。
3后端通过userid来进行无状态 *** 作。
我是通过这种方式解决这个问题的。当然别的解决方法也都可以实现相应的功能

hash是指url上#和其后面的链接，#称之为锚点。
由于 hash 值变化不会导致浏览器向服务器发出请求，而且 hash 改变会触发 hashchange 事件（hashchange只能改变 # 后面的url片段）； 更关键的一点是，因为hash发生变化的url都会被浏览器记录下来，从而你会发现浏览器的前进后退都可以用了。

首先，hash 本来是拿来做页面定位的，如果拿来做路由的话，原来的锚点功能就不能用了。其次，hash 的传参是基于 url 的，如果要传递复杂的数据，会有体积的限制，而 history 模式不仅可以在url里放参数，还可以将数据存放在一个特定的对象中。
history api可以分为两大部分：切换和修改
1、切换历史状态包括back、forward、go
这三个方法，对应浏览器的前进，后退，跳转 *** 作；（跳转 *** 作：在前进后退上长按鼠标，会出来所有当前窗口的历史记录，从而可以跳转）

2、修改历史状态包括了 pushState, replaceState两个方法
这两个方法接收三个参数:stateObj, title, url

history模式下，不怕前进后退，就怕h5刷新页面，因为刷新页面是向服务器请求了。
history 模式改变 url 的方式会导致浏览器向服务器发送请求 ，这不是我们想看到的，我们需要在服务器端做处理：如果匹配不到任何静态资源，则应该始终返回同一个 html 页面。
nginx服务器配置：

---