一、什么是集群
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
单个redis存在不稳定性，当redis服务宕机了，就没有可以用的服务了，因为单个redis的读写能力是有限的，所以有了redis集群，基于redis主从复制实现的，主要就是为了强化redis的读写能力。
1 、 redis主从复制
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
|
|
主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
2、哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
3、Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
数据分布理论
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。Redis Cluster采用哈希分区规则
- 节点取余分区
- 一致性哈希分区
- 虚拟槽分区(redis-cluster采用的方式)
顺序分区
哈希分区
例如按照节点取余的方式，分三个节点
1~100的数据对3取余，可以分为三类
- 余数为0
- 余数为1
- 余数为2
那么同样的分4个节点就是hash(key)%4
节点取余的优点是简单，客户端分片直接是哈希+取余
虚拟槽分区
Redis Cluster采用虚拟槽分区
虚拟槽分区使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。
Redis Cluster槽的范围是0 ～ 16383。
作者原话，关注下。
1、普通心跳数据包携带节点的完整配置，该配置可以用旧配置以幂等方式替换，以便更新旧配置。这意味着它们包含原始形式的节点的槽配置，16k的槽配置需要使用2k内存空间，但是使用65k槽将使用8k的内存空间。
2、同时，由于其他设计折衷，Redis集群不可能扩展到超过1000个节点。
因此，16k是比较合适的，可以确保每个主设备有足够的槽，最大为1000个。redis的node配置信息通过位图存储传输的，传输前有一个压缩过程，压缩比跟槽个数和节点数有很大关系（because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.）【槽数量／节点数】当这个N越大，压缩比就越小。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，
每个节点负责一定数量的槽。
集群进入fail状态的必要条件
A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态
一、什么是集群
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
单个redis存在不稳定性，当redis服务宕机了，就没有可以用的服务了，因为单个redis的读写能力是有限的，所以有了redis集群，基于redis主从复制实现的，主要就是为了强化redis的读写能力。
1 、 redis主从复制
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
|
|
主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
2、哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
3、Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
数据分布理论
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。Redis Cluster采用哈希分区规则
- 节点取余分区
- 一致性哈希分区
- 虚拟槽分区(redis-cluster采用的方式)
顺序分区
哈希分区
例如按照节点取余的方式，分三个节点
1~100的数据对3取余，可以分为三类
- 余数为0
- 余数为1
- 余数为2
那么同样的分4个节点就是hash(key)%4
节点取余的优点是简单，客户端分片直接是哈希+取余
虚拟槽分区
Redis Cluster采用虚拟槽分区
虚拟槽分区使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。
Redis Cluster槽的范围是0 ～ 16383。
作者原话，关注下。
1、普通心跳数据包携带节点的完整配置，该配置可以用旧配置以幂等方式替换，以便更新旧配置。这意味着它们包含原始形式的节点的槽配置，16k的槽配置需要使用2k内存空间，但是使用65k槽将使用8k的内存空间。
2、同时，由于其他设计折衷，Redis集群不可能扩展到超过1000个节点。
因此，16k是比较合适的，可以确保每个主设备有足够的槽，最大为1000个。redis的node配置信息通过位图存储传输的，传输前有一个压缩过程，压缩比跟槽个数和节点数有很大关系（because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.）【槽数量／节点数】当这个N越大，压缩比就越小。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，
每个节点负责一定数量的槽。
集群进入fail状态的必要条件
A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态
一、什么是集群
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
单个redis存在不稳定性，当redis服务宕机了，就没有可以用的服务了，因为单个redis的读写能力是有限的，所以有了redis集群，基于redis主从复制实现的，主要就是为了强化redis的读写能力。
1 、 redis主从复制
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
|
|
主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
2、哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
3、Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
数据分布理论
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。Redis Cluster采用哈希分区规则
- 节点取余分区
- 一致性哈希分区
- 虚拟槽分区(redis-cluster采用的方式)
顺序分区
哈希分区
例如按照节点取余的方式，分三个节点
1~100的数据对3取余，可以分为三类
- 余数为0
- 余数为1
- 余数为2
那么同样的分4个节点就是hash(key)%4
节点取余的优点是简单，客户端分片直接是哈希+取余
虚拟槽分区
Redis Cluster采用虚拟槽分区
虚拟槽分区使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。
Redis Cluster槽的范围是0 ～ 16383。
作者原话，关注下。
1、普通心跳数据包携带节点的完整配置，该配置可以用旧配置以幂等方式替换，以便更新旧配置。这意味着它们包含原始形式的节点的槽配置，16k的槽配置需要使用2k内存空间，但是使用65k槽将使用8k的内存空间。
2、同时，由于其他设计折衷，Redis集群不可能扩展到超过1000个节点。
因此，16k是比较合适的，可以确保每个主设备有足够的槽，最大为1000个。redis的node配置信息通过位图存储传输的，传输前有一个压缩过程，压缩比跟槽个数和节点数有很大关系（because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.）【槽数量／节点数】当这个N越大，压缩比就越小。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，
每个节点负责一定数量的槽。
集群进入fail状态的必要条件
A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态
一、什么是集群
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
单个redis存在不稳定性，当redis服务宕机了，就没有可以用的服务了，因为单个redis的读写能力是有限的，所以有了redis集群，基于redis主从复制实现的，主要就是为了强化redis的读写能力。
1 、 redis主从复制
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
|
|
主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
2、哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
3、Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
数据分布理论
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。Redis Cluster采用哈希分区规则
- 节点取余分区
- 一致性哈希分区
- 虚拟槽分区(redis-cluster采用的方式)
顺序分区
哈希分区
例如按照节点取余的方式，分三个节点
1~100的数据对3取余，可以分为三类
- 余数为0
- 余数为1
- 余数为2
那么同样的分4个节点就是hash(key)%4
节点取余的优点是简单，客户端分片直接是哈希+取余
虚拟槽分区
Redis Cluster采用虚拟槽分区
虚拟槽分区使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。
Redis Cluster槽的范围是0 ～ 16383。
作者原话，关注下。
1、普通心跳数据包携带节点的完整配置，该配置可以用旧配置以幂等方式替换，以便更新旧配置。这意味着它们包含原始形式的节点的槽配置，16k的槽配置需要使用2k内存空间，但是使用65k槽将使用8k的内存空间。
2、同时，由于其他设计折衷，Redis集群不可能扩展到超过1000个节点。
因此，16k是比较合适的，可以确保每个主设备有足够的槽，最大为1000个。redis的node配置信息通过位图存储传输的，传输前有一个压缩过程，压缩比跟槽个数和节点数有很大关系（because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.）【槽数量／节点数】当这个N越大，压缩比就越小。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，
每个节点负责一定数量的槽。
集群进入fail状态的必要条件
A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态
一、什么是集群
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
单个redis存在不稳定性，当redis服务宕机了，就没有可以用的服务了，因为单个redis的读写能力是有限的，所以有了redis集群，基于redis主从复制实现的，主要就是为了强化redis的读写能力。
1 、 redis主从复制
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
|
|
主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
2、哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
3、Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
数据分布理论
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。Redis Cluster采用哈希分区规则
- 节点取余分区
- 一致性哈希分区
- 虚拟槽分区(redis-cluster采用的方式)
顺序分区
哈希分区
例如按照节点取余的方式，分三个节点
1~100的数据对3取余，可以分为三类
- 余数为0
- 余数为1
- 余数为2
那么同样的分4个节点就是hash(key)%4
节点取余的优点是简单，客户端分片直接是哈希+取余
虚拟槽分区
Redis Cluster采用虚拟槽分区
虚拟槽分区使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。
Redis Cluster槽的范围是0 ～ 16383。为啥？？？？？
作者原话，关注下。
1、普通心跳数据包携带节点的完整配置，该配置可以用旧配置以幂等方式替换，以便更新旧配置。这意味着它们包含原始形式的节点的槽配置，16k的槽配置需要使用2k内存空间，但是使用65k槽将使用8k的内存空间。
2、同时，由于其他设计折衷，Redis集群不可能扩展到超过1000个节点。
因此，16k是比较合适的，可以确保每个主设备有足够的槽，最大为1000个。redis的node配置信息通过位图存储传输的，传输前有一个压缩过程，压缩比跟槽个数和节点数有很大关系（because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.）【槽数量／节点数】当这个N越大，压缩比就越小。
搭建redis集群
一 所需软件:
Redis 3.2
Ruby语言运行环境
Redis的Ruby驱动redis-xxxx.gem
创建Redis集群的工具redis-trib.rb
1) 下载Redis-x64-3.2.100.zip。
**********************************************************************************************************************************************
要让集群正常运作至少需要3个主节点，建议配置3个主节点，其余3个作为各个主节点的从节点（也是官网推荐的模式）。
所以需要6台虚拟机。
主节点崩溃，从节点的Redis就会提升为主节点，代替原来的主节点工作，崩溃的主Redis恢复工作后，会再成为从节点。
**********************************************************************************************************************************************
2) 创建Redis集群目录
把 redis 解压后，再复制出 5 份，配置 三主三从集群。 由于 redis 默认端口号为 6380，那么其它5份的端口可以为6380，6381，6382，6383，6384 ，6385。 并且把目录使用端口号命名
3) 修改配置文件
打开每个Redis目录下的文件 redis.windows.conf，修改里面的端口号分别对应相对应的文件夹名：6380，6381，6382，6383，6384 ，6385，
再修改集群支持配置，将以下配置前面的#去掉。
以6380为例，打开文件夹中的redis.windows.conf文件，分别修改里面的如下数据：
port 6380 //修改默认端口，与文件夹相同即可
cluster-enabled yes //开启实例的集群模式
cluster-config-file nodes-6379.conf //设定保存节点配置文件的路径，节点文件自动生成，无需修改
cluster-node-timeout 15000 //调整为 15000，那么在创建集群的时候，不会超时。
appendonly yes //开启appendonly模式后，redis将每一次写操作请求都追加到appendonly.aof文件中
注意：修改配置文件的时候去掉注释的部分，前面不能有空格
同时还有一个文件 redis.windows-service.conf也需要修改相同之处，保存即可
另外，在每个文件夹中写一个bat用来启动redis，内容如下：
title redis-6379（相对应的端口号）
redis-server.exe redis.windows.conf
建立完成之后，可以分别点击每个文件夹中的bat，启动每个redis。
二 安装Ruby
redis的集群使用 ruby脚本编写，所以系统需要有 Ruby 环境 ,下载地址
https://rubyinstaller.org/downloads/
三 安装Redis的Ruby驱动redis-xxxx.gem
下载地址 https://rubygems.org/pages/download
下载后解压，当前目录切换到解压目录中，如 D:\Program Files\Redis_cluster\rubygems-2.7.7 然后命令行执行 ruby setup.rb
再用 GEM 安装 Redis ：切换到redis安装目录，需要在命令行中，执行 gem install redis
redis-trib.rb集群的命令为
redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385
四 启动每个节点并且执行集群构建脚本
把每个节点下的 start.bat双击启动， 在切换到redis目录在命令行中执行
redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385
五 连接集群进行测试
使用Redis客户端Redis-cli.exe来查看数据记录数，以及集群相关信息
命令 redis-cli –c –h ”地址” –p "端口号" ; c 表示集群
redis-cli -c -h 127.0.0.1 -p 6380
查看集群的信息，命令：cluster info
查看主从关系，命令： info replication
查看各个节点分配slot，命令 cluster nodes
cluster keyslot test 查询对应的槽
Redis集群数据分配策略：
采用一种叫做哈希槽 (hash slot)的方式来分配数据，redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384
注意的是：必须要3个以上的主节点，否则在创建集群时会失败，三个节点分别承担的slot 区间是：
节点A覆盖0－5460;
节点B覆盖5461－10922;
节点C覆盖10923－16383.
动态增删节点
一、动态增加节点
1.添加命令
redis-trib.rb add-node newIP:port oldIP:port
2.重新分片（reshard）
redis-trib.rb reshard newIP:port
提示
// 打算分配多少槽点给当前节点
How many slots do you want to move (from 1 to 16384)?
输入 200 （意思是给当前节点分配200个槽点）
// 接收节点的ID是多少，也就是当前节点的ID
What is the receiving node ID?
输入 b062c61070542120c4cc6d6bb1e9c800a28f1be7
// 这里支持从所有节点平均分配槽点，以及从指定节点分配槽点两种方式
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: // 这里输入槽点来源节点的ID，已done结束，或all（如果是all，则表示从所有节点获取）
这里提示 Source node #1: 我们输入 7001 对应的ID，回车后，输入 done 执行提交
Source node #2: done
回车后会展示分配计划，并提问是否确认分片计划
Do you want to proceed with the proposed reshard plan (yes/no)? yes
输入 yes 即可。
3.添加从节点使用同主节点命令
切换客户端到新添加的从节点 让它成为刚添加的主节点的从节点
cluster replicate b062c61070542120c4cc6d6bb1e9c800a28f1be(这个是主节点的Id)
Eg: redis-trib.rb add-node 127.0.0.1:6386 127.0.0.1:6380 6386是新增的节点， 6380是现有节点的任意一个节点 为了建立联系 随便写那个都可以！
二、动态删除节点
- ruby redis-trib.rb reshard 127.0.0.1：6386
提示：
how many move….. 切记输入分配节点数-1 因为是从0开始
what is receving node id --- 接受槽的Master主节点ID：这个节点可以是任意一个主节点都可以。，输入对应的id
source node id_2 - ---- 输入要删除的节点的id
- ruby redis-trib.rb del-node 127.0.0.1：6386 71ecd970838e9b400a2a6a15cd30a94ab96203bf
删除从节点只需要用第二个命令 del-node这个删除就可以了！
总结
主从复制和哨兵模式这两个集群模式由于不能动态扩容，而且主节点之间（有多个主节点的情况）数据完全一样，导致了主节点的容量成了整个集群的瓶颈，如果想扩展集群容量，必须扩展主节点的容量。但是redis-Cluster集群模式，这个模式在主节点之间数据是不一样的，数据也可以根据需求自动转向其他节点。这样就可以实现横向动态扩容，新增加的主从节点，用于存储新的数据则可，对以前的节点的数据不会有任何影响。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，
每个节点负责一定数量的槽。
集群进入fail状态的必要条件
A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态
一、什么是集群
所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。
单个redis存在不稳定性，当redis服务宕机了，就没有可以用的服务了，因为单个redis的读写能力是有限的，所以有了redis集群，基于redis主从复制实现的，主要就是为了强化redis的读写能力。
1 、 redis主从复制
主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。
只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。
|
|
主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。
2、哨兵模式
当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。
（1）监控主服务器和从服务器是否正常运行。
（2）主服务器出现故障时自动将从服务器转换为主服务器。
3、Redis-Cluster集群
redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
Redis-Cluster采用无中心结构,它的特点如下：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的fail是通过集群中超过半数的节点检测失效时才生效。
客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
数据分布理论
分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
常见的分区规则有哈希分区和顺序分区。Redis Cluster采用哈希分区规则
- 节点取余分区
- 一致性哈希分区
- 虚拟槽分区(redis-cluster采用的方式)
顺序分区
哈希分区
例如按照节点取余的方式，分三个节点
1~100的数据对3取余，可以分为三类
- 余数为0
- 余数为1
- 余数为2
那么同样的分4个节点就是hash(key)%4
节点取余的优点是简单，客户端分片直接是哈希+取余
虚拟槽分区
Redis Cluster采用虚拟槽分区
虚拟槽分区使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。
Redis Cluster槽的范围是0 ～ 16383。
作者原话，关注下。
1、普通心跳数据包携带节点的完整配置，该配置可以用旧配置以幂等方式替换，以便更新旧配置。这意味着它们包含原始形式的节点的槽配置，16k的槽配置需要使用2k内存空间，但是使用65k槽将使用8k的内存空间。
2、同时，由于其他设计折衷，Redis集群不可能扩展到超过1000个节点。
因此，16k是比较合适的，可以确保每个主设备有足够的槽，最大为1000个。redis的node配置信息通过位图存储传输的，传输前有一个压缩过程，压缩比跟槽个数和节点数有很大关系（because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.）【槽数量／节点数】当这个N越大，压缩比就越小。
槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，
每个节点负责一定数量的槽。
集群进入fail状态的必要条件
A、某个主节点和所有从节点全部挂掉，我们集群就进入faill状态。
B、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态.
C、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态