第二十二节-哈希算法（下）

这节讲的主要是哈希算法在分布式系统中的应用

应用五：负载均衡

负载均衡的算法很多，有轮询、随机、加权轮询等。但要实现一个会话粘滞（session sticky）的负载均衡算法就可以使用哈希算法。

如果不适用哈希算法，可以维持一张映射关系表，key 是客户端 IP，value 是服务器编号。实现不难，但弊端是：

• 如果客户端多，那么映射表很大，浪费内存和计算资源
• 客户端上线、下线，服务器扩容、缩容都会导致映射失效，这样维护映射关系的成本很大。

使用哈希的话，只要设计一个哈希函数，对客户端地址取散列值再按服务器资源数取模即可构成最简单的可用哈希函数。

应用六：数据切片

1. 如何统“搜索关键词”出现的次数？

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

难点有两个：1、日志文件大，没法放到一台服务器的内存中。 2、 如果只用一条服务器来处理这么大量的数据，处理时间很长。

处理方法：1、对数据进行分片。 2、采用多台机器并行处理。

我们先从日志文件中，依次读取每条搜索关键词记录，通过哈希函数计算哈希值，再对分片数取模，最终得到的值就是数据应该放入哪个数据片的编号。然后采用多台机器并行处理这些数据片，把结果整合到一起，就是我们最终要的结果了。

实际上，这也是 MapReduce 的基本设计思想。

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

上一节我们讲过这个例子，解决方法是给图片取哈希值构建散列表。

假设现在有一亿张图片，显然在单机上构建哈希表就不够了。因为单机内存有限，一亿张图片构建出来的哈希表显然远远超出一台普通机器的内存上限。

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

当我们要判断一个图片是否在图库中的时候，我们通过同样的哈希算法，计算标识，求余取模，在对应的机器查找。

现在估算一下给 1 亿张图片构建分布式哈希表需要大约多少台机器。

散列表中每个数据单元包含两个信息，哈希值和图片文件的路径。假设采用 MD5 计算哈希值，那长度就是 128 比特，即 16 字节。文件路径长度上限是 256 字节，我们取中间值 128 字节计算。再假设采用链表法解决哈希冲突，每个数据单元加一个 8 字节的指针。总计算下来，每个数据单元占用 152 字节。

假设一台机器的内存是 2 GB，散列表的装在因子为 0.75，那一台机器大约可以给 1000万 （2GB * 0.75 / 152 Byte）张图片构建散列表。所以，如果要对 1 亿张图片构建索引，大约需要十几台机器。

借助这种分布式处理，分片思路，可以解决海量数据处理的单机内存、CPU 问题。

应用七：分布式存储

当面对海量的数据、用户时，为了提高数据的读取、写入能力，一般可以采用分布式的方式来存储数据，比如分布式缓存。

思路仍然是构建一个哈希算法，将不同的数据缓存到不同的机器上。但是，考虑到数据是不断增加的，假设有一天需要进行服务器扩容，那么服务器数量增加，原来的哈希算法计算出来的哈希值就都失效了，需要重新计算正确的缓存服务器来读取、写入数据。这时，所有的请求都会穿透缓存，直达数据库，很容易发生雪崩效应，压垮服务器。

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

一致性哈希的介绍可以查看 https://zh.wikipedia.org/wiki/%E4%B8%80%E8%87%B4%E5%93%88%E5%B8%8C
或者
https://www.sohu.com/a/158141377_479559
进行直白的了解。