接上一节内容，本节我们将初步测试一下这个Redis集群【集群存值变化，以及主节点的挂掉和重启时，对应集群状态变化】。
1、测试连接集群
按照redis cluster的特点，它是去中心化，去中间件，每个节点都是对等的。所以，你连接哪个节点都可以获取和设置数据，我们来试一下。
redis-cli是redis默认的客户端工具，启动时加上｀-c｀参数，就可以连接到集群【“-c”，这个参数表示我们将打开集群的一个客户端】。
连接任意一个节点端口：
存入一个值：
由先前的理论知识，Redis集群在分配key的时候，它会使用CRC16('my_name')%16384算法计算出一个结果值，根据这个值与节点哈希槽的范围进行比对，进而决定将这个key 放到哪个节点，这里分配到了12803 slot 就分配到了6383(10923-16383)这个节点上。
Redirected to slot [12803] located at 192.168.72.134:6383
Redis cluster采用的方式比较直接，它直接跳转到6383这个节点上，而不是停留在自身的6381节点。
现在我们连接6385这个从节点，从这个节点客户端查询刚才存入的值：
我们在6385这个节点客户端上，同样是获取my_name的值，而它同样也是跳转到了6383节点上。
test others:
可以看出，数据都会在集群的主节点之间相互跳转进行存储。
2、测试集群中的master主节点宕机
模拟其中一台Master主服务器节点已死的情况，那就6384节点宕机：
可以看到，集群中6384这个节点已死，因为6384的从节点只有6381，理论上，肯定6381就会被选举称Master节点了，那么我们检查一下集群节点状态：
| ./redis-trib.tb check 192.168.72.134:6381 |
果然，6381被选举出来，成了替代6384的主节点了。那我们来获取原先存在6384节点的数据：
数据并没有丢失，而是从6381上面获取了。
3、测试集群中的宕机master节点重启
这个时候，突然集群中刚才宕机的6384节点又重启了，那么6384这个节点还会自动加入到集群中吗？此时，6384这个节点在集群中充当什么角色呢？
重新启动 6384节点：
我们看到，集群中6384这个节点已经重启，现在查询一下集群节点状态：
| ./redis-tirb.tb check 192.168.72.134:6384 |
6384节点重启了，但是它却成为6381的从节点，验证了之前我们的理论分析结果图：
即，集群中master节点挂掉之后，它名下slave节点将被选举顶替master成为新的主节点；
如果已挂的master节点再次启动加入集群，这个时候将作为新的从节点分配给已选举出的新master节点。
4、测试集群中的slave从节点宕机和重启
这里关于slave节点的挂掉和重启时，集群状态变化，可参考上述测试进行，不再赘述。
从节点宕机，因为其并未分配哈希槽，并不影响其附属的master节点状态。
从节点重启，集群将根据现有master节点下从节点存活情况，灵活地安排重启节点附加给没有slave节点的master上。
下一节，我们测试在集群中新增、删除master/slave节点时，集群的变化情况。