redis夺命连环问7--Redis怎么保存海量数据？

Redis怎么保存海量数据？

切片集群，横向扩展Redis、切片集群

Redis 应对数据量增多的两种方案：纵向扩展（scale up）和横向扩展（scale out）。

• 纵向扩展：升级单个 Redis 实例的资源配置，包括增加内存容量、增加磁盘容量、使用更高配置的 CPU。
  优点：实施起来简单、直接
  缺点：会受到硬件和成本的限制

• 横向扩展：横向增加当前 Redis 实例的个数
  优点：不用担心单个实例的硬件和成本限制。
  缺点：不可避免地涉及到多个实例的分布式管理问题。

哈希槽又是如何映射到 Redis 实例上呢？

• 根据键值对的 key，使用 CRC16 算法，计算出一个 16 bit 的值；
• 将 16 bit 的值对 16384 执行取模，得到 0 ～ 16383 的数表示 key 对应的哈希槽。
• 根据该槽信息定位到对应的实例。
  

那客户端如何定位数据呢？

Redis会把自己的哈希槽信息扩散给和它相连的其他哈希槽，这样每一个实例就都能知道所有的哈希槽映射信息了。 客户端知道哈希槽的分布之后，会缓存一份到本地。

在集群中，实例和哈希槽的对应关系并不是一成不变的：

• 在集群中，实例有新增或删除，Redis 需要重新分配哈希槽；
• 为了负载均衡，Redis 需要把哈希槽在所有实例上重新分布一遍。

实例之间还可以通过相互传递消息，获得最新的哈希槽分配信息，但是，客户端是无法主动感知这些变化的。

重定向 Redis Cluster 方案提供了一种重定向机制，所谓的“重定向”，就是指， 客户端给一个实例发送数据读写操作时，这个实例上并没有相应的数据，实例发送MOVED命令帮助客户端重定向访问正确的实例，然后再更新自己的缓存，和 MOVED 命令不同，ASK 命令并不会更新客户端缓存的哈希槽分配信息 。

在切片集群中，怎么应对数据倾斜？

• 啥是数据倾斜：
  数据倾斜有两类。
  数据量倾斜：在某些情况下，实例上的数据分布不均衡，某个实例上的数据特别多。
  数据访问倾斜：虽然每个集群实例上的数据量相差不大，但是某个实例上的数据是热点数据，被访问得非常频繁。

数据量倾斜的成因和应对方法

主要有三个原因，分别是某个实例上保存了 bigkey、Slot 分配不均衡以及 Hash Tag。

• bigkey 导致倾斜

bigkey 的 value 值很大（String 类型），或者是 bigkey 保存了大量集合元素（集合类型），会导致这个实例的数据量增加，内存资源消耗也相应增加。

应对：
一个根本的应对方法是，我们在业务层生成数据时，要尽量避免把过多的数据保存在同一个键值对中。
如果 bigkey 正好是集合类型，我们还有一个方法，就是把 bigkey 拆分成很多个小的集合类型数据，分散保存在不同的实例上。

• Slot 分配不均衡导致倾斜
  集群运维人员没有均衡地分配 Slot，就会有大量的数据被分配到同一个 Slot 中，而同一个 Slot 只会在一个实例上分布，这就会导致，大量数据被集中到一个实例上，造成数据倾斜。

应对：
可以通过运维规范，在分配之前，我们就要避免把过多的 Slot 分配到同一个实例。 如果是已经分配好 Slot 的集群，我们可以先查看 Slot 和实例的具体分配关系，从而判断是否有过多的 Slot 集中到了同一个实例。 如果有的话，就将部分 Slot 迁移到其它实例，从而避免数据倾斜。

• Hash Tag 导致倾斜
  Hash Tag 是指加在键值对 key 中的一对花括号{}。 这对括号会把 key 的一部分括起来，客户端在计算 key 的 CRC16 值时，只对 Hash Tag 花括号中的 key 内容进行计算。
  Hash Tag 主要是用在 Redis Cluster 和 Codis 中，支持事务操作和范围查询。因为 Redis Cluster 和 Codis 本身并不支持跨实例的事务操作和范围查询，当业务应用有这些需求时，就只能先把这些数据读取到业务层进行事务处理，或者是逐个查询每个实例，得到范围查询的结果。

应付 不用就行了

数据访问倾斜的成因和应对方法

发生数据访问倾斜的根本原因，就是实例上存在热点数据。

应对：可以采用热点数据多副本的方法来应对。
具体就是把热点数据复制多份，在每一个数据副本的 key 中增加一个随机前缀，让它和其它副本数据不会被映射到同一个 Slot 中。 热点数据的访问压力就被分散到不同的实例上了。

不足：热点数据多副本方法只能针对只读的热点数据。 因为要保证多副本间的数据一致性，会带来额外的开销。 对于有读有写的热点数据，我们就要给实例本身增加资源了。