redis cluster

官方集群方案

redis cluster是Redis的分布式集群解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求
实现了数据在多个Redis节点之间自动分片、故障自动转移、扩容机制等功能。

集群关心的问题 

 1 、增加了 slot 槽的计算，是不是比单机性能差？
共16384个槽，slots槽计算方式公开的， HASH_SLOT = CRC16(key) mod 16384 。
为了避免每次都需要服务器计算重定向，优秀的java客户端都实现了本地计算，并且缓存服务器slots分配，有变动时
再更新本地内容，从而避免了多次重定向带来的性能损耗。（结合画图过程理解）
 2、 redis 集群大小，到底可以装多少数据？
理论是可以做到16384个槽，每个槽对应一个实例，但是redis官方建议是最大1000个实例。存储足够大了
 3、 集群节点间是怎么通信的？
每个Redis群集节点都有一个额外的TCP端口，每个节点使用TCP连接与每个其他节点连接。检测和故障转移这些步骤基
本和哨兵模式类似（毕竟是同一个软件，同一个作者设计）。

4、 ask 和 moved 重定向的区别
重定向包括两种情况
 若确定slot不属于当前节点，redis会返回moved。
 若当前redis节点正在处理slot迁移，则代表此处请求对应的key暂时不在此节点，返回ask，告诉客户端本次请求重
定向。
5 、数据倾斜和访问倾斜的问题
倾斜导致集群中部分节点数据多，压力大。解决方案分为前期和后期：
 前期是业务层面提前预测，哪些key是热点，在设计的过程中规避。
 后期是slot迁移，尽量将压力分摊（slot调整有自动rebalance、reshard和手动）。

6 、 节点之间会交换信息，传递的消息包括槽的信息，带来带宽消耗。
注意：避免使用大的一个集群，可以分多个集群。
 7、  Pub/Sub 发布订阅机制
注意：对集群内任意的一个节点执行publish发布消息，这个消息会在集群中进行传播，其他节点接收到发布的消息。
 8 、 读写分离
 redis-cluster默认所有从节点上的读写，都会重定向到key对接槽的主节点上。
 可以通过readonly设置当前连接可读，通过readwrite取消当前连接的可读状态。
注意：主从节点依然存在数据不一致的问题

分片集群示意图

集群数据迁移方式

slot 手动迁移怎么做？
迁移过程如下，大致描述如下：
 在迁移目的节点执行cluster setslot <slot> IMPORTING <node ID>命令，指明需要迁移的slot和迁移源节点。
 在迁移源节点执行cluster setslot <slot> MIGRATING <node ID>命令，指明需要迁移的slot和迁移目的节点。
 在迁移源节点执行cluster getkeysinslot获取该slot的key列表。
 在迁移源节点执行对每个key执行migrate命令，该命令会同步把该key迁移到目的节点。
 在迁移源节点反复执行cluster getkeysinslot命令，直到该slot的列表为空。
在迁移源节点和目的节点执行cluster setslot <slot> NODE <node ID>，完成迁移操作。

集群从节点迁移

reids集群实现了一个叫做复制（从节点）迁移的概念，以提高系统的可用性。

假设集群有三个主节点 A A ，B B ，C C。 。 A A 、B B 都 各有一个从节点， A1 和 和 B1 。 节点C C 有 两个从节点： C1 和 和 C2
迁移过程如下，大致描述如下：
- 主节点 A 失效。A1 被提升为主节点。
- 节点 C2 迁移成为节点 A1 的从节点，要不然 A1 就没有任何从节点。
- 三个小时后节点 A1 也失效了。
- 节点 C2 被提升为取代 A1 的新主节点。
- 集群仍然能继续正常工作。