在《实现redis哨兵，模拟master故障场景》（链接：https://blog.51cto.com/u_15473594/5341779）一文中，笔者演示了通过脚本来实现redis6.2.4版本的编译安装，redis5版本的安装方法类似（redis3和4版本要用到redis-trib.rb，依赖于高版本的ruby，需先编译安装2.3版本以上的ruby），而且此次试验要求的主机较多，笔者就直接在CentOS8中通过yum来安装演示。
此次实验笔者准备了6台虚拟机，ip分别为10.0.0.{8,18,28,38,48,58}，前三台作为master节点，后三台按序作为前三台的slave节点，由于从节点会在对应的主节点出现故障后通过选举变为主节点，故六台主机名分别取名node1-6。
- 所有节点安装redis服务
CentOS8通过yum安装的redis为5.0.3版本，刚好满足此次实验要求，笔者就直接通过yum来安装，redis服务需要在所有的节点上都安装好。
- 启用redis cluster配置
要想实现redis cluster，需要对redis服务配置文件进行修改。首先是将bind部分由127.0.0.1的本机改为0.0.0.0；masterauth部分建议配置，否则后期的master和slave主从复制无法成功，还需再配置；requirepass部分取消前面的注释，并设置一个密*码用于客户端连接；cluster-enabled yes部分取消前面的注释，必须开启集群，开启后redis进程会有cluster标识；cluster-config-file部分取消前面注释，此为集群状态文件，记录主从关系及slot范围信息，由redis cluster集群自动创建和维护；cluster-require-full-coverage部分将默认值yes改为no，可以防止一个节点不可用导致整个cluster都不可用。
修改完启动redis服务，查看端口发现6379和16379端口已经打开，其中前者为redis服务端口，后者就是redis cluster的（redis cluster端口=redis端口号+10000）。查看redis进程，发现服务后面也有了cluster的标注。
- 创建redis cluster集群
执行redis-cli --cluster help命令可以查看redis cluster集群使用的相关帮助，接下来我们要用到的就是create部分。
创建集群时可以一个个节点的添加，不过这种方式需要手动去分配每个master节点的槽位和对应的从节点，也可使用--cluster create跟上所有的节点ip+端口同时添加所有的节点进来，后面再跟上--cluster-replicas 1，表示每个master节点对应一个从节点，按照次序自动将前一半的主机作为master节点，后一半按次序作为前面master节点的从节点，并会自动分配好槽位。在此过程中，我们需要敲一个yes进行自动创建集群的确认。
- 查看redis cluster集群信息
4.1 查看主从状态
按照以上的自动划分，主节点ip分别为10.0.0.{8,18,28}，对应的从节点分别为10.0.0.{38,48,58}，我们可以在各个节点上查看并验证是否与以上的自动划分保持一致。
4.2 查看集群状态
执行redis-cli -a <password> cluster info命令可查看集群状态，这里重点要注意的是cluster_known_nodes和cluster_size，前者表示redis cluster集群节点数，后者表示集群数。
如果想查看某一个节点的集群状态，在以上命令的基础上加上对应节点的ip和端口号即可。
4.3 查看nodes对应关系
执行redis-cli -a <password> cluster nodes命令可查看集群中的nodes对应关系，例如每个节点的和ipID、master和slave都有谁、每个master对应的slave是谁、每个master所拥有的的槽位编号等。
我们也可执行redis-cli -a <password> --cluster check ip:port命令在任意节点上查看nodes对应关系。
- 验证集群写入key
5.1 redis cluster写入key
在redis cluster中，客户端登录到任意节点发出key的命令，经过CRC16的哈希算法将该key指定到对应主机的指定槽位中，如果该槽位在客户端登录的redis节点上则可直接执行，如果槽位不在登录的redis节点上，会回复removed，要求客户端重定向发送key命令到对应的redis节点。
例如笔者这边登录到node1节点上，想要设置key1对应的value值value1，执行命令后提示要在10.0.0.18上操作，登录到对应的node上再执行相同命令即可写入。
由于是在node2上写入的key1，所以可以直接在node2上查看key1对应的value，而node5作为node2的从节点是无法查看value值的，但是能看到有一个key，其他节点上是无法查看是否有key1的存在的。
5.2 redis cluster计算key所在的槽位
在查看集群状态部分，我们了解到执行redis-cli -a <password> cluster nodes命令还可了解具体槽位所对应的master是谁，执行redis-cli -a <password> --no-auth-warning cluster keyslot key命令可计算key所对应的槽位是多少，例如我们想要写入hello这个key，计算后发现是886，而886这个槽位对应的master为node1，在node2或其他节点中是没办法写入的。
5.3 以集群形式写入key
让客户端通过计算后再登录到对应节点进行写入或其他操作难免过于繁琐，加上-c选项即可以集群形式连接，在集群所包含的任意节点进行写入和查看。例如以上hello这个key是只能在node1上写入，要在其他节点修改也不可能，但是加上-c选项即可进行在node2或者其他节点进行修改，并且使用-c选项也能任意节点查看集群中任意k-v键值对信息。
- Python脚本实现redis cluster集群写入
6.1 利用Python脚本批量写入数据
由于redis cluster会根据客户端的key得出哈希值来放到对应的槽位中，为了查看redis cluster的该算法是否能起到负载均衡作用和解决了写入瓶颈问题，我们可以利用Python脚本批量写入1000个key来查看效果。利用Python脚本写入时，需要先安装python3和redis-py-cluster。
接下来笔者创建一个简单的Python脚本，往redis cluster集群中批量写入1000个k-v键值对，key部分为key0-999，对应的value部分为value0-999。
6.2 验证数据
1000条数据（上面实验的两条数据未清，key1的值被覆盖，故总量加起来为1001）分给三台master节点，平均在333左右，通过查看三台master节点的数据量，可以发现还是比较平均的，没有出现偏向于一个或两个节点的情况，说明redis cluster的这种CRC16形式哈希算法还是很可靠的。根据已生成的数据，我们查看数据是否符合算法规则时，例如key88，对应的value为value88，显示的是在ip为10.0.0.28的master节点上，登录到该节点，也确实能获取到key88对应的value值。
- 模拟master故障
7.1 主从节点自动切换
我们知道在redis sentinel机制中，当master节点出现故障时，通过选举会让某一个slave节点变为新的master，在redis cluster中也有相同的功能。以node2节点出故障为例，node2登录到到redis后关闭redis服务，此时node2的redis服务相关端口已经关闭
在任意节点上查看node2之外的集群状态，可以看到node2对应的ip为10.0.0.48的从节点node5已经变成了新的master节点，由于node2已经关闭了服务，所以新提升为master节点的node5没有slave。
在上面的实验中，我们知道从节点是没办法查看key所对应的value值的，刚好key1是在node2中生成，现在node5替代node2成为了新的master，登录redis服务后，可以查看到key1所对应的值，并且也能做修改的写操作，说明确实变成了新的master。
7.2 故障节点重新加入集群
当出现故障的master节点重新加入集群时，也与sentinel一样，重回集群的原master节点不会抢回master的角色，而是扮演新master的从节点。例如我们重启node2的redis服务，在任意节点查看redis cluster状态，除了没出故障的两个master节点，新提升的master节点依旧保持为10.0.0.48，同时我们可以看到节点信息配置文件nodes-6379.conf中也自动进行了修改。
