将任意长度的二进制值串映射为固定长度的二进制值串，这个映射的规则就是哈希算法，而通过原始数据映射之后得到的二进制值串就是哈希值。
一个优秀的哈希算法需要满足如下要求：
MD5 的哈希值是 128 位的 Bit 长度 （16进制长度为32位)。
sugoi@sugoi:~$ echo "今天我来讲哈希算法" | md5sum
eb4f874d1ef429470bb2808ae32323dc -
sugoi@sugoi:~$ echo "今天我来讲哈希算法!" | md5sum
a2cbc0646f7ce8ba5bb9d74821d4a6c9 -
sugoi@sugoi:~$ echo "jiajia" | md5sum
4ced003def1157c81e8a1a2832c2f9f7 -安全加密、唯一标识、数据校验、散列函数、负载均衡、数据分片、分布式存储，后三个应用与分布式系统有关。
最常用于加密的哈希算法是 ：
其他加密算法
当哈希算法用于加密时，很难根据哈希值反向推导出原始数据和散列冲突的概率要很小这两点就显得尤为重要。
加密的目的就是防止原始数据泄露，所以很难通过哈希值反向推导原始数据，这是一个最基本的要求。
不管是什么哈希算法，只能尽量减少碰撞冲突的概率，理论上是没办法做到完全不冲突的。为什么哈希算法无法做到零冲突？
抽屉原理：如果有 10 个鸽巢，有 11 只鸽子，那肯定有 1 个鸽巢中的鸽子数量多于 1 个，换句话说就是，肯定有 2 只鸽子在 1 个鸽巢内。
哈希算法产生的哈希值的长度是固定且有限的。如 MD5 的哈希值是固定的 128 位二进制串，能表示的数据是有限的，最多能表示 2^128=340282366920938463463374607431768211456 个数据，而需要哈希的数据是无穷的。
基于抽屉原理，如果对 2^128+1 个数据求哈希值，就必然会存在哈希值相同的情况。所以，一般情况下，哈希值越长的哈希算法，散列冲突的概率越低。
虽然哈希算法存在散列冲突的情况，但是因为哈希值的范围很大，冲突的概率极低，所以相对来说还是很难破解的。像 MD5，有2^128个不同的哈希值，这个数据已经是一个天文数字了，所以散列冲突的概率要小于1/2^128。
如果拿到一个 MD5 哈希值，希望通过毫无规律的穷举的方法，找到跟这个 MD5 值相同的另一个数据，那耗费的时间应该是个天文数字。所以，即便哈希算法存在冲突，但是在有限的时间和资源下，哈希算法还是被很难破解的。
没有绝对安全的加密。越复杂、越难破解的加密算法，需要的计算时间也越长。比如 SHA-256 比 SHA-1 要更复杂、更安全，相应的计算时间就会比较长。在实际的开发过程中，需要权衡破解难度和计算时间，来决定使用哪种加密算法。
如果要在海量的图库中，搜索一张图是否存在，不能单纯地用图片的元信息（比如图片名称）来比对，因为可能存在名称相同但图片内容不同，或者名称不同图片内容相同的情况。
任何文件在计算中都可以表示成二进制码串，所以，可以拿要查找的图片的二进制码串与图库中所有图片的二进制码串一一比对。但是，每个图片小则几十KB、大则几MB，转化成二进制是一个非常长的串，比对起来非常耗时。
可以给每一个图片取一个唯一标识（或信息摘要）。比如：
通过这个唯一标识来判定图片是否在图库中，这样就可以减少很多工作量。
继续提高效率：
BT 下载的原理是基于 P2P 协议的。
从多个机器上并行下载一个 2GB 的电影，这个电影文件可能会被分割成很多文件块（比如可以分成 100 块，每块大约 20MB）。等所有的文件块都下载完成之后，再组装成一个完整的电影文件。
网络传输是不安全的，下载的文件块有可能是被宿主机器恶意修改过的，又或者下载过程中出现了错误，导致下载的文件块可能不是完整的。如果没有能力检测这种恶意修改或者文件下载出错，就会导致最终合并后的电影无法观看，甚至导致电脑中毒。
BT 协议很复杂，校验方法也有很多，可以通过哈希算法，对 100 个文件块分别取哈希值，并且保存在种子文件中。
哈希算法有一个特点，对数据很敏感。只要文件块的内容有一丁点儿的改变，最后计算出的哈希值就会完全不同。所以，当文件块下载完成之后，可以通过相同的哈希算法，对下载好的文件块逐一求哈希值，然后跟种子文件中保存的哈希值比对。如果不同，说明这个文件块不完整或者被篡改了，需要再重新从其他宿主机器上下载这个文件块。
散列函数也是哈希算法的一种应用。
相对哈希算法的其他应用，散列函数对于散列算法冲突的要求要低很多。即便出现个别散列冲突，只要不是过于严重，都可以通过开放寻址法或者链表法解决。
散列函数对于散列算法计算得到的值，是否能反向解密也并不关心。散列函数中用到的散列算法，更加关注散列后的值是否能平均分布，也就是，一组数据是否能均匀地散列在各个槽中。
散列函数执行的快慢，也会影响散列表的性能，所以，散列函数用的散列算法一般都比较简单，比较追求效率。
负载均衡算法有很多，比如轮询、随机、加权轮询等。
实现一个会话粘滞（session sticky）的负载均衡算法，也就是说，同一个客户端上，在一次会话中的所有请求都路由到同一个服务器上。
最直接的方法就是，维护一张映射关系表，这张表的内容是客户端 IP 地址或者会话 ID 与服务器编号的映射关系。客户端发出的每次请求，都要先在映射表中查找应该路由到的服务器编号，然后再请求编号对应的服务器。
这种方法简单直观，但也有几个弊端：
如果借助哈希算法，可以非常完美地解决。通过哈希算法，对客户端 IP 地址或者会话 ID 计算哈希值，将取得的哈希值与服务器列表的大小进行取模运算，最终得到的值就是应该被路由到的服务器编号。这样，就可以把同一个 IP 过来的所有请求，都路由到同一个后端服务器上。
哈希算法用于数据的分片。
在1T的日志文件中，记录用户搜索关键词，如何快速统计每个关键词被搜索的次数？
难点：
解决方案：
具体思路：
实际上，这里的处理过程也是 MapReduce 的基本设计思想。
在唯一标识的应用中，给每个图片取唯一标识（或者信息摘要），然后构建散列表，来判断图片是否存在。
当图片数量巨大如上亿张图片时，在单台服务器上构建散列表是行不通的。因为单台机器的内存有限，而上亿张图片构建散列表显然远远超过了单台机器的内存上限。
同样对数据进行分片，然后采用多机处理。
k，那就去编号 k 的机器构建的散列表中查找。假设图片数量是1亿张，散列表中每个数据单元包含哈希值和图片文件的路径。使用MD5算法生成的哈希值是128位（16字节），文件路径长度的上限是256字节（假设平均长度128字节）。使用链表法来解决冲突，每个指针占用8个字节，所以散列表一个数据单元大概152字节。
假设一台机器内存2GB，散列表装填因子0.75，那么一台机器可以给大约1000万（2GB×0.75./152B）图片构建索引。所以大概需要十几台机器。
借助数据分片的思路，可以突破单机内存、CPU等资源资源限制。
面对海量数据和用户，为了提高数据的读写能力，一般都采用分布式的方式来存储数据，比如分布式缓存。对于海量数据的缓存，需要将缓存分布在多台机器上。
同样借助数据分片的思想，通过哈希算法对数据取哈希值，然后对机器个数取模，这个最终值就是应该存储的缓存机器编号。
但是随着数据的增多就需要扩容，这里的扩容并不是简单的增加机器，就像散列表的扩容一样，会涉及到数据缓存位置的重新计算，然后数据迁移到新的机器上。这样就相当于，缓存数据一下子全部失效了。所有的数据请求都会穿透缓存，直接去请求数据库，发生雪崩效应，压垮数据库。
需要一种方法，使得在新加入一个机器后，并不需要做大量的数据搬移，这就是一致性哈希算法。
假设有
k个机器，数据的哈希值的范围是[0, MAX]。将整个范围划分成m个小区间（m远大于k），每个机器负责m/k个小区间。当有新机器加入的时候，将某几个小区间的数据，从原来的机器中搬移到新的机器中。这样，既不用全部重新哈希、搬移数据，也保持了各个机器上数据数量的均衡。
除了分布式缓存，实际上，一致性哈希算法的应用非常广泛，在很多分布式存储系统中，都可以见到一致性哈希算法的影子。
通过哈希算法，对用户密码进行加密之后再存储，选择相对安全的加密算法，比如 SHA 等（因为 MD5 已经号称被破解了）。
字典攻击：维护一个常用密码的字典表，把字典中的每个密码用哈希算法计算哈希值，然后拿哈希值跟脱库后的密文比对。如果相同，基本上就可以认为，这个加密之后的密码对应的明文就是字典中的这个密码。
针对字典攻击，可以引入一个盐（salt），跟用户的密码组合在一起，增加密码的复杂度，将组合之后的字符串做哈希算法加密，将它存储到数据库中，进一步增加破解的难度。
安全和攻击是一种博弈关系，不存在绝对的安全。所有的安全措施，只是增加攻击的成本而已。