Redis集群的那些谜

下列问题是我在搭建Redis集群之前与实验过程发出的疑问

随着我Redis集群的成功搭建，疑问也一个一个解开

Redis集群搭建参考资料

Redis-Cluster参考资料

Redis集群的数据互通吗？

先说结论：==互通的；往Redis集群里存放一个数据时，他会以Hash Slot哈希槽的方式将数据存放在不同的结点，取出对应Key时，再连接到该结点去取出。==

• 以集群模式随机连接至一个Redis结点，此结点中无数据：

    root@hadoop102:~/myredis# ./redis-cli -c -h 192.168.150.102 -p 7002
    192.168.150.102:7002> keys *
    (empty list or set)

• 随机Set多个值，发现客户端居然在结点间不停地切换：

    192.168.150.102:7002> set helloWorld OKOK
    -> Redirected to slot [519] located at 192.168.150.102:7001
    OK
    192.168.150.102:7001> set OKOK hahaha
    -> Redirected to slot [13171] located at 192.168.150.104:7001
    OK
    192.168.150.104:7001> set XIXIXI OKOKOK
    -> Redirected to slot [10749] located at 192.168.150.103:7001
    OK

• 在某一个结点上，查看结点上的Key，并get一个曾经set过的，但是并不存放此结点的Key，发现连接到了该结点，并成功取出了。

    192.168.150.102:7001> keys *
    1) "hello"
    2) "helloWorld"
    192.168.150.102:7001> get OKOK
    -> Redirected to slot [13171] located at 192.168.150.104:7001
    "hahaha"

为什么在集群模式下Set和Get总是会出现Redirected to slot字样，并跳转到目的主机？

因为Redis集群采用了Hash Slot的模式，每个结点都存放一段不同的分片

Redis集群中有16384个hash slots，为了计算给定的key应该在哪个hash slot上，我们简单地用这个key的CRC16值来对16384取模。（即：key的CRC16 % 16384）

为什么要使用Hash Slots而不是一致性哈希算法？

• Hash Slots继承并增强一致性哈希的容错性，扩展性，以及平衡性。 Redis在此种算法下，可以当缓存，也能当存储数据库！

因为将hash slots从一个节点移动到另一个节点并不需要停止其它的操作，添加、删除节点以及更改节点所维护的hash slots的百分比都不需要任何停机时间。也就是说，移动hash slots是并行的，移动hash slots不会影响其它操作。

集群模式下，不同数据存放在不同的结点，那怎么该结点宕机了怎么办？

结论

• 启动Master-Slave模式，为每一个Master配备Slave
• 当Master宕机后，Slave内有Master的备份数据，将代替Master工作，不至于集群的数据丢失
• 当集群中的其中一组Master和Slave都不可用的情况下，，Hash-Slots的分片数据丢失，集群不可用

实战演示

• Redis-Cluster模式中，验证Master和Slave数据是否一致：
  • 数据连接到集群中的一台Master查看其Slave信息：命令info

        # Replication
        role:master
        connected_slaves:2
        slave0:ip=192.168.150.102,port=7003,state=online,offset=4873,lag=1
        slave1:ip=192.168.150.104,port=7003,state=online,offset=4873,lag=1

 *  查看`Master`数据，并连接到其中一个`Slave`查看数据：

        192.168.150.103:7001> keys *
        1) "test"
        2) "OKO"
        3) "XIXIXI"
        192.168.150.103:7001>
        root@hadoop102:~/myredis# ./redis-cli -c -h 192.168.150.102 -p 7003
        192.168.150.102:7003> keys *
        1) "XIXIXI"
        2) "OKO"
        4) "test"

 *  人为宕掉`Master`后马上在`Slave`上查看状态：`down`宕机状态

        # Replication
        role:slave
        master_host:192.168.150.103
        master_port:7001
        master_link_status:down

 *  过了几秒后再次查看：有了新的`Master`

        # Replication
        role:slave
        master_host:192.168.150.104
        master_port:7003
        master_link_status:up

 *  其实此结点也可能成为结点，条件如下：

     *  竞选`Master`结点条件优先级：

         *  配置文件中的优先级，高的优先
         *  结点的数据偏移量，高的优先
         *  集群启动时的`run_id`， 小的优先

文章永久链接：https://tech.souyunku.com/45740