End

数据结构与算法之美-8 散列表 哈希

本文地址

目录

目录

散列表

18 | 散列表（上）：Word文档中的单词拼写检查功能是如何实现的？

散列表的英文叫“Hash Table”，我们平时也叫它“哈希表”或者“Hash 表”。

散列表用的是数组支持按照下标随机访问数据的特性，所以散列表其实就是数组的一种扩展，由数组演化而来。

我们通过散列函数把元素的键值映射为下标，然后将数据存储在数组中对应下标的位置。当我们按照键值查询元素时，我们用同样的散列函数，将键值转化数组下标，从对应的数组下标的位置取数据。

散列函数设计的基本要求

  • 散列函数计算得到的散列值是一个非负整数
  • 如果 key1 = key2，那 hash(key1) == hash(key2)
  • 如果 key1 ≠ key2，那 hash(key1) ≠ hash(key2)

在真实的情况下，要想找到一个不同的 key 对应的散列值都不一样的散列函数，几乎是不可能的，即无法完全避免这种散列冲突。

散列冲突解决方法：开放寻址法

开放寻址法的核心思想是，如果出现了散列冲突，我们就重新探测一个空闲位置，将其插入。

那如何重新探测新的位置呢？一个比较简单的探测方法是，线性探测（Linear Probing）：当我们往散列表中插入数据时，如果某个数据经过散列函数散列之后，存储位置已经被占用了，我们就从当前位置开始，依次往后查找，看是否有空闲位置，直到找到为止。

1、插入操作

下图里面黄色的色块表示空闲位置，橙色的色块表示已经存储了数据。

从图中可以看出，散列表的大小为 10，在元素 x 插入散列表之前，已经 6 个元素插入到散列表中。x 经过 Hash 算法之后，被散列到位置下标为 7 的位置，但是这个位置已经有数据了，所以就产生了冲突。于是我们就顺序地往后一个一个找，看有没有空闲的位置，遍历到尾部都没有找到空闲的位置，于是我们再从表头开始找，直到找到空闲位置 2，于是将其插入到这个位置。

2、查找操作

我们通过散列函数求出要查找元素的键值对应的散列值，然后比较数组中下标为散列值的元素和要查找的元素：

  • 如果相等，则说明就是我们要找的元素
  • 否则就顺序往后依次查找
  • 如果遍历到数组中的空闲位置，还没有找到，就说明要查找的元素并没有在散列表中

3、删除操作

对于使用线性探测法解决冲突的散列表，删除操作稍微有些特别。我们不能单纯地把要删除的元素设置为空，因为在查找的时候，一旦我们通过线性探测方法找到一个空闲位置，我们就可以认定散列表中不存在这个数据。但是，如果这个空闲位置是我们后来删除的，就会导致原来的查找算法失效。本来存在的数据，会被认定为不存在。这个问题如何解决呢？

我们可以将删除的元素，特殊标记为 deleted。当线性探测查找的时候，遇到标记为 deleted 的空间，并不是停下来，而是继续往下探测。

4、线性探测法的缺点

线性探测法其实存在很大问题。当散列表中插入的数据越来越多时，散列冲突发生的可能性就会越来越大，空闲位置会越来越少，线性探测的时间就会越来越久。极端情况下，我们可能需要探测整个散列表，所以最坏情况下的时间复杂度为 O(n)。同理，在删除和查找时，也有可能会线性探测整张散列表，才能找到要查找或者删除的数据。

5、二次探测和双重散列

对于开放寻址冲突解决方法，除了线性探测方法之外，还有另外两种比较经典的探测方法，二次探测（Quadratic probing）和双重散列（Double hashing）。

所谓二次探测，跟线性探测很像，线性探测每次探测的步长是 1，而二次探测探测的步长就变成了原来的二次方，也就是说，它探测的下标序列就是 hash(key)+0，hash(key)+1^2，hash(key)+2^2。

所谓双重散列，意思就是不仅要使用一个散列函数。我们使用一组散列函数 hash1(key)，hash2(key)，hash3(key)……我们先用第一个散列函数，如果计算得到的存储位置已经被占用，再用第二个散列函数，依次类推，直到找到空闲的存储位置。

6、装载因子

不管采用哪种探测方法，当散列表中空闲位置不多的时候，散列冲突的概率就会大大提高。为了尽可能保证散列表的操作效率，一般情况下，我们会尽可能保证散列表中有一定比例的空闲槽位。我们用装载因子 load factor 来表示空位的多少。

散列表的装载因子 = 填入表中的元素个数/散列表的长度

散列冲突解决方法：链表法

链表法是一种更加常用的散列冲突解决办法。

在散列表中，每个 桶bucket 或者 槽slot 会对应一条链表，所有散列值相同的元素我们都放到相同槽位对应的链表中。

当插入的时候，我们只需要通过散列函数计算出对应的散列槽位，将其插入到对应链表中即可，所以插入的时间复杂度是 O(1)。当查找、删除一个元素时，我们同样通过散列函数计算出对应的槽，然后遍历链表查找或者删除。

内容小结

散列表来源于数组，它借助散列函数对数组这种数据结构进行扩展，利用的是数组支持按照下标随机访问元素的特性。散列表两个核心问题是散列函数设计和散列冲突解决。散列冲突有两种常用的解决方法，开放寻址法和链表法。散列函数设计的好坏决定了散列冲突的概率，也就决定散列表的性能。

19 | 散列表（中）：如何打造一个工业级水平的散列表？

如何设计散列函数

首先，散列函数的设计不能太复杂。过于复杂的散列函数，势必会消耗很多计算时间，也就间接地影响到散列表的性能。

其次，散列函数生成的值要尽可能随机并且均匀分布，这样才能避免或者最小化散列冲突，而且即便出现冲突，散列到每个槽里的数据也会比较平均，不会出现某个槽内数据特别多的情况。

装载因子过大了怎么办：动态扩容

对于动态散列表来说，数据集合是频繁变动的，我们事先无法预估将要加入的数据个数，所以我们也无法事先申请一个足够大的散列表。随着数据慢慢加入，装载因子就会慢慢变大。当装载因子大到一定程度之后，散列冲突就会变得不可接受。

针对散列表，当装载因子过大时，我们也可以进行动态扩容，重新申请一个更大的散列表，将数据搬移到这个新散列表中。

但是，针对散列表的扩容，数据搬移操作要复杂很多。因为散列表的大小变了，数据的存储位置也变了，所以我们需要通过散列函数重新计算每个数据的存储位置。

实际上，对于动态散列表，随着数据的删除，散列表中的数据会越来越少，空闲空间会越来越多。如果我们对空间消耗非常敏感，我们可以在装载因子小于某个值之后，启动动态缩容。当然，如果我们更加在意执行效率，能够容忍多消耗一点内存空间，那就可以不用费劲来缩容了。

如何避免低效的扩容：均摊移动

为了解决一次性扩容耗时过多的情况，我们可以将扩容操作穿插在插入操作的过程中，分批完成。当装载因子触达阈值之后，我们只申请新空间，但并不将老的数据搬移到新散列表中。

当有新数据要插入时，我们将新数据插入新散列表中，并且从老的散列表中拿出一个数据放入到新散列表。每次插入一个数据到散列表，我们都重复上面的过程。经过多次插入操作之后，老的散列表中的数据就一点一点全部搬移到新散列表中了。这样没有了集中的一次性数据搬移，插入操作就都变得很快了。

这期间的查询操作，为了兼容了新、老散列表中的数据，我们先从新散列表中查找，如果没有找到，再去老的散列表中查找。

两种冲突解决方法的优缺点

Java 中 LinkedHashMap 采用了链表法解决冲突，ThreadLocalMap 是通过线性探测的开放寻址法来解决冲突。

开放寻址法的优缺点

  • 优点
    • 散列表中的数据都存储在数组中，可以有效地利用 CPU 缓存加快查询速度
    • 序列化起来比较简单
  • 缺点
    • 删除数据的时候比较麻烦，需要特殊标记已经删除掉的数据
    • 所有的数据都存储在一个数组中，比起链表法来说，冲突的代价更高
    • 使用开放寻址法解决冲突的散列表，装载因子的上限不能太大，这也导致这种方法比链表法更浪费内存空间

总结：当数据量比较小、装载因子小的时候，适合采用开放寻址法。这也是 Java 中的ThreadLocalMap使用开放寻址法解决散列冲突的原因。

链表法的优缺点

  • 优点
    • 链表法对内存的利用率比开放寻址法要高，因为链表结点可以在需要的时候再创建，并不需要像开放寻址法那样事先申请好
    • 链表法比起开放寻址法，对大装载因子的容忍度更高
      • 开放寻址法只能适用装载因子小于 1 的情况，接近 1 时，就可能会有大量的散列冲突，导致大量的探测、再散列等，性能会下降很多
      • 对于链表法来说，只要散列函数的值随机均匀，即便装载因子变成 10，也就是链表的长度变长了而已，虽然查找效率有所下降，但是比起顺序查找还是快很多
    • 对链表法稍加改造，可以实现一个更加高效的散列表
      • 将链表法中的链表改造为其他高效的动态数据结构，比如跳表、红黑树，极端情况下，最终退化成的散列表的查找时间也只不过是 O(logn)
  • 缺点：
    • 链表因为要存储指针，所以对于比较小的对象的存储，是比较消耗内存的，还有可能会让内存的消耗翻倍
      • 如果我们存储的是大对象，也就是说要存储的对象的大小远远大于一个指针的大小，那链表中指针的内存消耗在大对象面前就可以忽略了
    • 因为链表中的结点是零散分布在内存中的，不是连续的，所以对 CPU 缓存是不友好的，这方面对于执行效率也有一定的影响

总结：基于链表的散列冲突处理方法比较适合存储大对象、大数据量的散列表；而且，比起开放寻址法，它更加灵活，支持更多的优化策略，比如用红黑树代替链表。

工业级的散列表：HashMap

1、初始大小

HashMap 默认的初始大小是 16，如果事先知道大概的数据量有多大，可以通过修改默认初始大小，减少动态扩容的次数，这样会大大提高 HashMap 的性能。

2、装载因子和动态扩容

最大装载因子默认是 0.75，当 HashMap 中元素个数超过 0.75*capacity 的时候，就会启动扩容，每次扩容都会扩容为原来的两倍大小。

3、散列冲突解决方法

HashMap 底层采用链表法来解决冲突。

在 JDK1.8 版本中，为了对 HashMap 做进一步优化，当链表长度超过 8 时，链表就转换为红黑树。当红黑树结点个数少于 8 个的时候，又会将红黑树转化为链表。因为在数据量较小的情况下，红黑树要维护平衡，比起链表来，性能上的优势并不明显。

4、散列函数

int hash(Object key) {
    int h = key.hashCode()；
    return (h ^ (h >>> 16)) & (capicity -1); //capicity表示散列表的大小
}

20 | 散列表（下）：为什么散列表和链表经常会一起使用？

LRU 缓存淘汰算法

我们需要维护一个按照访问时间从大到小有序排列的链表结构，当要缓存某个数据的时候，先在链表中查找这个数据

  • 如果没有找到，则直接将数据放到链表的尾部
  • 如果找到了，我们就把它移动到链表的尾部
  • 当缓存空间不够的时候，我们就直接将链表头部的结点删除

因为查找数据需要遍历链表，所以单纯用链表实现的 LRU 缓存淘汰算法的时间复杂很高，是 O(n)。借助散列表，我们可以把 LRU 缓存淘汰算法的时间复杂度降低为 O(1)

因为我们的散列表是通过链表法解决散列冲突的，所以每个结点会在两条链中。一个链是刚刚我们提到的双向链表，另一个链是散列表中的拉链。前驱指针(prev)和后继指针(next)是为了将结点串在双向链表中，hnext 指针是为了将结点串在散列表的拉链中。

  • 如何查找一个数据
    • 通过散列表以O(1)的时间复杂度完成
    • 找到数据之后，我们还需要以O(1)的时间复杂度将它移动到双向链表的尾部
  • 如何删除一个数据，先查找数据
    • 找到数据之后，我们还需要以O(1)的时间复杂度将结点删除
    • 双向链表可以通过前驱指针以O(1)时间复杂度获取前驱结点
  • 如何添加一个数据：先查找数据
    • 如果找到了，需要以O(1)的时间复杂度将其移动到双向链表的尾部
    • 如果没找到，还要看缓存有没有满
      • 如果没有满，就直接将数据放到双向链表的尾部
      • 如果满了，则将双向链表头部的结点删除，然后再将数据放到双向链表的尾部

整个过程涉及的查找操作都可以通过散列表以O(1)的时间复杂度完成

Redis 有序集合

在有序集合中，每个成员对象有两个重要的属性，key（键值）和 score（分值）。

如果我们仅仅按照分值将成员对象组织成跳表的结构，那按照键值来查询、删除成员对象就会很慢。解决方法与 LRU 缓存淘汰算法的解决方法类似：

  • 我们可以先按照键值构建一个散列表，这样按照 key 来删除、查找一个成员对象的时间复杂度就变成了 O(1)
  • 同时，借助跳表结构，其他操作也非常高效

LinkedHashMap

LinkedHashMap 也是通过散列表和双向链表组合在一起实现的，它不仅支持按照插入顺序遍历数据，还支持按照访问顺序来遍历数据。

按照访问时间排序的 LinkedHashMap 本身就是一个支持 LRU 缓存淘汰策略的缓存系统。

  • 调用 put() 函数插入数据的时候，会先查找这个键值是否已经存在
    • 如果不存在，会将数据添加到链表的尾部
    • 如果存在，会先将已经存在的数据删除，然后将新的数据放到链表的尾部
  • 调用 get() 函数访问元素的时候，会将被访问到的数据移动到链表的尾部。

总结：LinkedHashMap 是通过双向链表和散列表这两种数据结构组合实现的，LinkedHashMap 中的Linked实际上是指的是双向链表，并非指用链表法解决散列冲突。

解答开篇 & 内容小结

为什么散列表和链表经常一块使用？

散列表这种数据结构虽然支持非常高效的数据插入、删除、查找操作，但是散列表中的数据都是通过散列函数打乱之后无规律存储的。也就说，它无法支持按照某种顺序快速地遍历数据。如果希望按照顺序遍历散列表中的数据，那我们需要将散列表中的数据拷贝到数组中，然后排序，再遍历。

但是因为散列表是动态数据结构，不停地有数据的插入、删除，所以每当我们希望按顺序遍历散列表中的数据的时候，都需要先排序，那效率势必会很低。为了解决这个问题，就需要将散列表和链表（或者跳表）结合在一起使用。

哈希算法

21 | 哈希算法（上）：如何防止数据库中的用户信息被脱库？

将任意长度的二进制值串映射为固定长度的二进制值串，这个映射的规则就是哈希算法，而通过原始数据映射之后得到的二进制值串就是哈希值。

hash算法的基本要求

  • 从哈希值不能反向推导出原始数据
  • 对输入数据非常敏感，哪怕原始数据只修改了一个 Bit，最后得到的哈希值也大不相同
  • 散列冲突的概率要很小，对于不同的原始数据，哈希值相同的概率非常小
  • 哈希算法的执行效率要尽量高效，针对较长的文本，也能快速地计算出哈希值

安全加密

  • MD5：Message-Digest Algorithm，MD5 消息摘要算法
  • SHA：Secure Hash Algorithm，安全散列算法
  • DES：Data Encryption Standard，数据加密标准
  • AES：Advanced Encryption Standard，高级加密标准

鸽巢原理（也叫抽屉原理）：如果有 10 个鸽巢，有 11 只鸽子，那肯定有 1 个鸽巢中的鸽子数量多于 1 个，换句话说就是，肯定有 2 只鸽子在 1 个鸽巢内。

下面这两段字符串经过 MD5 哈希算法加密之后，产生的哈希值是相同的。

没有绝对安全的加密。越复杂、越难破解的加密算法，需要的计算时间也越长。

唯一标识

如果要在海量的图库中，搜索一张图是否存在，我们不能单纯地用图片的元信息（比如图片名称）来比对，因为有可能存在名称相同但图片内容不同，或者名称不同图片内容相同的情况。那我们该如何搜索呢？

我们可以给每一个图片取一个唯一标识，或者说信息摘要。比如，我们可以从图片的二进制码串开头取 100 个字节，从中间取 100 个字节，从最后再取 100 个字节，然后将这 300 个字节放到一块，通过哈希算法（比如 MD5），得到一个哈希字符串，用它作为图片的唯一标识，通过这个唯一标识来判定图片是否在图库中。

如果还想继续提高效率，我们可以把每个图片的唯一标识，和相应的图片文件在图库中的路径信息，都存储在散列表中。当要查看某个图片是不是在图库中的时候，我们先通过哈希算法对这个图片取唯一标识，然后在散列表中查找是否存在这个唯一标识。

如果不存在，那就说明这个图片不在图库中；如果存在，我们再通过散列表中存储的文件路径，获取到这个已经存在的图片，跟现在要插入的图片做全量的比对，看是否完全一样。如果一样，就说明已经存在；如果不一样，说明两张图片尽管唯一标识相同，但是并不是相同的图片。

数据校验

BT 下载的原理是基于 P2P 协议的。我们从多个机器上并行下载一个 2GB 的电影，这个电影文件可能会被分割成很多文件块（比如可以分成 100 块，每块大约 20MB）。等所有的文件块都下载完成之后，再组装成一个完整的电影文件就行了。现在的问题是，如何来校验文件块的安全、正确、完整呢？

我们通过哈希算法，对 100 个文件块分别取哈希值，并且保存在种子文件中。当文件块下载完成之后，我们可以通过相同的哈希算法，对下载好的文件块逐一求哈希值，然后跟种子文件中保存的哈希值比对。如果不同，说明这个文件块不完整或者被篡改了，需要再重新从其他宿主机器上下载这个文件块。

散列函数

相对哈希算法的其他应用，散列函数对于散列算法冲突的要求要低很多。即便出现个别散列冲突，只要不是过于严重，我们都可以通过开放寻址法或者链表法解决。不仅如此，散列函数对于散列算法计算得到的值，是否能反向解密也并不关心。

散列函数中用到的散列算法，更加关注散列后的值是否能平均分布，也就是，一组数据是否能均匀地散列在各个槽中。除此之外，散列函数执行的快慢，也会影响散列表的性能，所以，散列函数用的散列算法一般都比较简单，比较追求效率。

区块链

区块链是一块块区块组成的，每个区块分为两部分：区块头和区块体。区块头保存着 自己区块体 和 上一个区块头 的哈希值。

因为这种链式关系和哈希值的唯一性，只要区块链上任意一个区块被修改过，后面所有区块保存的哈希值就不对了。

区块链使用的是 SHA256 哈希算法，计算哈希值非常耗时，如果要篡改一个区块，就必须重新计算该区块后面所有的区块的哈希值，短时间内几乎不可能做到。

解答开篇

我们可以通过哈希算法，对用户密码进行加密之后再存储，不过最好选择相对安全的加密算法，比如 SHA 等（因为 MD5 已经号称被破解了）。

字典攻击：维护一个常用密码的字典表，把字典中的每个密码用哈希算法计算哈希值，然后拿哈希值跟脱库后的密文比对。如果相同，基本上就可以认为，这个加密之后的密码对应的明文就是字典中的这个密码。

针对字典攻击，我们可以引入一个盐（salt），跟用户的密码组合在一起，增加密码的复杂度。我们拿组合之后的字符串来做哈希算法加密，将它存储到数据库中，进一步增加破解的难度。

安全和攻击是一种博弈关系，不存在绝对的安全。所有的安全措施，只是增加攻击的成本而已。

22 | 哈希算法（下）：哈希算法在分布式系统中有哪些应用？

实际上，哈希算法还有很多其他的应用，比如网络协议中的 CRC 校验、Git commit id 等等。

负载均衡

负载均衡算法有很多，比如轮询、随机、加权轮询等。那如何才能实现一个会话粘滞（session sticky）的负载均衡算法呢？也就是说，我们需要在同一个客户端上，在一次会话中的所有请求都路由到同一个服务器上。

最直接的方法就是，维护一张映射关系表，这张表的内容是客户端 IP 地址或者会话 ID 与服务器编号的映射关系。客户端发出的每次请求，都要先在映射表中查找应该路由到的服务器编号，然后再请求编号对应的服务器。

这种方法简单直观，但也有几个弊端：

  • 如果客户端很多，映射表可能会很大，比较浪费内存空间
  • 客户端下线、上线，服务器扩容、缩容都会导致映射失效，这样维护映射表的成本就会很大

我们可以通过哈希算法，对客户端 IP 地址或者会话 ID 计算哈希值，将取得的哈希值与服务器列表的大小进行取模运算，最终得到的值就是应该被路由到的服务器编号。这样，我们就可以把同一个 IP 过来的所有请求，都路由到同一个后端服务器上。

数据分片

如何快速判断图片是否在图库中

假设现在我们的图库中有 1 亿张图片，因为单台机器的内存有限，所以在单台机器上构建散列表是行不通的。

我们可以对数据进行分片，然后采用多机处理。我们准备 n 台机器，让每台机器只维护某一部分图片对应的散列表。我们每次从图库中读取一个图片，计算唯一标识，然后与机器个数 n 求余取模，得到的值就对应要分配的机器编号，然后将这个图片的唯一标识和图片路径发往对应的机器构建散列表。

当我们要判断一个图片是否在图库中的时候，我们通过同样的哈希算法，计算这个图片的唯一标识，然后与机器个数 n 求余取模。假设得到的值是 k，那就去编号 k 的机器构建的散列表中查找。

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

分布式存储

现在互联网面对的都是海量的数据、海量的用户。我们为了提高数据的读取、写入能力，一般都采用分布式的方式来存储数据，比如分布式缓存。我们有海量的数据需要缓存，所以一个缓存机器肯定是不够的。于是，我们就需要将数据分布在多台机器上。我们可以借用前面数据分片的思想，即通过哈希算法对数据取哈希值，然后对机器个数取模，这个最终值就是应该存储的缓存机器编号。

但是，如果数据增多，原来的 10 个机器已经无法承受了，我们就需要扩容了，比如扩到 11 个机器，这时候麻烦就来了。因为，这里并不是简单地加个机器就可以了。因为，按照原先的逻辑，所有的数据都要重新计算哈希值，然后重新搬移到正确的机器上。这样就相当于，缓存中的数据一下子就都失效了。所有的数据请求都会穿透缓存，直接去请求数据库。这样就可能发生雪崩效应，压垮数据库。

这时候，一致性哈希算法就要登场了。

一致性哈希算法

白话解析：一致性哈希算法 consistent hashing

假设我们有 k 个机器，数据的哈希值的范围是[0, MAX]。我们将整个范围划分成 m 个小区间（m 远大于 k），每个机器负责 m/k 个小区间。当有新机器加入的时候，我们就将某几个小区间的数据，从原来的机器中搬移到新的机器中。这样，既不用全部重新哈希、搬移数据，也保持了各个机器上数据数量的均衡。

一致性哈希算法的基本思想就是这么简单。除此之外，它还会借助一个虚拟的环和虚拟结点，更加优美地实现出来。

实际上，一致性哈希算法的应用非常广泛，在很多分布式存储系统中，都可以见到一致性哈希算法的影子。

2021-08-29

posted @ 2021-08-29 23:15  白乾涛  阅读(185)  评论(1)  编辑  收藏  举报