数据结构之hash

1. 散列表(哈希表)

1) hash函数

• 映射函数 hash(key)=addr ；hash 函数可能会把两个或两个以上的不同 key 映射到同一地址，这种情况称之为冲突（或者 hash 碰撞）；
• 选择hash函数的主要依据
  • 计算速度快
  • 强随机分布（等概率、均匀地分布在整个地址空间）
• 主流hash函数
  • murmurhash1，murmurhash2，murmurhash3，siphash（redis6.0当中使⽤，rust等大多数
    语言选用的hash算法来实现hashmap），cityhash 都具备强随机分布性；
  • siphash 主要解决字符串接近的强随机分布性 ;
• 负载因子
  • 负载因子 = 数组存储元素的个数 / 数据长度；用来形容散列表的存储密度；负载因子越小，冲突越小，负载因子越大，冲突越大；

2) 冲突处理

• 链表法
  引用链表来处理哈希冲突;也就是将冲突元素用链表链接起来;这也是常用的处理冲突的方式;但是可能出现一种极端情况，冲突元素比较多，该冲突链表过长，这个时候可以将这个链表转换为红黑树;由原来链表时间复杂度O(n)转换为红黑树时间复杂度O(log₂n);那么判断该链表过长的依据是多少?可以采用超过**256(经验值）**个节点的时候将链表结构转换为红黑树结构;
• 开放寻址法
  • 将所有的元素都存放在哈希表的数组中，不使用额外的数据结构；一般使用线性探查的思路解决；
    • 1）当插入新元素的时，使用哈希函数在哈希表中定位元素位置；
    • 2）检查数组中该槽位索引是否存在元素。如果该槽位为空，则插⼊，否则3；
    • 3）在 2 检测的槽位索引上加一定步长接着检查2； 加⼀定步长分为以下几种：
      • a. i+1,i+2,i+3,i+4, … ,i+n
      • b. i-1²,i+2² ,i-3² ,1+ 4², … 这两种都会导致**同类 hash 聚集**；也就是近似值它的hash值也近似，那么它的数组槽位也靠近，形成 hash 聚集；第一种同类聚集冲突在前，第二种只是将聚集冲突延后； 另外还可以使用双重哈希来解决上面出现hash聚集现象。

3) 应用场景

• 从海量日志数据中提取出某日访问百度（www.baidu.com）次数最多的那个IP。
  • 分析:百度作为国内第一大搜索引擎，每天访问它的IP数量巨大，如果想一次性把所有IP数据装进内存处理，内存容量通常不够，故针对数据量太大、内存受限的情况，可以把大文件转化成（取模映射）小文件，从而大而化小，逐个处理。简言之，先映射，而后统计，最后排序。
  • 解法:具体分为下述三个步骤。
    (1）分而治之/散列映射。先将该日访问百度的所有IP从访问日志中提取出来,然后逐个写入一个大文件中，接着采取散列映射的方法(如hash(IP)%1000)，把整个大文件的数据映射到1000个小文件中(相同IP肯定会映射到同一个文件中)。
    (2) hash_map统计。大文件转化成了小文件，便可以采用hash_map(ip，value)分别对1000个小文件的IP进行频率统计，找出每个小文件中出现频率最高的IP，总共1000个IP。
    (3）堆/快速排序。统计出1000个频率最高的IP后，依据它们各自频率的大小进行排序（可采取堆排序)，找出最终那个出现频率最高的IP，即为所求。
• hash 函数实现过程当中，为什么使用31作为乘数
  • i * 31 = i * (32-1) = i * (1<<5 -1) = i << 5 - i；乘积运算可以使用位移提升性能，同时目前的JVM虚拟机也会自动支持此类的优化。
  • 31 是一个质数，hash 随机分布性是最好的；质数和其他数相乘的结果比其他方式更容易产生唯一性，减少哈希冲突；31是经过观测分布结果后的选择；

2. 布隆过滤器

1) 什么是布隆过滤器

布隆过滤器（Bloom Filter）是由 Bloom 于 1970 年提出的。我们可以把它看作由二进制向量（或者说位数组）和一系列随机映射函数（哈希函数）两部分组成的数据结构。相比于我们平时常用的的 List、Map 、Set 等数据结构，它占用空间更少并且效率更高，但是缺点是其返回的结果是概率性的，而不是非常准确的。理论情况下添加到集合中的元素越多，误报的可能性就越大。并且，存放在布隆过滤器的数据不容易删除。
布隆过滤器通常用于判断某个 key 一定不存在的场景，同时允许判断存在时有误差的情况；

2) 背景

• 布隆过滤器是一种概率型数据结构，它的特点是高效地插入和查询，能确定某个字符串一定不存在或者可能存在；
• 布隆过滤器不存储具体数据，所以占用空间小，查询结果存在误差，但是误差可控，同时不支持删除操作；

3) 原理

• 构成
  • 位图（bit 数组）+ n 个 hash 函数
    
    说明：假设一个位图大小为 64bit 的布隆过滤器，使用C++的数据类型 byte buf[8] 来表示。如果，hash(val) = 173，则对 buf[5][5] 位置处的值赋为1。具体计算过程如下：
    a. 根据hash结果，计算具体地址: 173 % 64 = 173 & 63 = 45；
    b. 根据具体地址，计算列位置：j = 45 % 8 = 45 & 7 = 5;
    c. 根据具体地址，计算行位置：i = 45 / 8 = 5；
    位运算技巧：
    对于取余运算，可转换为位与运算，m % 2ⁿ= m & (2ⁿ - 1 )
• 原理
  • 当一个元素加入位图时，通过 k 个 hash 函数将这个元素映射到位图的 k 个点，并把它们置为 1；
    当检索时，再通过 k 个 hash 函数运算检测位图的 k 个点是否都为 1；如果有不为 1 的点，那么认为该 key 不存在；如果全部为 1，则可能存在；
    
  • 为什么不支持删除
    在位图中每个槽位只有两种状态（0 或者 1），一个槽位被设置为 1 状态，但不确定它被设置了多少次；也就是不知道被多少个key 哈希映射而来以及是被具体哪个 hash 函数映射而来；
    

4) 应用场景

• 判断给定数据是否存在
  • 从海量数据中查询某个字符串是否存在；
  • 使用 word 文档时，word 如何判断某个单词是否拼写正确；
  • 反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱；
  • 缓存穿透，将所有可能存在的数据缓存放到布隆过滤器中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。
  • 热key限流；将热key放入到布隆过滤器中，当查询到的key不在布隆过滤器中，则不限流，否则限流。
• 海量数据去重
  • 网络爬虫程序，怎么让它不去爬相同的 url 页面；
• 案例分析（缓存穿透的解决方案）
  
  • 描述缓存场景，为了减轻数据库（mysql）的访问压力，在 server 端与数据库（mysql）之间加入缓存用来存储热点数据；
  • 描述缓存穿透，server端请求数据时，缓存和数据库都不包含该数据，最终请求压力全部涌向数据库；
  • 数据请求步骤，如图中第二点所示；
  • 发生原因：黑客利用漏洞伪造数据攻击或者内部业务 bug 造成大量重复请求不存在的数据；
  • 解决方案：如图中第三点所示；

5) 实际应用分析

• 在实际应用中，该选择多少个 hash 函数？要分配多少空间的位图？预期存储多少元素？如何控制误差？公式如下：

n – 预期布隆过滤器中元素的个数，如上图 只有str1和str2 两个元素 那么 n=2
p – 假阳率，在0-1之间 0.000000
m – 位图所占空间
k – hash函数的个数
公式如下：
n = ceil(m / (-k / log(1 - exp(log§ / k))))
p = pow(1 - exp(-k / (m / n)), k)
m = ceil((n * log§) / log(1 / pow(2, log(2))));
k = round((m / n) * log(2));

• 确定 n 和 p
  在实际使用布隆过滤器时，首先需要确定 n 和 p，通过上面的运算得出 m 和 k；通常可以在下面这个网站上选出合适的值； https://hur.st/bloomfilter
• 选择 hash 函数
  选择一个 hash 函数，通过给 hash 传递不同的种子偏移值，采用线性探寻的方式构造多个 hash函数；

  #define MIX_UINT64(v) ((uint32_t)((v>>32)^(v)))
  
  uint64_t hash1 = MurmurHash2_x64(key, len, Seed);
  uint64_t hash2 = MurmurHash2_x64(key, len, MIX_UINT64(hash1));
  
  for (i = 0; i < k; i++) // k 是hash函数的个数
  {
    Pos[i] = (hash1 + i*hash2) % m; // m 是位图的⼤⼩
  }
  

3. 分布式一致性Hash

1) 背景

• 在解决分布式系统中负载均衡的问题时候可以使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡的作用。
• 但是普通的余数hash（hash(比如用户id)%服务器机器数）算法伸缩性很差，当新增或者下线服务器机器时候，服务器数量会发生变化，使得用户id与服务器的映射关系会大量失效。
• 一致性hash则利用hash环对其进行了改进，当服务器数量发生变化时，仅一部分用户的映射关系被破坏了，并且其负责处理的请求被顺时针下一个节点委托处理。
  • 分布式一致性 hash 算法将哈希空间组织成一个虚拟的圆环，圆环的大小是 2³²；
  • 算法为： hash(ip) ，最终会得到一个 [0, 2³² - 1] 之间的一个无符号整型，这个整数代表服务器的编号；多个服务器都通过这种方式在 hash 环上映射一个点来标识该服务器的位置；当用户在客户端进行请求时候，首先根据hash(用户id)计算路由规则（hash值），然后看hash值落到了hash环的那个地方，根据hash值在hash环上的位置顺时针找距离最近的ip作为路由ip。
    
  • 一致性hash是对固定值2³²取模。因为IPv4地址是由32位2进制数组成，所以用2^32可以保证每个IP地址会有唯一的映射；

2) 映射关系分析

• 初始状态
  

如上图可知user1, user2的请求会落到服务器ip2进行处理，user3的请求会落到服务器ip3进行处理，user4的请求会落到服务器ip4进行处理，user5, user6的请求会落到服务器ip1进行处理。

• 删除服务器节点
  当ip2的服务器挂了的时候，一致性hash环大致如下图：
  

根据顺时针规则可知user1, user2的请求会被服务器ip3进行处理，而其它用户的请求对应的处理服务器不变，也就是只有之前被ip2处理的一部分用户的映射关系被破坏了，并且其负责处理的请求被顺时针下一个节点委托处理。

• 新增服务器节点
  当新增一个ip5的服务器后，一致性hash环大致如下图：
  

根据顺时针规则可知之前user5的请求应该被ip1服务器处理，现在被新增的ip5服务器处理，其他用户的请求处理服务器不变，也就是新增的服务器顺时针最近的服务器的一部分请求会被新增的服务器所替代。

3) 存在问题

• hash偏移
  hash 算法得到的结果是随机的，不能保证服务器节点均匀分布在哈希环上；分布不均匀造成请求访问不均匀，服务器承受的压力不均匀。如下图，服务器ip1, ip2, ip3经过hash后落到了一致性hash环上，从图中hash值分布可知ip1会负责处理大概80%的请求，而ip2和ip3则只会负责处理大概20%的请求，虽然三个机器都在处理请求，但是明显每个机器的负载不均衡，这样称为一致性hash的倾斜。
  

• 虚拟节点
  当服务器节点比较少的时候会出现一致性hash倾斜的问题，一个解决方法是多加机器，但是加机器是有成本的，那么就加虚拟节点，比如上面三个机器，每个机器引入1个虚拟节点后的一致性hash环，如下图：
  
  其中ip1-1是ip1的虚拟节点，ip2-1是ip2的虚拟节点，ip3-1是ip3的虚拟节点。当客户端计算的hash值处于ip2和ip3或者处于ip2-1和ip3-1之间时候使用ip3服务器进行处理。

• 虚拟节点权重
  我们为每台服务器分配多个虚拟节点，每台服务器对应的虚拟节点的数量（权重）取决于服务器的处理性能。例如，如果某台服务器的处理性能是其他服务器的两倍时，它可以分配其他服务器两倍的虚拟节点。

• 均衡一致性hash
  如果生成虚拟节点的算法不够好很可能会得到下面的环。每个服务节点引入1个虚拟节点后，情况相比没有引入前均衡性有所改善，但是并不均衡。
  
  均衡的一致性hash应该是如下图：
  

• 均匀一致性hash的目标
  均匀一致性hash的目标是如果处理性能一致的服务器有N台，客户端的hash值有M个，那么每个服务器应该处理大概M/N个用户的，也就是每台服务器负载尽量均衡。

4) 应用场景

• 分布式缓存；将数据均衡地分散在不同的服务器当中，用来分摊缓存服务器的压力；解决缓存服务器数量变化尽量不影响缓存失效；
• 解决分布式系统中，服务器的负载均衡，将数据均衡地分散在不同的服务器当中。

5) 思考

• 分布式一致性 hash 增加或者删除节点怎么进行数据迁移？
  参考：https://github.com/metang326/consistent_hashing_cpp