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， 小的优先