一致性哈希

1 概述 1.1 传统哈希(硬哈希) 分布式系统中，假设有 n 个节点，传统方案使用 mod(key, n) 映射数据和节点。 当扩容或缩容时(哪怕只是增减1个节点)，映射关系变为 mod(key, n+1) / mod(key, n-1)，绝大多数数据的映射关系都会失效。 1.2 一致性哈希(Consistent Hashing) 1997年，麻省理工学院(MIT)的 David Karger 等6个人发布学术论文《Consistent hashing and random trees: distributed caching protocols for relieving hot spots on the World Wide Web（一致性哈希和随机树：用于缓解万维网上热点的分布式缓存协议）》，对于 K 个关键字和 n 个槽位(分布式系统中的节点)的哈希表，增减槽位后，平均只需对 K/n 个关键字重新映射。 1.3 哈希指标 评估一个哈希算法的优劣，有如下指标，而一致性哈希全部满足： 均衡性(Balance)：将关键字的哈希地址均匀地分布在地址空间中，使地址空间得到充分利用，这是设计哈希的一个基本特性。 单调性(Monotonicity): 单调性是指当地址空间增大时，通过哈希函数所得到的关键字的哈希地址也能映射的新的地址空间，而不是仅限于原先的地址空间。或等地址空间减少时

分布式基础知识 https://www.cnblogs.com/zhang-qc/p/8687663.html 参考 https://github.com/CyC2018/Interview-Notebook/blob/master/notes/ 基本概念 （1）异常： 1. 服务器宕机 　　内存错误、服务器停电等都会导致服务器宕机，此时节点无法正常工作，称为不可用。 　　服务器宕机会导致节点失去所有内存信息，因此需要将内存信息保存到持久化介质上。 2. 网络异常 　　有一种特殊的网络异常称为 网络分区 ，即集群的所有节点被划分为多个区域，每个区域内部可以通信，但是区域之间无法通信。 3. 磁盘故障 　　磁盘故障是一种发生概率很高的异常。 　　使用冗余机制，将数据存储到多台服务器。 （2）超时： 　　可以将服务器的操作设计为具有 幂等性 ，即执行多次的结果与执行一次的结果相同。如果使用这种方式，当出现超时的时候，可以不断地重新请求直到成功。 （3）衡量指标 1. 性能 　　常见的性能指标有：吞吐量、响应时间。这两个指标往往是矛盾的，追求高吞吐的系统，往往很难做到低响应时间。 　　高吞吐意味并发系统，高并发提高 CPU 资源的利用率，但是请求不能马上被处理，需要和其它请求一起进行并发处理，响应时间增高。 2. 可用性：指系统在面对各种异常时可以提供正常服务的能力 3. 一致性

一致性哈希背景和原理 点这里 源码实现 package consistent // import "stathat.com/c/consistent" import ( "errors" "hash/crc32" "sort" "strconv" "sync" ) type uints [] uint32 // Len returns the length of the uints array. func (x uints) Len() int { return len (x) } // Less returns true if element i is less than element j. func (x uints) Less(i, j int ) bool { return x[i] < x[j] } // Swap exchanges elements i and j. func (x uints) Swap(i, j int ) { x[i], x[j] = x[j], x[i] } // ErrEmptyCircle is the error returned when trying to get an element when nothing has been added to hash. var ErrEmptyCircle = errors.New(

一、算法背景 一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。 二、应用场景 现在一致性hash算法在分布式系统中也得到了广泛应用，分布式系统中涉及到集群部署，包括缓存Redis集群，数据库集群，我们在使用Redis的时候，为了保证Redis的高可用，提高Redis的读写性能，最简单的方式我们会做主从复制，组成Master-Master或者Master-Slave的形式，或者搭建Redis集群，进行数据的读写分离，类似于数据库的主从复制和读写分离。如下所示： 同样数据库中也是，当单表数据大于500W的时候需要对其进行分库分表，当数据量很大的时候（标准可能不一样，要看Redis服务器容量）我们同样可以对Redis进行类似的操作，就是分库分表。 假设，我们有一个社交网站，需要使用Redis存储图片资源，存储的格式为键值对，key值为图片名称，value为该图片所在文件服务器的路径，我们需要根据文件名查找该文件所在文件服务器上的路径，数据量大概有2000W左右，按照我们约定的规则进行分库，规则就是随机分配，我们可以部署8台缓存服务器，每台服务器大概含有500W条数据

目录 概念 一致性证明和审计证明 默克一致性证明 默克审计证明 使用证明 译： How Log Proofs Work 概念 证书透明日志使用特殊的加密算法有助于证书和日志的公共审查。这个特殊的加密算法称作 默克哈希树（Merkle hash tree） ，一种包含哈希叶和结点的简单二叉树（图1）。叶子是已附加到日志中的单个证书的哈希。节点是成对的子叶或成对的子节点的哈希。所有叶子和结点的根，即根哈希称作 默克树哈希（Merkle tree hash） 。当日志服务器对默克树哈希（及其他信息）签名，称为 签名树头（STH:signed tree head ） 。 定期地，可能一小时一次，日志服务器将新获取到的证书追加到日志中。通过新获取到的证书创建单独的默克树哈希，该哈希和之前已在哈希树中的旧默克树哈希结合成新的默克树哈希（图2）。对新的默克树哈希签名创建新签名树头。反反复复的持续，之前提交到日志中的所有证书形成了一个不断增长的默克树。 一致性证明和审计证明 因为这种构造方式，默克哈希树让日志高效迅速的证明两件事： 所有证书被一致性地附加到日志中 特定的证书附加到日志中 日志通过提供两个加密证明来支持：默克一致性证明和默克审计证明。 默克一致性证明 默克一致性证明验证一条日志的任意两个版本是一致的：即，新版本包含旧版本的一切，换句话说，所有新条目紧跟在上个版本的条目后

整个网站应用中，缓存几乎无处不在，既存在于浏览器、也存在于应用服务器和数据库服务器；既可以对数据缓存（分布式缓存），也可以对文件缓存（分布式存储系统），还可以对页面片段缓存（ESI）。 一、合理使用缓存 1.频繁修改的数据 缓存主要存放读写比很高、很少变化的数据。一般说来，数据的读写比在2:1以上，如商品类目信息、热门搜索列表信息等。 2.没有热点的数据 如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据并没有集中在小部分数据上，那么缓存就没有意义。 3.数据不一致与脏读 一般会对还存的数据设置失效时间，一旦超过失效时间，就会从数据库重新加载，因此应用要容忍一定时间的数据不一致。 4.缓存可用性 为了应对当缓存服务崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用（缓存雪崩故障），可以通过 缓存热备 或者 分布式缓存服务器集群 来改善缓存的可用性。 5.缓存预热 可以在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫作缓存预热。常用于元数据如城市地名列表、类目信息等。 6.缓存穿透 如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有请求都会落到数据库上，会对数据库造成很大压力，甚至崩溃。 一个简单的对策就是将不存在的数据也缓存起来（value为null）。 二、Memcached高效的内存管理

转载自： https://blog.csdn.net/losetowin/article/details/53743135 适当做了一些修改,最后加了自己的一些理解 1、项目场景 (1) 单个节点的缓存容量达到上限，无法继续单点增加内存，如何解决？ (2) 单个节点 支撑的 QPS (每秒查询率)达到上限， 如何解决 ？ 2、 初步方案 增加 N 个 缓存节点 ，为了保证 缓存数据的均匀 ，一般情况会采用对 key值hash ，然后 取模 的方式，然后根据结果，确认数据落到哪台节点上：如下： hash(key)%N 很好，这个的确解决了上面的问题，实现了 初步的分布式缓存 ， 数据均匀分散 到了各个节点上， 流量请求也均匀的分散 到了各个节点。 (1) 但是如果出现以下情况，会带来什么问题？ 某台服务器 突然宕机 。缓存服务器从 N 变为 N-1 台。 缓存容量 达到 上限 或者 请求处理达到上限 ，需要 增加缓存服务器 ，假定增加1台，则缓存服务器从 N 变为 N+1 上面的情况带来的问题： 增加 或者 删除 缓存服务器的时候，意味着 大部分的缓存都会失效 。这个是 比较致命 的一点，缓存失效，如果 业务为缓存不命中 ，查询DB的话，会导致 一瞬间DB的压力陡增 。可能会 导致整个服务 不可用。 (2) 换种描述方式，我们需要解决怎么样的问题？或者需求是怎样的？ 增删 机器时，

本文转载自： https://www.cnblogs.com/lpfuture/p/5796398.html 如有侵权，请告知下线，多谢！！ 0. 目的 分布式系统中节点根据哈希取值进行保存数据，当有节点新增或者节点下线，普通哈希算法会需要所有数据的哈希分布重新计算。而一致性哈希算法只需要重新计算下线的节点的数据即可。关键在于数据在环上，顺时针向最靠近的节点分布。 1. 一致性Hash性质 考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，如何保证当系统的节点数目发生变化时仍然能够对外提供良好的服务，这是值得考虑的，尤其实在设计分布式缓存系统时，如果某台服务器失效，对于整个系统来说如果不采用合适的算法来保证一致性，那么缓存于系统中的所有数据都可能会失效（即由于系统节点数目变少，客户端在请求某一对象时需要重新计算其hash值（通常与系统中的节点数目有关），由于hash值已经改变，所以很可能找不到保存该对象的服务器节点），因此一致性hash就显得至关重要，良好的分布式cahce系统中的一致性hash算法应该满足以下几个方面： 平衡性(Balance) 平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。 单调性(Monotonicity) 单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中

分布式系统中一致性哈希算法 此博文转载自 分布式系统中一致性哈希算法 ，博主对分布式系统中最常见的一致性哈希算法进行了非常细致的讲解，非常值得阅读！另外博主在博客园上定制的皮肤样式也是非常好看，推荐一波~ 业务场景 近年来，由于互联网的兴起，B2C、O2O等商业概念的提出和移动端的发展，使得分布式系统流行起来。分布式系统相对于单一系统而言，带来了流量大、系统高可用和高容错的便利。功能强大的同时，也意味着实现起来需要更多的技术支持。例如系统访问层的 负债均衡 、缓存层的 多实例主从复制备份 以及数据层的 分库分表 等。 我们以负载均衡为例，常见的负载均衡方法有很多，但是它们的优缺点都很明显： 随机访问策略： 系统随机访问，缺点：可能造成服务器负载压力不均衡，俗话讲就是撑的撑死，饿的饿死。 轮询策略： 请求均匀分配，如果服务器有性能差异，则无法实现性能好的服务器能够多承担一部分。 权重轮询策略： 权值需要静态配置，无法自动调节，不适合对长连接和命中率有要求的场景。 Hash取模策略： 不稳定，如果列表中某台服务器宕机，则会导致路由算法产生变化，由此导致命中率的急剧下降。 一致性哈希策略（本文重点分析） 以上几个策略，排除本篇介绍的一致性哈希策略，可能使用最多的就是 Hash取模策略 了。Hash取模策略的缺点也是很明显的，这种缺点也许在负载均衡的时候不是很明显

1.一致性哈希 什么是一致性哈希，和一般的分布式哈希表 (DHT)有什么区别？一般的 DHT使用以下公式进行数据定位： position = Hash(对象名 ) % N（ N是节点个数）。 很明显，如果我们在集群中增减一个节点，都必须要重新计算对象的位置，导致大量的数据迁移的发生。文中的对象表示文件 ( 分布式文件系统 ) 或者数据块 (p2p) 。 2.一致性哈希的改进 3.一致性哈希的实现 参考 来源： https://www.cnblogs.com/dennis-wong/p/11374737.html