Redis集群

介绍

• Redis 集群是一个提供在多个Redis间节点间共享数据的程序集
• Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
• Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis 集群的优势:
  • 自动分割数据到不同的节点上。
  • 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。

Redis 集群的数据分片

• Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.
• Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
  • 节点 A 包含 0 到 5500号哈希槽.
  • 节点 B 包含5501 到 11000 号哈希槽.
  • 节点 C 包含11001 到 16384号哈希槽.

Redis 集群的主从复制模型

• 为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.
• 在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.
• 然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了
• 不过当B和B1 都失败后，集群是不可用的.

Redis 一致性保证

• Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作
• 第一个原因是因为集群是用了异步复制. 写操作过程:
  • 客户端向主节点B写入一条命令.
  • 主节点B向客户端回复命令状态.
  • 主节点将写操作复制给他得从节点 B1, B2 和 B3.
• 发生网络分区问题时无法保证一致性，Redis最好仅用作缓存

搭建并使用Redis集群

• 集群最小配置文件
  • 文件中的 cluster-enabled 选项用于开实例的集群模式
  • 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodes.conf.节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

• 安装若干个节点，准备配置文件即可
• 搭建集群
  • 执行命令./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
    • 高版本使用：redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
    • 这个命令在这里用于创建一个新的集群, 选项–replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

集群重新分片

• redis-cli --cluster reshard 127.0.0.1:7000
  • 您只需要指定一个节点，redis-cli就会自动找到其他节点。
  • 当前redis-cli仅能在管理员支持下重新分片，您不能仅仅说将5％的插槽从该节点移到另一个节点（但这实现起来很简单）
• redis-cli --cluster check 127.0.0.1:7000 检查哈希槽分片情况
• redis-cli --cluster reshard <host>:<port> --cluster-from <node-id> --cluster-to <node-id> --cluster-slots <number of slots> --cluster-yes
• redis-cli -p 7000 cluster nodes 查看节点信息

测试故障转移

手动故障转移