Redis Cluster采用虚拟槽分区,全部的键根据哈希函数映射到0~16383整数槽内,计算公式:slot=CRC16(key)&16383。槽是集群内数据管理和迁移的基本单位。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每一个节点会负责必定数据的槽,以下图所示:node
当集群有5个节点,每一个节点平均大约负载3276个槽。因为采用高质量的哈希算法,每一个槽所映射的数据一般比较均匀,将数据平均划分到5个节点进行数据分区。每个节点负责维护一部分槽以及槽所映射的键值数据,以下图所示:redis
Redis虚拟槽分区的特色:算法
解耦数据和节点之间的关系,简化了节点扩容和收缩难度。数据库
节点自身维护槽的映射关系,不须要客户端或者代理服务维护槽分区元数据。bash
支持节点、槽、键之间的映射查询,用于数据路由、在线伸缩等场景。并发
数据分区是分布式存储的核心,理解和灵活运用数据分区规则对于掌握Redis Cluster很是有帮助。运维
集群功能限制异步
Redis集群相对单机的功能上存在一些限制,须要开发人页提早了解,在使用时作好规避。限制以下:分布式
1)key批量操做支持有限。如mset、mget,目前只支持具备相同slot值的key执行批量操做。对于映射为不一样slot值的key因为执行mget、mset等操做可能存在于多个节点上所以不被支持。ide
2)key事务操做支持有限。同理只支持多key在同一节点上的事务操做,当多个key分布在不一样的节点上时没法使用事务功能。
3)key做为数据分区的最小粒度,所以不能将一个大的键值对象如hash、list等映射到不一样的节点。
4)不支持多数据库空间。单机下的Redis能够支持16个数据库,集群模式下只能使用一个数据库空间,即db0。
5)复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。
搭建集群
下面开始搭建集群工做,须要如下三个步骤:
1)准备节点
2)节点握手
3)分配槽
准备节点
节点规划,使用三台机器,第台机器上部署两个Redis实例,分别为一主一从。
redis_1 192.168.56.120 redis_2 192.168.56.121 redis_3 192.168.56.122
Redis集群通常由多个节点组成,节点数据至少为6个才能保证组成完整高可用的集群。每一个节点须要开启配置cluster-enabled yes,让Redis运行在集群模式下。建议为集群内全部节点统一目录,通常划分三个目录:conf、data、log,分别存放配置、数据和日志相关文件。把6个节点配置统一放在conf目录下,集群相关配置以下:
#节点端口 port 6379 #开启集群模式 cluster-enabled yes #节点超时时间,单位毫秒 cluster-node-timeout 15000 #集群内部配置文件 cluster-config-file "nodes-6379.conf"
其余配置和单机模式一致便可,配置文件命名规则redis-{port}.conf,准备好配置后启动全部节点,命令以下:
#redis_1 redis-server conf/redis-6379.conf & redis-server conf/redis-6380.conf & #redis_2 redis-server conf/redis-6379.conf & redis-server conf/redis-6380.conf & #redis_3 redis-server conf/redis-6379.conf & redis-server conf/redis-6380.conf &
检查节点是日志是否正确,内容以下
5200:M 05 Apr 11:28:18.931 * No cluster configuration found, I'm 383261e3f0053f74c953bd07ceee36a4b5795bc3 ...... Redis 4.0.13 (00000000/0) 64 bit Running in cluster mode Port: 6380 PID: 5200 ....... 5200:M 05 Apr 11:28:18.943 * Ready to accept connections
redis_1上的6379节点启动成功,第一次启动时若是没有集群配置文件,它会自动建立一份,文件名称采用cluster-config-file参数项控制,建议采用node-{port}.conf格式定义,经过使用端口号区分不一样节点,防止同一机器下多个节点彼此覆盖,形成集群信息异常。若是启动时存在集群配置文件,节点会使用配置文件内容初始化集群信息,启动过程以下图:
集群模式的Redis除了原有的配置文件以外又加了一份集群配置文件。当集群节点信息发生变化,如添加节点、节点下线、故障转移等。节点会自动保存集群状态到配置文件中。须要注意的是,Redis自动维护集群配置文件,不要手动修改,防止节点重启时产生集群信息错乱。
如redis_3的6379实例首次启动后生成集群配置以下:
[redis@redis_3 ~]$ cat data/nodes-6379.conf
275753d11365feabb366170b940bca4b8486bbd7 :0@0 myself,master - 0 0 0 connected
vars currentEpoch 0 lastVoteEpoch 0
文件内容记录了集群初始状态,这里最重要的是节点ID,它是一个40位16进制字符串,用于标准集群内一个节点,以后不少集群操做都要借助于节点ID来完成。须要注意的是,节点IDeas不一样于运行IDeas。节点IDeas在集群初始化时只建立一次,节点重启时会加载集群配置文件进行重用,而Redis的运行IDeas每次重启都 会变化。在redis_3的6379节点上执行cluster nodes命令获取集群节点状态:
127.0.0.1:6380> cluster nodes
d54639285709a65bb8ca331f26d4fe1b1c8c73ca :6380@16380 myself,master - 0 0 0 connected
每一个节点目前只能识别出本身的节点信息。咱们启动6个节点,但每一个节点彼此不知道对方的存在,下面经过节点握手让6个节点彼此建议联系从而组成一个集群。
节点握手
节点握手是批一批运行在集群模式下的节点经过Gossip协议彼此通讯,达到感知对方的过程。节点握手是集群彼此通讯的第一步,由客户端发起命令:cluster meet {ip} {port},以下图所示
图中执行的命令是:cluster meet 127.0.0.1 6380让节点6379和6380进行握手通讯。cluster meet命令是一个异步命令,执行以后马上返回。内部发起与目标节点进行握手通讯,如图所示
1)节点6379本地建立6380节点信息对象,并发送meet消息。
2)节点6380接受到meet消息后,保存6379节点信息并回复pong消息。
3)以后节点6379和6380彼此按期经过ping/pong消息进行正常的节点通讯。
这里的meet、ping、pong消息是Gossip协议通讯的载体,以后的节点通讯部分作进一步介绍,它的主要做用是节点彼此交换状态数据信息。6379和6380节点经过meet命令彼此建议通讯以后集群结构如图:
执行完cluster meet后,能够经过cluster nodes看到两个实例都检查到了对方的存在
[redis@redis_1 ~]$ redis-cli -h redis_1 -p 6379 redis_1:6379> cluster meet 192.168.56.120 6380 OK redis_1:6379> cluster nodes 383261e3f0053f74c953bd07ceee36a4b5795bc3 192.168.56.120:6380@16380 master - 0 1554440139158 1 connected ceaf2ccb751978b7334ddeca474da3d6b7aac99b 192.168.56.120:6379@16379 myself,master - 0 0 0 connected redis_1:6379> exit [redis@redis_1 ~]$ redis-cli -h redis_1 -p 6380 redis_1:6380> cluster nodes ceaf2ccb751978b7334ddeca474da3d6b7aac99b 192.168.56.120:6379@16379 master - 0 1554440152934 0 connected 383261e3f0053f74c953bd07ceee36a4b5795bc3 192.168.56.120:6380@16380 myself,master - 0 0 1 connected redis_1:6380>
使用以下命令把其余节点加入集群,只须要在集群内任意节点执行cluster meet命令加入新节点,握手状态会经过消息在集群内传播,这样其余节点会自动发现新节点并发起握手流程。最后执行cluster nodes命令确认6个节点都彼此感知并组成了集群:
[redis@redis_1 ~]$ redis-cli -h redis_1 -p 6379 redis_1:6379> cluster meet 192.168.56.121 6379 OK redis_1:6379> cluster meet 192.168.56.121 6380 OK redis_1:6379> cluster meet 192.168.56.122 6379 OK redis_1:6379> cluster meet 192.168.56.122 6380 OK redis_1:6379> cluster nodes 275753d11365feabb366170b940bca4b8486bbd7 192.168.56.122:6379@16379 master - 0 1554440316783 4 connected 383261e3f0053f74c953bd07ceee36a4b5795bc3 192.168.56.120:6380@16380 master - 0 1554440316000 1 connected ceaf2ccb751978b7334ddeca474da3d6b7aac99b 192.168.56.120:6379@16379 myself,master - 0 1554440315000 5 connected d54639285709a65bb8ca331f26d4fe1b1c8c73ca 192.168.56.122:6380@16380 master - 0 1554440316000 0 connected ca4f05809dc9a9eda4292a33b994b4e2aab13033 192.168.56.121:6380@16380 master - 0 1554440317000 3 connected a85bbb17a3f559d18d7f5059f14ffd9f6ba48ee1 192.168.56.121:6379@16379 master - 0 1554440315000 2 connected
握手完成后集群的状态以下图:
节点建议握手以后集群还不能正常工做,这里集群处理下线状态,全部的数据读写都被禁止。经过以下命令能够看到:
redis_2:6379> set hello world (error) CLUSTERDOWN Hash slot not served
经过cluster info 命令能够获取集群当前状态:
redis_2:6379> cluster info cluster_state:fail cluster_slots_assigned:0 cluster_slots_ok:0 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:0 cluster_current_epoch:5 cluster_my_epoch:2 cluster_stats_messages_ping_sent:315 cluster_stats_messages_pong_sent:314 cluster_stats_messages_meet_sent:3 cluster_stats_messages_sent:632 cluster_stats_messages_ping_received:312 cluster_stats_messages_pong_received:318 cluster_stats_messages_meet_received:2 cluster_stats_messages_received:632
从输出内容能够看到,被分配的槽(cluster_slots_assigned)是0,因为目前全部的槽没有分配节点,所以集群没法完成槽到节点的映射。只有当16384个槽所有分配给节点后,集群才进入在线状态。
分配槽
Redis集群把全部的数据映射到16384个槽中。每一个key会映射为一个固定的槽,只有当节点分配了槽,才响应和这些槽相关联的键命令。经过cluster addslots命令为节点分配槽。这些利用bash特性批量设置槽(slots),命令以下:
[redis@redis_1 ~]$ redis-cli -h redis_1 -p 6379 cluster addslots {0..5461} OK [redis@redis_1 ~]$ redis-cli -h redis_2 -p 6379 cluster addslots {5462..10922} OK [redis@redis_1 ~]$ redis-cli -h redis_3 -p 6379 cluster addslots {10923..16383} OK
把16384个slot平均分配给redis_1/2/3的6379三个节点。执行cluster info查看集群状态以下所示:
[redis@redis_1 ~]$ redis-cli -h redis_2 -p 6379 cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:5 cluster_my_epoch:2 cluster_stats_messages_ping_sent:1062 cluster_stats_messages_pong_sent:1067 cluster_stats_messages_meet_sent:3 cluster_stats_messages_sent:2132 cluster_stats_messages_ping_received:1065 cluster_stats_messages_pong_received:1065 cluster_stats_messages_meet_received:2 cluster_stats_messages_received:2132
当前集群状态是OK,集群进入在线状态。全部的槽都已经分配给节点,执行cluster nodes命令能够看到节点和槽的分配关系:
[redis@redis_1 ~]$ redis-cli -h redis_2 -p 6379 cluster nodes a85bbb17a3f559d18d7f5059f14ffd9f6ba48ee1 192.168.56.121:6379@16379 myself,master - 0 1554441448000 2 connected 5462-10922 ceaf2ccb751978b7334ddeca474da3d6b7aac99b 192.168.56.120:6379@16379 master - 0 1554441448455 5 connected 0-5461 ca4f05809dc9a9eda4292a33b994b4e2aab13033 192.168.56.121:6380@16380 master - 0 1554441449000 3 connected 383261e3f0053f74c953bd07ceee36a4b5795bc3 192.168.56.120:6380@16380 master - 0 1554441450000 1 connected d54639285709a65bb8ca331f26d4fe1b1c8c73ca 192.168.56.122:6380@16380 master - 0 1554441450491 0 connected 275753d11365feabb366170b940bca4b8486bbd7 192.168.56.122:6379@16379 master - 0 1554441449470 4 connected 10923-16383
目前还有三个节点没有使用,做为一个完整的集群,每一个负责处理槽的节点应该具备从节点,保证当它出现故障时能够自动进行故障转移。集群模式下,Redis节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点,从节点负责复制主节点槽信息和相关的数据。使用cluster replicate {nodeID}命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行,nodeID是要复制主节点的节点ID,命令以下:
[redis@redis_1 ~]$ redis-cli -h redis_1 -p 6380 cluster replicate a85bbb17a3f559d18d7f5059f14ffd9f6ba48ee1 OK [redis@redis_1 ~]$ redis-cli -h redis_2 -p 6380 cluster replicate 275753d11365feabb366170b940bca4b8486bbd7 OK [redis@redis_1 ~]$ redis-cli -h redis_3 -p 6380 cluster replicate ceaf2ccb751978b7334ddeca474da3d6b7aac99b OK
复制(replication)完成后,整个集群的结构如图
到此为止,咱们依照Redis协议手动创建一个集群。它由6个节点构成,3个主节点负责处理槽和相关数据,3个从节点负责故障转移。
博文内容主要参考《Redis开发与运维》一书。