哈希算法

Redis使用字典的方式实现了数据库键空间，今天就记录一下字典的实现方式。 Redis 对字典的描述和实现源码在 src/dict.h src/dict.c，关于学习Redis字典如何进行测试或debug，请参考另外一篇文章： Redis 2.8.9源码 - 字典哈希表操作函数头整理，并注释作用和参数说明（附测试方法和代码以及使用方法） 字典结构： typedef struct dict { dictType *type; //根据存储内容的不同，自定义一组回调函数来控制比较申请内存释放空间等操作 void *privdata; //用于回调函数使用 dictht ht[2]; //存放hash表的结构 0 默认使用0，rehash的时候使用1 int rehashidx; //默认为-1，rehash开始的时候该变量设置为0，完成后重新设置为-1 int iterators; //正在进行的安全迭代的数量，释放安全迭代后会减1 } dict; typedef struct dictType { unsigned int (*hashFunction)(const void *key); //针对不同类型进行hash计算的函数，返回hash值 void *(*keyDup)(void *privdata, const void *key); //复制key void *(

大纲 Hash取余算法 判定哈希算法好坏的四个定义 一致性Hash算法的两大设计 Hash取余算法 hash( Object.key) %N，hash值随Object.key、N的变化而变化。 如果有节点（集群中节点增减太正常）发生变化，几乎重新分配，意味着所有已经分配好的数据都要迁移到新的节点上。 一致性Hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义 ： 1、平衡性（Balance）：平衡性是指哈希的结果能够尽可能分布在所有的缓冲(Cache)中去，这样可以使得所有的缓冲空间得到利用。很多哈希算法都能够满足这一条件。 2、单调性（Monotonicity）：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应该能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会映射到旧的缓冲集合中的其他缓冲区。 3、分散性（Spread）：在分布式环境中，终端有可能看不到所有的缓冲，而只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上去，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度

一致性Hash算法背景 　　一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。 　　但现在一致性hash算法在分布式系统中也得到了广泛应用，研究过memcached缓存数据库的人都知道，memcached服务器端本身不提供分布式cache的一致性，而是由客户端来提供，具体在计算一致性hash时采用如下步骤： 首先求出memcached服务器（节点）的哈希值，并将其配置到0～2 32 的圆（continuum）上。 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2 32 仍然找不到服务器，就会保存到第一台memcached服务器上。 　　从上图的状态中添加一台memcached服务器。余数分布式算法由于保存键的服务器会发生巨大变化而影响缓存的命中率，但Consistent Hashing中，只有在园（continuum）上增加服务器的地点逆时针方向的第一台服务器上的键会受到影响，如下图所示： 一致性Hash性质 　　考虑到分布式系统每个节点都有可能失效

上一节，我讲了哈希算法的四个应⽤，它们分别是：安全加密、数据校验、唯⼀标识、散列函数。今天，我们再来看剩余三种应用： 负载均衡、 数据分片、 分布式存储 你可能已经发现，这三个应用都跟分布式系统有关。没错，今天我就带你看下， 哈希算法是如何解决这些分布式问题的。 应用五：负载均衡 1、如何实现一个会话粘滞的负载均衡算法 2、维护映射关系表的弊端 3、借助哈希算法完美解决 应用六：数据分片 1、引子案列 2、难点处理方案 3、问题所在痛点 4、如何快读判断图片是否在图库中 1、对数据进行分片、然后采用多机处理 2、具体方法 3、需要多少台机器 1、散列表中的每个数据单元包含两个信息 2、使用MD5 3、一台机器可以存多少图片 4、如果对一亿张图片构建索引，需要大约十几台机器 5、实际上 应用七：唯一标识 1、分布式存储 2、扩容带来的问题及痛点 1、方法 2、扩容存在的问题 3、雪崩效应、压垮数据库 3、将那个数据放到那个机器上呢 1、所以我们需要一种方法 2、解决方案 3、一致性哈希算法 解答开篇 & 内容小结 1、解答开篇 2、内容小结 来源： https://www.cnblogs.com/luoahong/p/11330458.html

Nginx 第三方模块的安装以及一致性哈希算法的使用 第三方模块安装方法总结： 以ngx_http_php_memcache_standard_balancer-master为例 1:解压 到 path/ngx_module 配置:add_module=后面写的就是被解压之后的模块的位置 ./configure --prefix=/xxx/xxx --add_module=/path/ngx_module 编译 安装 Make && make instal 需要一致性哈希算法，来统一nginx和php的mc算法，使得二者的算法同步 wget 一致性哈希算法的zip 解压 通过-V来查看一下nginx编译时候的选项（这一步只是看到了这个命令，所以记录下来，不是必要的） 重新编译nginx 因为之前编译过，可以先make clean一下 编译之前最好先把nginx进程杀死 在nginx中做集群与负载均衡,步骤都是一样的 Upstream {}模块 把多台服务器加入到一个组 然后 memcached_pass, fastcgi_pass, proxy_pass ==> upstream组 默认的负载均衡的算法: 是设置计数器,轮流请求N台服务器. 可以安装第3方模式,来利用uri做hash等等. 如http://wiki.nginx.org

3 月，跳不动了？>>> 1.什么是短链接 就是把普通网址，转换成比较短的网址。比如： http://t.cn/RlB2PdD 这种，在微博这些限制字数的应用里。好处不言而喻。短、字符少、美观、便于发布、传播。 2.交互流程 a)用户访问短链接： http://t.cn/RtFFvic b)短链接服务器t.cn收到请求，根据URL路径RtFFvic获取到原始的长链接： http://blog.csdn.net/poem_qianmo/article/details/52344732 c)服务器返回302状态码，将响应头中的Location设置为： http://blog.csdn.net/poem_qianmo/article/details/52344732 d)浏览器重新向http://blog.csdn.net/poem_qianmo/article/details/52344732发送请求 e)返回响应 说明：301 是永久重定向，302 是临时重定向。短地址一经生成就不会变化，所以用 301 是符合 http 语义的。同时对服务器压力也会有一定减少。 但是如果使用了 301，我们就无法统计到短地址被点击的次数了。而这个点击次数是一个非常有意思的大数据分析数据源。能够分析出的东西非常非常多。所以选择302虽然会增加服务器压力，但是我想是一个更好的选择。 3. 算法实现 a

一、负载均衡 1.1.需求 如何实现一个会话粘滞（session sticky）的负载均衡算法？也就是说，在一次会话中的所有请求都路由到同一个服务器上。 1.2.解决方案 通过哈希算法对客户端IP或会话ID计算哈希值，将取得的哈希值与服务器列表的大小进行取模运算，最终得到的值就是应该被路由到的服务器编号。这样，就可以把同一个IP过来的请求都路由到同一个后端服务器上。 二、数据分片 2.1.如何统计“搜索关键词”出现的次数？ ①需求描述 假如我们有1T的日志文件，这里面记录了用户的搜索关键词，我们想要快速统计出每个关键词被搜索的次数，该怎么做呢？ ②问题分析 这个问题有两个难点，第一个是搜索的日子很大，没办法放到一台机器的内存中。第二个是只用一台机器来处理这么巨大的数据，处理时间会很长。 ③解决方案 先对数据进行分片，然后采用多台（比如n台）机器进行处理。具体做法：从搜索记录的日志文件中依次读取每个关键词，并通过哈希函数计算该关键词的哈希值，然后跟机器的台数n取模，最终得到值就是该关键词应该被分到的机器编号，这样相同的关键词一定会被分配到同一台机器上，数据分配完成后，由多台机器并行进行统计，最后合并起来就是最终结果。 实际上，这里的处理过程也是 MapReduce 的基本设计思想。 2.2.如何快速判断图片是否存在图库中？ ①需求描述 假设现在我们的图库中有1亿张图片

哈希索引：通过对键值进行一定的哈希算法得到新的哈希值，检索时不需要像btree那样从根节点到叶子节点逐级查找，而是通过哈希算法就可以快速定位到位置 btree和哈希结构的比较： 1、哈希结构的索引适合等值查询，前提是值唯一，因为会出现哈希碰撞的情况，就会导致找到具体的位置后，还得扫描链表 2、哈希结构不适合范围查找，原本有序的磁盘数据经过键值的哈希算法后可能试键值出现不连续，导致不能范围查找 3、哈希机构不适合排序、模糊查询、分组查询，因为这些本质上是范围查询 4、哈希结构不能遵循复合索引的最左原则 B-tree索引：是一个多路平衡搜索树，和二叉树的区别是二叉树每个节点只允许有两个子节点，而btree可以有多个节点 其特点是： 1、所有键值分布在整棵树中 2、任何一个关键字出现且只出现在一个节点中 3、一次查询可能未到叶子节点就可以查询结束，因为真实数据也存储在非叶子节点；性能逼近二分查找 B+tree也是一种多路平衡搜索树，它和B-tree的区别是： 1、B+tree存储的真实数据只在叶子节点 2、为所有叶子节点增加了一个链指针 为什么使用B+tree 1、B+树更适合外部存储,由于内节点无 data 域,一个结点可以存储更多的内结点,每个节点能索引的范围更大,也意味着 B+树单次磁盘IO的信息量大于B-树,I/O效率更高。 2、Mysql是一种关系型数据库

2018年开始听说区块链，从中本聪到智能合约；从加密货币到区块链；从比特币到钱包 ……今天我们再学点新知识。 1、哈希算法是什么？ 哈希算法又叫散列算法，是将任意长度的二进制值映射为较短的固定长度的二进制值，这个小的二进制值称为哈希值。它的原理其实很简单，就是把一段交易信息转换成一个固定长度的字符串。 这串字符串具有一些特点： 1. 信息相同，字符串也相同。 2. 信息相似不会影响字符串相同。 3. 可以生成无数的信息，但是字符串的种类是一定的，所以是不可逆的。 让我们举个例子理解一下：如果我们要搜一张图片，在没有人工标注的情况下，于巨大的图库中想要以图搜图是一件及其庞大而又困难的工作量。 来源： CSDN 作者： li.junmin 链接： https://blog.csdn.net/Doudou_Mylove/article/details/104398277

分布式系统与高并发高可用 浅析分布式系统中的一致性哈希算法 通过本文将了解到以下内容： 分布式系统的简单概念和基本作用 分布式系统常用负载均衡策略 普通哈希取模策略优缺点 一致性哈希算法的定义和思想 一致性哈希的基本过程 Redis集群中一致性哈希的实现 1.分布式系统的基本概念 分布式系统与高并发高可用 当今高并发和海量数据处理等场景越来越多，实现服务应用的高可用、易扩展、短延时等成为必然。 在此情况下分布式系统应运而生，互联网的场景无外乎存储和计算，因此分布式系统可以简单地分为： 分布式存储 分布式计算 所谓分布式系统就是一批计算机组合起来共同对外提供服务，对于用户来说具体有多少规模的计算机完成了这次请求，完全是无感知的。分布式系统中的计算机越多，意味着计算和存储资源等也就越多，能够处理的并发访问量也就越大，响应速度也越快。 如图为简单整体架构图： 大前端 主要实现了服务应用对应的所有流量的接入，比如xyz域名下可能有N个子服务，这一层涉及很多网络流量的处理，也很有挑战，像百度的BFE(百度统一前端)接入了百度的大部分流量，每日转发1万亿次，峰值QPS1000w。 中间层 完成了各个服务的调度和分发，粒度相比大前端接入层更细致一些，这一层实现了用户的无感知体验，可以简单理解为反向代理层。 业务层 完成了数据存储、数据计算、数据缓存等，各个业务环节高度解耦，并且基于集群化来实现。