阿里大厂面试：2亿条数据需要缓存，如何设计这个存储方案？

对于2亿条数据需要缓存，使用单机肯定是不可能了，至少是分布式存储。

而分布式存储我们可以选择的选项有很多，今天我们单独来讨论下redis的解决方案。

使用redis如何落地。

在阿里p7工程案例和场景设计中，这一类的确是必问题，我们一般有三种解决方案：

第一种： 哈希取余算法

2亿条记录假设2亿个k,v，我们单机不行必须要分布式多机，假设有3台机器构成一个集群，用户每次读写操作都是根据公式：

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

比如0，就是最左的，1是中间的，2是最右边的。

这种方案是最常用的，也是最通用的

优点：
简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台、8台、10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。

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

某个red