广州市官网网站建设平台,企业网站关键词排名 s,.net 接单网站有哪些,签订网站制作协议需注意什么转自 极客时间
Redis主从架构 redis主从架构搭建#xff0c;配置从节点步骤#xff1a;
1、复制一份redis.conf文件2、将相关配置修改为如下值#xff1a;
port 6380
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile 6380.log
…转自 极客时间
Redis主从架构 redis主从架构搭建配置从节点步骤
1、复制一份redis.conf文件2、将相关配置修改为如下值
port 6380
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile 6380.log
dir /usr/local/redis-5.0.3/data/6380 # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1bind绑定的是自己机器网卡的ip如果有多块网卡可以配多个ip代表允许客户端通过机器的哪些网卡ip去访问内网一般可以不配置bind注释掉即可3、配置主从复制
replicaof 192.168.0.60 6379 # 从本机6379的redis实例复制数据Redis 5.0之前使用slaveof
replica-read-only yes # 配置从节点只读4、启动从节点
redis-server redis.conf # redis.conf文件务必用你复制并修改了之后的redis.conf文件5、连接从节点
redis-cli -p 63806、测试在6379实例上写数据6380实例是否能及时同步新修改数据7、可以自己再配置一个6381的从节点Redis主从工作原理
如果你为master配置了一个slave不管这个slave是否是第一次连接上Master它都会发送一个PSYNC命令给master请求复制数据。 master收到PSYNC命令后会在后台进行数据持久化通过bgsave生成最新的rdb快照文件持久化期间master会继续接收客户端的请求它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后master会把这份rdb文件数据集发送给slaveslave会把接收到的数据进行持久化生成rdb然后再加载到内存中。然后master再将之前缓存在内存中的命令发送给slave。 当master与slave之间的连接由于某些原因而断开时slave能够自动重连Master如果master收到了多个slave并发连接请求它只会进行一次持久化而不是一个连接一次然后再把这一份持久化的数据发送给多个并发连接的slave。
主从复制(全量复制)流程图
数据部分复制
当master和slave断开重连后一般都会对整份数据进行复制。但从redis2.8版本开始redis改用可以支持部分数据复制的命令PSYNC去master同步数据slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。 master会在其内存中创建一个复制数据用的缓存队列缓存最近一段时间的数据master和它所有的slave都维护了复制的数据下标offset和master的进程id因此当网络连接断开后slave会请求master继续进行未完成的复制从所记录的数据下标开始。如果master进程id变化了或者从节点数据下标offset太旧已经不在master的缓存队列里了那么将会进行一次全量数据的复制。
主从复制(部分复制断点续传)流程图 如果有很多从节点为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)可以做如下架构让部分从节点与从节点(与主节点同步)同步数据
Redis哨兵高可用架构 sentinel哨兵是特殊的redis服务不提供读写服务主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点后续就直接访问redis的主节点不会每次都通过sentinel代理访问redis的主节点当redis的主节点发生变化哨兵会第一时间感知到并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能订阅sentinel发布的节点变动消息)
redis哨兵架构搭建步骤
1、复制一份sentinel.conf文件
cp sentinel.conf sentinel-26379.conf2、将相关配置修改为如下值
port 26379
daemonize yes
pidfile /var/run/redis-sentinel-26379.pid
logfile 26379.log
dir /usr/local/redis-5.0.3/data
# sentinel monitor master-redis-name master-redis-ip master-redis-port quorum
# quorum是一个数字指明当有多少个sentinel认为一个master失效时(值一般为sentinel总数/2 1)master才算真正失效
sentinel monitor mymaster 192.168.0.60 6379 2 # mymaster这个名字随便取客户端访问时会用到3、启动sentinel哨兵实例
src/redis-sentinel sentinel-26379.conf4、查看sentinel的info信息
src/redis-cli -p 26379
127.0.0.1:26379info
可以看到Sentinel的info里已经识别出了redis的主从5、可以自己再配置两个sentinel端口26380和26381注意上述配置文件里的对应数字都要修改sentinel集群都启动完毕后会将哨兵集群的元数据信息写入所有sentinel的配置文件里去(追加在文件的最下面)我们查看下如下配置文件sentinel-26379.conf如下所示
sentinel known-replica mymaster 192.168.0.60 6380 #代表redis主节点的从节点信息
sentinel known-replica mymaster 192.168.0.60 6381 #代表redis主节点的从节点信息
sentinel known-sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵节点当redis主节点如果挂了哨兵集群会重新选举出新的redis主节点同时会修改所有sentinel节点配置文件的集群元数据信息比如6379的redis如果挂了假设选举出的新主节点是6380则sentinel文件里的集群元数据信息会变成如下所示
sentinel known-replica mymaster 192.168.0.60 6379 #代表主节点的从节点信息
sentinel known-replica mymaster 192.168.0.60 6381 #代表主节点的从节点信息
sentinel known-sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵节点同时还会修改sentinel文件里之前配置的mymaster对应的6379端口改为6380
sentinel monitor mymaster 192.168.0.60 6380 2当6379的redis实例再次启动时哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点加入集群
哨兵的Jedis连接代码
public class JedisSentinelTest {public static void main(String[] args) throws IOException {JedisPoolConfig config new JedisPoolConfig();config.setMaxTotal(20);config.setMaxIdle(10);config.setMinIdle(5);String masterName mymaster;SetString sentinels new HashSetString();sentinels.add(new HostAndPort(192.168.0.60,26379).toString());sentinels.add(new HostAndPort(192.168.0.60,26380).toString());sentinels.add(new HostAndPort(192.168.0.60,26381).toString());//JedisSentinelPool其实本质跟JedisPool类似都是与redis主节点建立的连接池//JedisSentinelPool并不是说与sentinel建立的连接池而是通过sentinel发现redis主节点并与其建立连接JedisSentinelPool jedisSentinelPool new JedisSentinelPool(masterName, sentinels, config, 3000, null);Jedis jedis null;try {jedis jedisSentinelPool.getResource();System.out.println(jedis.set(sentinel, zhuge));System.out.println(jedis.get(sentinel));} catch (Exception e) {e.printStackTrace();} finally {//注意这里不是关闭连接在JedisPool模式下Jedis会被归还给资源池。if (jedis ! null)jedis.close();}}
}哨兵的Spring Boot整合Redis连接代码见示例项目redis-sentinel-cluster 1、引入相关依赖
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactId
/dependencydependencygroupIdorg.apache.commons/groupIdartifactIdcommons-pool2/artifactId
/dependencyspringboot项目核心配置
server:port: 8080spring:redis:database: 0timeout: 3000sentinel: #哨兵模式master: mymaster #主服务器所在集群名称nodes: 192.168.0.60:26379,192.168.0.60:26380,192.168.0.60:26381lettuce:pool:max-idle: 50min-idle: 10max-active: 100max-wait: 1000
访问代码
RestController
public class IndexController {private static final Logger logger LoggerFactory.getLogger(IndexController.class);Autowiredprivate StringRedisTemplate stringRedisTemplate;/*** 测试节点挂了哨兵重新选举新的master节点客户端是否能动态感知到* 新的master选举出来后哨兵会把消息发布出去客户端实际上是实现了一个消息监听机制* 当哨兵把新master的消息发布出去客户端会立马感知到新master的信息从而动态切换访问的masterip** throws InterruptedException*/RequestMapping(/test_sentinel)public void testSentinel() throws InterruptedException {int i 1;while (true){try {stringRedisTemplate.opsForValue().set(zhugei, i);System.out.println(设置key zhuge i);i;Thread.sleep(1000);}catch (Exception e){logger.error(错误, e);}}}
}Redis集群方案比较
哨兵模式 高可用集群模式 Redis高可用集群搭建
redis集群搭建
redis集群需要至少三个master节点我们这里搭建三个master节点并且给每个master再搭建一个slave节 点总共6个redis节点这里用三台机器部署6个redis实例每台机器一主一从搭建集群的步骤如下:
第一步在第一台机器的/usr/local下创建文件夹redis-cluster然后在其下面分别创建2个文件夾如下
1mkdir -p /usr/local/redis-cluster
2mkdir 8001 8004第一步把之前的redis.conf配置文件copy到8001下修改如下内容
1daemonize yes
2port 8001分别对每个机器的端口号进行设置
3pidfile /var/run/redis_8001.pid # 把pid进程号写入pidfile配置的文件
4dir /usr/local/redis-cluster/8001/指定数据文件存放位置必须要指定不同的目录位置不然会丢失数据
5cluster-enabled yes启动集群模式
6cluster-config-file nodes-8001.conf集群节点信息文件这里800x最好和port对应上
7cluster-node-timeout 10000(8)# bind 127.0.0.1bind绑定的是自己机器网卡的ip如果有多块网卡可以配多个ip代表允许客户端通过机器的哪些网卡ip去访问内网一般可以不配置bind注释掉即可(9)protected-mode no 关闭保护模式(10)appendonly yes
如果要设置密码需要增加如下配置(11)requirepass zhuge (设置redis访问密码)(12)masterauth zhuge (设置集群节点间访问密码跟上面一致)第三步把修改后的配置文件copy到8004修改第2、3、4、6项里的端口号可以用批量替换
:%s/源字符串/目的字符串/g 第四步另外两台机器也需要做上面几步操作第二台机器用8002和8005第三台机器用8003和8006第五步分别启动6个redis实例然后检查是否启动成功
1/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/800*/redis.conf
2ps -ef | grep redis 查看是否启动成功第六步用redis-cli创建整个redis集群(redis5以前的版本集群是依靠ruby脚本redis-trib.rb实现)
# 下面命令里的1代表为每个创建的主服务器节点创建一个从服务器节点
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问可以先简单把所有机器防火墙关掉如果不关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W)
# 关闭防火墙
# systemctl stop firewalld # 临时关闭防火墙
# systemctl disable firewalld # 禁止开机启动
# 注意下面这条创建集群的命令大家不要直接复制里面的空格编码可能有问题导致创建集群不成功
1/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster create --cluster-replicas 1 192.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192.168.0.63:8006 第七步验证集群
1连接任意一个客户端即可./redis-cli -c -h -p (-a访问服务端密码-c表示集群模式指定ip地址和端口号如/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.61 -p 800*
2进行验证 cluster info查看集群信息、cluster nodes查看节点列表
3进行数据操作验证
4关闭集群则需要逐个进行关闭使用命令
/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.60 -p 800* shutdownJava操作redis集群
借助redis的java客户端jedis可以操作以上集群引用jedis版本的maven坐标如下
dependencygroupIdredis.clients/groupIdartifactIdjedis/artifactIdversion2.9.0/version
/dependencyJava编写访问redis集群的代码非常简单如下所示
public class JedisClusterTest {public static void main(String[] args) throws IOException {JedisPoolConfig config new JedisPoolConfig();config.setMaxTotal(20);config.setMaxIdle(10);config.setMinIdle(5);SetHostAndPort jedisClusterNode new HashSetHostAndPort();jedisClusterNode.add(new HostAndPort(192.168.0.61, 8001));jedisClusterNode.add(new HostAndPort(192.168.0.62, 8002));jedisClusterNode.add(new HostAndPort(192.168.0.63, 8003));jedisClusterNode.add(new HostAndPort(192.168.0.61, 8004));jedisClusterNode.add(new HostAndPort(192.168.0.62, 8005));jedisClusterNode.add(new HostAndPort(192.168.0.63, 8006));JedisCluster jedisCluster null;try {//connectionTimeout指的是连接一个url的连接等待时间//soTimeout指的是连接上一个url获取response的返回等待时间jedisCluster new JedisCluster(jedisClusterNode, 6000, 5000, 10, zhuge, config);System.out.println(jedisCluster.set(cluster, zhuge));System.out.println(jedisCluster.get(cluster));} catch (Exception e) {e.printStackTrace();} finally {if (jedisCluster ! null)jedisCluster.close();}}
}运行效果如下
OK
zhuge集群的Spring Boot整合Redis连接代码见示例项目redis-sentinel-cluster 1、引入相关依赖
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactId
/dependencydependencygroupIdorg.apache.commons/groupIdartifactIdcommons-pool2/artifactIdspringboot项目核心配置
server:port: 8080spring:redis:database: 0timeout: 3000password: zhugecluster:nodes: 192.168.0.61:8001,192.168.0.62:8002,192.168.0.63:8003,192.168.0.61:8004,192.168.0.62:8005,192.168.0.63:8006lettuce:pool:max-idle: 50min-idle: 10max-active: 100max-wait: 1000
访问代码
RestController
public class IndexController {private static final Logger logger LoggerFactory.getLogger(IndexController.class);Autowiredprivate StringRedisTemplate stringRedisTemplate;RequestMapping(/test_cluster)public void testCluster() throws InterruptedException {stringRedisTemplate.opsForValue().set(zhuge, 666);System.out.println(stringRedisTemplate.opsForValue().get(zhuge));}
}Redis集群原理分析
Redis Cluster 将所有数据划分为 16384 个 slots(槽位)每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。 当 Redis Cluster 的客户端来连接集群时它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况还需要纠正机制来实现槽位信息的校验调整。
槽位定位算法 Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值然后用这个整数值对 16384 进行取模来得到具体槽位。 HASH_SLOT CRC16(key) mod 16384
跳转重定位 当客户端向一个错误的节点发出了指令该节点会发现指令的 key 所在的槽位并不归自己管理这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作还会同步更新纠正本地的槽位映射表缓存后续所有 key 将使用新的槽位映射表。
Redis集群节点间的通信机制 gossip协议的优点在于元数据的更新比较分散不是集中在一个地方更新请求会陆陆续续打到所有节点上去更新有一定的延时降低了压力缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。
gossip通信的10000端口 每个节点都有一个专门用于节点间gossip通信的端口就是自己提供服务的端口号10000比如7001那么用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息同时其他几点接收到ping消息之后返回pong消息。
网络抖动 真实世界的机房网络往往并不是风平浪静的它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象突然之间部分连接变得不可访问然后很快又恢复正常。 为解决这种问题Redis Cluster 提供了一种选项cluster-node-timeout表示当某个节点持续 timeout 的时间失联时才可以认定该节点出现故障需要进行主从切换。如果没有这个选项网络抖动会导致主从频繁切换 (数据的重新复制)。
Redis集群选举原理分析
当slave发现自己的master变为FAIL状态时便尝试进行Failover以期成为新的master。由于挂掉的master可能会有多个slave从而存在多个slave竞争成为master节点的过程 其过程如下
slave发现自己的master变为FAIL将自己记录的集群currentEpoch加1并广播FAILOVER_AUTH_REQUEST 信息其他节点收到该信息只有master响应判断请求者的合法性并发送FAILOVER_AUTH_ACK对每一个epoch只发送一次ack尝试failover的slave收集master返回的FAILOVER_AUTH_ACKslave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点如果只有两个当其中一个挂了只剩一个主节点是不能选举成功的)slave广播Pong消息通知其他集群节点
从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举而是有一定延迟一定的延迟确保我们等待FAIL状态在集群中传播slave如果立即尝试选举其它masters或许尚未意识到FAIL状态可能会拒绝投票 •延迟计算公式 DELAY 500ms random(0 ~ 500ms) SLAVE_RANK * 1000ms•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下持有最新数据的slave将会首先发起选举理论上。
集群脑裂数据丢失问题
redis集群没有过半机制会有脑裂问题网络分区导致脑裂后多个主节点对外提供写服务一旦网络分区恢复会将其中一个主节点变为从节点这时会有大量数据丢失。 规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失参考集群leader选举机制)
min-slaves-to-write 1 //写数据成功最少同步的slave数量这个数量可以模仿大于半数机制配置比如集群总共三个节点可以配置1加上leader就是2超过了半数该参数在redis最新版本里名字已经换成了min-replicas-to-write注意这个配置在一定程度上会影响集群的可用性比如slave要是少于1个这个集群就算leader正常也不能提供服务了需要具体场景权衡选择。
集群是否完整才能对外提供服务
当redis.conf的配置cluster-require-full-coverage为no时表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时集群仍然可用如果为yes则集群不可用。
Redis集群为什么至少需要三个master节点并且推荐节点数为奇数
因为新master的选举需要大于半数的集群master节点同意才能选举成功如果只有两个master节点当其中一个挂了是达不到选举新master的条件的。 奇数个master节点可以在满足选举该条件的基础上节省一个节点比如三个master节点和四个master节点的集群相比大家如果都挂了一个master节点都能选举新master节点如果都挂了两个master节点都没法选举新master节点了所以奇数的master节点更多的是从节省机器资源角度出发说的。
Redis集群对批量操作命令的支持
对于类似msetmget这样的多个key的原生批量操作命令redis集群只支持所有key落在同一slot的情况如果有多个key一定要用mset命令在redis集群上操作则可以在key的前面加上{XX}这样参数数据分片hash计算的只会是大括号里的值这样能确保不同的key能落到同一slot里去示例如下
mset {user1}:1:name zhuge {user1}:1:age 18假设name和age计算的hash slot值不一样但是这条命令在集群下执行redis只会用大括号里的 user1 做hash slot计算所以算出来的slot值肯定相同最后都能落在同一slot。
哨兵leader选举流程
当一个master服务器被某sentinel视为下线状态后该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期)每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作从存活的slave中选举出新的master这个选举过程跟集群的master选举很类似。 哨兵集群只有一个哨兵节点redis的主从也能正常运行以及选举master如果master挂了那唯一的那个哨兵节点就是哨兵leader了可以正常选举新master。 不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。
Redis高可用集群之水平扩展
Redis3.0以后的版本虽然有了集群功能提供了比之前版本的哨兵模式更高的性能与可用性但是集群的水平扩展却比较麻烦今天就来带大家看看redis高可用集群如何做水平扩展原始集群(见下图)由6个节点组成6个节点分布在三台机器上采用三主三从的模式
1、启动集群
启动整个集群
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8001/redis.conf
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8002/redis.conf
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8003/redis.conf
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8004/redis.conf
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8005/redis.conf
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8006/redis.conf#客户端连接8001端口的redis实例
/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.61 -p 8001#查看集群状态
192.168.0.61:8001 cluster nodes从上图可以看出整个集群运行正常三个master节点和三个slave节点8001端口的实例节点存储0-5460这些hash槽8002端口的实例节点存储5461-10922这些hash槽8003端口的实例节点存储10923-16383这些hash槽这三个master节点存储的所有hash槽组成redis集群的存储槽位slave点是每个主节点的备份从节点不显示存储槽位
2、集群操作
我们在原始集群基础上再增加一主(8007)一从(8008)增加节点后的集群参见下图新增节点用虚线框表示
增加redis实例 #在/usr/local/redis-cluster下创建8007和8008文件夹并拷贝8001文件夹下的redis.conf文件到8007和8008这两个文件夹下
mkdir 8007 8008
cd 8001
cp redis.conf /usr/local/redis-cluster/8007/
cp redis.conf /usr/local/redis-cluster/8008/# 修改8007文件夹下的redis.conf配置文件
vim /usr/local/redis-cluster/8007/redis.conf
# 修改如下内容
port:8007
dir /usr/local/redis-cluster/8007/
cluster-config-file nodes-8007.conf# 修改8008文件夹下的redis.conf配置文件
vim /usr/local/redis-cluster/8008/redis.conf
修改内容如下
port:8008
dir /usr/local/redis-cluster/8008/
cluster-config-file nodes-8008.conf# 启动8007和8008俩个服务并查看服务状态
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8007/redis.conf
/usr/local/redis-5.0.3/src/redis-server /usr/local/redis-cluster/8008/redis.conf
ps -el | grep redis查看redis集群的命令帮助
cd /usr/local/redis-5.0.3
src/redis-cli --cluster help1.create创建一个集群环境host1:port1 … hostN:portN 2.call可以执行redis命令 3.add-node将一个节点添加到集群里第一个参数为新节点的ip:port第二个参数为集群中任意一个已经存在的节点的ip:port 4.del-node移除一个节点 5.reshard重新分片 6.check检查集群状态
配置8007为集群主节点 #使用add-node命令新增一个主节点8007(master)前面的ip:port为新增节点后面的ip:port为已知存在节点看到日志最后有[OK] New node added correctly提示代表新节点加入成功
/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster add-node 192.168.0.61:8007 192.168.0.61:8001#查看集群状态
/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.61 -p 8001
192.168.0.61:8001 cluster nodes注意当添加节点成功以后新增的节点不会有任何数据因为它还没有分配任何的slot(hash槽)我们需要为新节点手工分配hash槽 #使用redis-cli命令为8007分配hash槽找到集群中的任意一个主节点对其进行重新分片工作。
/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster reshard 192.168.0.61:8001#查看下最新的集群状态
/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.61 -p 8001
192.168.0.61:8001 cluster nodes如上图所示现在我们的8007已经有hash槽了也就是说可以在8007上进行读写数据啦到此为止我们的8007已经加入到集群中并且是主节点(Master)
配置8008为8007的从节点 #添加从节点8008到集群中去并查看集群状态
/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster add-node 192.168.0.61:8008 192.168.0.61:8001如图所示还是一个master节点没有被分配任何的hash槽。 #我们需要执行replicate命令来指定当前节点(从节点)的主节点id为哪个,首先需要连接新加的8008节点的客户端然后使用集群命令进行操作把当前的8008(slave)节点指定到一个主节点下(这里使用之前创建的8007主节点)
/usr/local/redis-5.0.3/src/redis-cli -a zhuge -c -h 192.168.0.61 -p 8008
192.168.0.61:8008 cluster replicate 2728a594a0498e98e4b83a537e19f9a0a3790f38 #后面这串id为8007的节点id#查看集群状态8008节点已成功添加为8007节点的从节点 删除8008从节点 #用del-node删除从节点8008指定删除节点ip和端口以及节点id(红色为8008节点id)
/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster del-node 192.168.0.61:8008 a1cfe35722d151cf70585cee21275565393c0956#再次查看集群状态如下图所示8008这个slave节点已经移除并且该节点的redis服务也已被停止 删除8007主节点 最后我们尝试删除之前加入的主节点8007这个步骤相对比较麻烦一些因为主节点的里面是有分配了hash槽的所以我们这里必须先把8007里的hash槽放入到其他的可用主节点中去然后再进行移除节点操作不然会出现数据丢失问题(目前只能把master的数据迁移到一个节点上暂时做不了平均分配功能)执行命令如下
/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster reshard 192.168.0.61:8007至此我们已经成功的把8007主节点的数据迁移到8001上去了我们可以看一下现在的集群状态如下图你会发现8007下面已经没有任何hash槽了证明迁移成功 #最后我们直接使用del-node命令删除8007主节点即可
/usr/local/redis-5.0.3/src/redis-cli -a zhuge --cluster del-node 192.168.0.61:8007 2728a594a0498e98e4b83a537e19f9a0a3790f38#查看集群状态一切还原为最初始状态啦大功告成
