分布式缓存

使用Docker搭建三主三从分布式缓存，由于有多个Redis需要算法来确定数据存放在哪个Redis中，一般有三种算法：哈希取余，一致性哈希，哈希槽。除此之外，为防止Redis宕机产生数据丢失的情况，使用主从复制的方式给每个主节点配置一个从节点。

哈希取余分区

定义：hash(key) % N个机器台数，计算出哈希值，用来决定数据映射到哪一个节点上。

优点：简单有效，只需预估好数据规划好节点，就能保证一段时间的数据支撑。

缺点：扩容和缩容都比较麻烦，每次数据变动导致节点有变动，映射关系需要重新进行计算。

一致性哈希

提出一致性Hash解决方案，目的是当服务器个数发生变动时， 尽量减少影响客户端到服务器的映射关系。

一致性哈希环

一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,2^32-1]，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(0 = 2^32),这样让它逻辑上形成了一个环形空间，即hash环。类似于leetcode上的循环队列。

节点映射

将集群中各个IP节点映射到环上的某一个位置。将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算(hash(ip))，使用IP地址哈希后在环空间的位置如下：

当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的Hash函数计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针行走，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。

假如有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下：根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。

容错性

假设Node C宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据，并且这些数据会转移到D进行存储。

扩展性

数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那受到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，不会导致全部数据重新洗牌。

数据倾斜问题

一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题。例如系统中只有两台服务器：

哈希槽

哈希槽实质就是一个数组，数组[0,2^14 -1]（16384个槽）形成hash slot空间。用来解决数据倾斜问题。在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系。

可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取余，余数是几key就落入对应的槽里。slot = CRC16(key) % 16384。