面试题：1~2亿数据需要缓存，请问如何设计个存储案例

回答：单机单台100%不可能，肯定是分布式存储，用redis如何落地？

一般业界有三种解决方案：

哈希取余分区

2亿条记录就是2亿个k，v，我们单机不行必须要分布式多机，假设有三台机器构成一个集群，用户每次读写操作都是根据公式：hash(key)%N个机器台数，计算出哈希值，用来界定数据印射到哪一个节点上。
优点：简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台，8台，10台，就能保证一段时间的数据支撑。使用Hash算法让入定的一部分要求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用

缺点：原来规划好的缺点，进行扩容或者缩容就比较麻烦了，不管扩缩，每次数据变动导致结点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性孔融或者故障停机的情况下，原来的取模公式就会发生变化：hash（key）/3就会发生变动。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。

某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

哈希算法分区

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

​ 它也是按照使用取模的方法，前面介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性hash算法是对2^{32取模，简单来说，一致性hash算法将整个哈希值空间组成一个虚拟的圆环，如假设哈希函数H的值空间为0-2}32-1(即哈希值是一个32位无符号整形)，整个哈希环如下图：整个空间按照顺时针反向组织，圆环的正上方的点代表0,0点右侧的第一个点代表1，依次类推，直到2^{32-1,也就是0点左侧的第一个点代表2}32-1,0和2^{32-1在0点中方向整合，我们把这个由2}32个点组成的圆环称为hash环

节点映射：将集群中各个ip节点映射到环上的某一个位置

将各个服务器使用hash进行一个哈希，具体可以选择服务器的ip或主机名作为关键字哈希，这样每台机器就能确定其在哈希环上的位置。加入4个结点nodeA,B,C,D,经过ip地址的哈希函数计算（hash（ip））,使用ip地址哈希后在环空间位置如下

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

如我们有objectA,objectB,objectC,objectD四个数据对象，经过哈希计算后，在环空间的位置如下：根据一致性hash算法，数据A会被定为到nodeA上，b会被定为到nodeB上，c会定为到nodeC上，d会被定为到nodeD上。

优点

容错性：假设nodec宕机，可以看到此时对象A,B,D不会收到英雄昂，只有c对象被重定为到nodeD。一般的，在意识形态hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着顺时针方向行走遇到的第一台服务器)之间的数据，其他不会收到影响。简单来说，就是c挂了，受到影响的知识B,C之间的数据，并且这些数据会转移到D进行存储

扩展性：数据量增加了，需要增加一台结点nodex，x的位置在A,B之间，那受到的影响也就是A到X之间的数据，重新把A到X的数据录入到X上即可，不会导致hash取余全部数据重洗牌。

缺点

hash环的数据倾斜问题

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

总结

为了在结点数目发生改变时尽可能少的迁移数据

将所有的存储接地点配列在首尾相接的hash环上，每个可以在计算hash后会顺时针找到临近的存储点存放。而当有结点加入或退出时仅影响该节点在hash环上顺时针相邻的后续结点

优点：加入和删除只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响

缺点：数据的分布和节点位置有关，因为这些节点不是均匀分布在hash环上的，所以数据在进行存储时达不到均匀分布的效果。

哈希槽分区

1，为什么会出现一致性哈希算法的数据倾斜问题，哈希槽实质就是一个数组，数据[0,2^14-1]形成hash slot空间

2，能干什么：解决均匀分配的问题，在数据和及节点之间又加入了一层，把这层称为哈希槽(slot),用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动，哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配，

3，多少个hash槽

一个集群只能有16384个槽，编号0-16383(0-2^14-1).这些槽会分配给集群中所有主节点，分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。解决了节点和槽的关系后，接下来就需要对可以求哈希值，然后对16384取余，余数是几key就落入对应的槽里。slot=CRC16(key)%16384.以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

redis集群中内置了16384个哈希槽，redis会根据节点数量大致均等的将哈希槽映射到不同的节点，当需要在redis集群中放置一个key-value时，Redis先对key使用crc16算法算出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号都在0-16484之间哈希槽，也就是映射到某个节点上。如下代码，key之A，B在node2，key之C落在node3上