一致性哈希

分布式服务器布置需要使用到hash算法， 设节点有N个, 普通的哈希算法：key%N，在遇到节点增加和减少的情况下， 对于单纯的逻辑计算hash是没有问题的，但如果节点集群提供存储功能，那效果就不理想了。这时候我们的想法是在增加节点时以前的节点不受影响，在减少节点时只有与减少节点相关的受影响。那么我们不能单纯的使用%的方式，有个解决方案是将对象key和服务器节点key抽象出来，间隔排布在一个圆环上面，安装顺时针的方式对象key取的最近的服务器节点。这个方法就是ConsistentHash，下面贴出算法的Java版本： import java.util.Collection; import java.util.SortedMap; import java.util.TreeMap; public class ConsistentHash<T> { private final HashFunction hashFunction;// hash算法 private final int numberOfReplicas;// 虚拟节点数目 private final SortedMap<Integer, T> circle = new TreeMap<Integer, T>(); public ConsistentHash(HashFunction hashFunction, int

一致性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性质 　　考虑到分布式系统每个节点都有可能失效

ngx_http_upstream_consistent_hash 模块是一个负载均衡器，使用一个内部一致性hash算法来选择合适的后端节点。与 PHP 的 memcache 模块memcache.hash_strategy兼容，这意味着可以使用php-memcache模块将内容存储到memcached集群中，而后通过 nginx 在集群中找到值。 该模块通过使用客户端信息(如：$ip, $uri, $args等变量)作为参数，使用一致性hash算法将客户端映射到后端节点。 该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器，比如： consistent_hash $remote_addr：可以根据客户端ip映射 consistent_hash $request_uri： 根据客户端请求的uri映射 consistent_hash $args：根据客户端携带的参数进行映射 指令 语法：consistent_hash variable_name 默认值：none 上下文：upstream 配置upstream采用一致性hash作为负载均衡算法，并使用配置的变量名作为hash输入。 2 3 4 5 # cd /tmp # wget https://github.com/replay/ngx_http_consistent_hash/archive/master.zip #

一致性哈希是指分布式系统做负载均衡策略时的一种算法。 前言：本身负载均衡策略有一种模式是通过hash算法，将一些固定请求映射到固定某台服务器上。这样有个弊端就是，如果某台服务器挂了，或者新增机器的时候，这种用户id与服务器的hash关系就会大量失效。 一致性哈希的出现主要是为了解决此场景。 原理：1.将所有服务器的ip地址首先计算出来，从0-最大正整数之间形成一个闭环。 　　　2.用户请求时，将用户的ip hash值计算出来后，看离着闭环上的哪台服务器的节点最近，就由那台服务器去处理请求。 　　　3.特性：单调性、分散性、平衡性。 扩展：1. 虚拟节点，为了降低分散性，节约成本（加机器成本太高）。 　　　2. 均匀一致性哈希： 使每台服务器尽量负载均衡。 以上只为小叙，详情参考大佬文章： https://www.jianshu.com/p/e968c081f563 　 来源： https://www.cnblogs.com/camouflage/p/12358677.html

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

一致性哈希实现负载均衡 1 为什么需要哈希算法 解决同一个用户访问服务器是，访问的是不同的服务器的问题 场景：集群造成的session没有同步 当一个用户访问服务器A的时候，该台服务器A会保存这台服务器的session，但是当下次再访问的时候，被负载均衡算法可能算到了不同的服务器B，服务器B中没有用户的session，会要求用户再次登录。 解决： 加入redis，将session存到redis中 Tomcat同步session 一致性哈希算法 2 什么是一致性哈希算法 服务器集群接收到一次请求调用时，可以根据请求的信息，比如客户端的ip地址，或请求路径与请求参数等信息进行哈希，可以得出一个哈希值，特点是对于相同的ip地址，或请求路径和请求参数哈希出来的值是一样的，只要能再增加一个算法，能够把这个哈希值映射成一个服务端ip地址，就可以使用相同的请求（相同的ip地址，或请求路径和请求参数）落到同一服务器上。 因为客户端发起的请求是无穷无尽的（客户端地址不同，请求参数不同等等），所以对于的哈希值也是无穷大的，所以我们不能把所有的哈希值都进行映射到服务端ip上，所有这里需要用到 哈希环 。 3 虚拟节点 解决一个服务器挂掉造成的服务不均匀问题 使得哈希环更加平滑 当时当一台服务器挂掉的话，会造成服务器服务不均匀的情况 会发现，ip3和ip1直接的范围是比较大的，会有更多的请求落到ip1上

定义 一致性哈希是当机器数量增加或者减少的时候，最大限度的减少重新映射的数量。 实现 hash环 我们可以预先定义0-n个bucket，n通常取值2^32-1。为方便我们取值1000 对于实际存在的机器数量，假设是3个，我们根据机器的信息，随意hash到某一些bucket，注意不可以指定，分配过程是不可以有状态的，要不然重启就完犊子了，比如对ip做hash。假设分配到的bucket是100， 100， 500，那么对于<=10 || > 500，就访问机器1，>10 && <= 100就访问机器2，>100 && <= 500就访问机器3.这就是构成了一个环。 对于增加机器的情况：假设增加的机器在bucket 200处，那么机器2的部分数据会落到bucket 200，机器1 和机器3不受影响 对于宕机的情况，假设机器2挂了。那么机器2的数据会落到机器3上，机器1不受影响 数据倾斜&虚拟节点 假设机器1，2，3的ip hash到的节点非常临近，那么大部分数据就会落到机器1，这不是一个good idea，于是我们可以引入虚拟节点。 一个机器ip不再只生成一个节点，可以通过ip#1, ip#2…ip#32生成32个虚拟节点，这样落到这32个节点的数据都会访问这台机器，不可能这么多节点都是临近的。完美解决！只是每次增减机器的时候要同时变动多个节点而已。 来源： CSDN 作者：

目录 1、数据分布 2、哈希方式 3、一致性哈希方式 笔记来自分布式原理一书，供个人学习。 数据分布 单机系统与分布式系统的最大的区别在于问题的规模，即计算、存储的数据量的区别。将一个单机问题使用分布式解决，首先要解决的就是如何将问题拆解为可以使用多机分布式解决，使得 分布式系统中的每台机器负责原问题的一个子集。由于无论是计算还是存储，其问题输入对象都是数据，所以如何拆解分布式系统的输入数据成为分布式系统的基本问题，我们称这样的数据拆解为数据分布方式。 哈希方式 哈希方式是最常见的数据分布方式，其方法是按照数据的某一特征计算哈希值，并将哈希值与机器中的机器建立映射关系，从而将不同哈希值的数据分布到不同的机器上。所谓数据特征可以是 key-value 系统中的 key，也可以是其他与应用业务逻辑相关的值。例如，一种常见的哈希方式是按数据属于的用户 id 计算哈希值，集群中的服务器按0到机器数减 1 编号，哈希值除以服务器的个数，结果的余数作为处理该数据的服务器编号。工程中，往往需要考虑服务器的副本冗余，将每数台（例如 3）服务器组成一组，用哈希值除以总的组数，其余数为服务器组的编号。图 2-1 给出了哈希方式分数据的一个例子，将数据按哈希值分配到 4 个节点上。 哈希方式特点 ： 1.每个节点只计算一部分数据；每个节点只存储一部分数据。 我们假设节点的数量没有变化（实际上不可能）

Redis Cluster 集群中涉及到了数据分布问题，因为 redis cluster 是多 master 的结构，每个 master 都是可以提供存储服务的，这就会涉及到数据分布的问题，在新的 redis 版本中采用的是虚拟槽分区技术来解决数据分布的问题，关于什么是虚拟槽分区技术我们后面会详细的介绍。在集群中除了虚拟槽分区技术之外，还有几种数据分布的算法，比如哈希算法，一致性哈希算法，这篇文章我们就来一起聊一聊这几种数据分布算法。 因为是集群，所以我们需要一个大前提，在这篇文章中假设 redis cluster 集群中有三台 master，我们需要存储的数据集为： [{id:1,"name":"1"},{id:2,name:"2"},{id:3,name:"3"},{id:4,name:"4"},{id:5:"name":"5"},{id:6,"name":"6"}] ，在这个大前提下，我们来聊一聊集群中的数据分布算法。 哈希算法 哈希算法在分布式架构中应用广泛，不仅仅是数据存储，还有负载均衡等应用上有用的比较多，哈希算法的思想非常简单，也许你知道 HashMap 的哈希函数，哈希算法跟 HashMap 一样，也是通过一个哈希函数得到某一个数字，然后根据数字找到相应的服务器。哈希算法的哈希函数比较简单，一般是根据某个key的值或者key 的哈希值与当前可用的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> #摘要 本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用。首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题。 #分布式缓存问题 假设我们有一个网站，最近发现随着流量增加，服务器压力越来越大，之前直接读写数据库的方式不太给力了，于是我们想引入Memcached作为缓存机制。现在我们一共有三台机器可以作为Memcached服务器，如下图所示。 很显然，最简单的策略是将每一次Memcached请求随机发送到一台Memcached服务器，但是这种策略可能会带来两个问题：一是同一份数据可能被存在不同的机器上而造成数据冗余，二是有可能某数据已经被缓存但是访问却没有命中，因为无法保证对相同key的所有访问都被发送到相同的服务器。因此，随机策略无论是时间效率还是空间效率都非常不好。 要解决上述问题只需做到如下一点：保证对相同key的访问会被发送到相同的服务器。很多方法可以实现这一点，最常用的方法是计算哈希。例如对于每次访问，可以按如下算法计算其哈希值： h = Hash(key) % 3