redis 分片
为什么要分片
问题：公司用户量3千万，用户基本信息缓存到redis中，需要内存10G，如何设计Redis的缓存架构？
- 3千万用户，各种业务场景对用户信息的访问量很大。（单台redis示例的读写瓶颈凸显）
- 单redis实例管理10G内存，必然影响处理效率。
- redis的内存需求可能超过机器的最大内存。 （一台机器不够用）
官方集群方案
redis cluster是Redis的分布式集群解决方案，在3.0版本推出后有效地解决了redis分布式方面的需求
实现了数据在多个Redis节点之间自动分片、故障自动转移、扩容机制等功能
官方集群方案
搭建集群
- 准备6个独立的redis服务
- 通过redis-cli工具创建集群
- 检验集群
- 故障转移测试
- 集群扩容
- 集群节点删除
集群关心的问题
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>，完成迁移操作。
集群从节点迁移
Redis集群实现了一个叫做复制（从节点）迁移的概念以提高系统的可用性
假设集群有三个主节点 A，B，C。 A、B都各有一个从节点，A1 和 B1。节点C有两个从节点：C1 和 C2
迁移过程如下，大致描述如下：
- 主节点 A 失效。A1 被提升为主节点。
- 节点 C2 迁移成为节点 A1 的从节点，要不然 A1 就没有任何从节点。
- 三个小时后节点 A1 也失效了。
- 节点 C2 被提升为取代 A1 的新主节点。
- 集群仍然能继续正常工作。
