分片集群结构

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

1.海量数据存储问题
2.高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

1.集群中有多个master，每个master保存不同数据
2.每个master都可以有多个slave节点
3.master之间通过ping监测彼此健康状态
4.客户端请求可以访问集群任意节点，最终都会被转发到正确节点

搭建分片集群

1.准备一个新的redis.conf文件：

port 6379
# 开启集群功能
cluster-enabled yes
# 集群的配置文件名称，不需要我们创建，由redis自己维护
cluster-config-file /tmp/6379/nodes.conf
# 节点心跳失败的超时时间
cluster-node-timeout 5000
# 持久化文件存放目录
dir /tmp/6379
# 绑定地址
bind 0.0.0.0
# 让redis后台运行
daemonize yes
# 注册的实例ip
replica-announce-ip 192.168.150.101
# 保护模式
protected-mode no
# 数据库数量
databases 1
# 日志
logfile /tmp/6379/run.log

2.将这个文件拷贝到每个目录下。
3.修改每个目录下的redis.conf，并做一定的修改。
4.启动相应的redis服务

5.创建集群
  虽然服务启动了，但是目前每个服务之间都是独立的，没有任何关联。我们需要执行命令来创建集群，在Redis5.0之前创建集群比较麻烦，5.0之后集群管理命令都集成到了redis-cli中。

redis-cli --cluster create --cluster-replicas n IP IP IP ...

• redis-cli --cluster 或者 ./redis-trib.rb ：代表集群操作命令
• create ：代表是创建集群
• –replicas 1 或者 --cluster-replicas 1 ：指定集群中每个master的副本个数为1，此时 节点总数 ÷ (replicas + 1)得到的就是master的数量。因此节点列表中的前n个就是master，其它节点都是slave节点，随机分配到不同master.

通过命令可以查看集群状态：

redis-cli -p 7001 cluster nodes

散列插槽

  Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到。

  可以简单理解为将16384个插槽分给这些master节点，每个master节点都有一个范围。写到某个插槽上就会写到具体某个master节点上。
  数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

1.key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分
2.key中不包含“{}”，整个key都是有效部分

  例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。
Redis如何判断某个key应该在哪个实例？

将16384个插槽分配到不同的实例
根据key的有效部分计算哈希值，对16384取余
余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

集群伸缩

  集群伸缩也就是往集群中添加master节点和删除master节点.
  redis-cli --cluster提供了很多操作集群的命令，可以通过下面方式查看：


  添加后记得分配插槽，将某个节点的插槽分给这个节点多少个，相应的数据也移（拷贝）到这个节点上。

故障转移

当集群中有一个master宕机会发生什么呢？

• 首先是该实例与其它实例失去连接
• 然后是疑似宕机：
  
• 最后是确定下线，自动提升一个slave为新的master：
  
    利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：
  
  手动的Failover支持三种不同模式：

1.缺省：默认的流程，如图1~6歩
2.force：省略了对offset的一致性校验
3.takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见