redis 高可用及集群三种模式
redis高可用
持久化
RDB持久化
RBD持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘（也称为快照持久化），用二进制压缩保存，保存的文件后缀时rdb：当Redis重新启动时，可以读取快照文件恢复数据
[root@localhost ~]# vim /etc/redis/6379.conf
251 rdbchecksum yes //开启RDB文件压缩
254 dbfilename dump.rdb //指定RDB文件名
264 dir /var/lib/redis/6379 //指定RDB和AOF所在目录
触发条件
- 1.手动触发
save命令和bgsave命令都可以生成RDB文件
[root@localhost ~]# redis-cli //进入数据库
127.0.0.1:6379> bgsave //手动执行
Background saving started
127.0.0.1:6379>
[root@localhost ~]# ls /var/lib/redis/6379/
dump.rdb //RDB文件
- 2.自动触发
自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化
在配置文件中通过save m n，指定当m s内发生n次变化，会触发bgsave
在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave，并将rdb文件发送给从节点
执行shutdown命令时，自动执行rdb持久化
[root@localhost ~]# vim /etc/redis/6379.conf
219 save 900 1 //900秒内至少发生一次变化，执行bgsave
220 save 300 10 //300秒内至少发生10次变化，执行bgsave
221 save 60 10000 //60秒内至少发生10000次变化，执行bgsave
执行流程
- Redis父进程首先判断：当前是否在执行save或bgsave的子进程，如果在则bgsave命令直接返回；bgsave/bgrewriteaof的子进程不能同时执行
- 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
- 父进程fork后，bgsave命令返回“Backgroud saveing started”信息并不在阻塞父进程，并可以响应其他命令
- 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
- 子进程发送信号给父进程表示完成，父进程更新统计信息
启动时加载
- 在服务器中，仅当AOF功能关闭，才会载入RDB文件
- 启动过程中进行持久化文件的检测校验，若损坏，则打印错误，启动失败
AOF持久化
RDB持久化是将数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录
开启AOF
[root@localhost ~]# vim /etc/redis/6379.conf
700 appendonly yes //手动开启AOF
701
702 # The name of the append only file (default: "appendonly.aof")
703
704 appendfilename "appendonly.aof" //指定AOF文件名
796 aof-load-truncated yes //忽略此条可能出现问题
[root@localhost ~]# vim /etc/redis/6379.conf
[root@localhost ~]# /etc/init.d/redis_6379 restart //重启使配置文件生效
执行流程
- 命令追加：将Redis的写命令追加到缓冲区aof_buf
- 文件写入和文件同步：根据不同的同步策略将aof_buf的内容同步到硬盘
- 文件重写：定期重写AOF文件，以达到压缩的目的
启动时加载
- 当AOF开启时，Redis启动会优先载入AOF文件来恢复数据；当AOF开启时，但AOF文件不存在，即使RDB文件存在也不会加载。
- Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，但是如果是AOF文件结尾不完整，切aof-load-treuncated开启，则会忽略尾部，启动成功
Redis 集群三种模式
Redis 集群三种模式介绍
- 主从复制
redis高可用的基础，实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
缺陷:故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。
哨兵模式
基于主从复制模式，实现了自动化的故障恢复
缺陷：写操作无法负载均衡、存储能力受到单机的限制。
cluster集群模式
通过Redis集群解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
Redis 集群三种模式原理
Redis安装部署
环境
master 192.168.233.103
slave1 192.168.233.104
slave2 192.168.233.105
三台主机同时进行
安装依赖包
[root@localhost ~]# yum -y install gcc gcc-c++ make
安装redis
[root@slave1 opt]# wget -P /opt http://download.redis.io/releases/redis-5.0.9.tar.gz
解压
[root@slave1 opt]# tar -xzvf redis-5.0.9.tar.gz
编译安装
[root@slave1 redis-5.0.9]# make && make PREFIX=/usr/local/redis install
配置项设置
[root@slave1 redis-5.0.9]# cd utils/
[root@slave1 utils]# ./install_server.sh
优化管理路径
[root@slave1 utils]# ln -s /usr/local/redis/bin/* /usr/local/bin/
[root@slave1 utils]# netstat -napt | grep 6379
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 6969/redis-server 1
1.主从复制
1.流程
第一步：slave服务器向master服务器发送sync_command命令，请求同步数据
第二步：master接收到sync_command后使用fork函数派生一个子进程（此过程会阻塞子进程），用于生成RDB文件，并且把客户端执行的写命令保存在缓冲区中，再保存到aof文件中
第三步：master RDB持久化完成之后，将生成的RDB和AOF文件发送给slave
第四步：slave恢复RDB和AOF文件中的数据
第五步：master持续性的将客户端写入的命令以一定的规则同步给slave
实验
关闭防火墙，同步时间
[root@slave1 utils]# systemctl stop firewalld
[root@slave1 utils]# setenforce 0
[root@slave1 utils]# ntpdate ntp.aliyun.com
修改配置文件
master
[root@master utils]# vim /etc/redis/6379.conf
//定位70行，修改监听地址为：0.0.0.0
70 bind 0.0.0.0
//定位137行，开启守护进程
137 daemonize yes
//定位172行，指定日志文件目录
172 logfile "/var/log/redis_6379.log"
//定位264行，指定工作目录
264 dir "/var/lib/redis/6379"
//定位700行，开启AOF持久化
700 appendonly yes
[root@master utils]# systemctl restart redis_6379
slaves
[root@slave1 utils]# vim /etc/redis/6379.conf
//和master基本一致，只需要多添加一条信息
//定位288行，指定需要同步的master服务器的IP+端口
288 replicaof 192.168.177.130 6379
[root@slave1 utils]# systemctl restart redis_6379
查看主从同步是否成功
在master节点上使用 redis-cli info replication 命令
[root@master utils]# redis-cli info replication
# Replication
role:master //角色是master
connected_slaves:2 //从服务器数量2
slave0:ip=192.168.233.104,port=6379,state=online,offset=28,lag=0 //从服务的IP+端口及偏移量
slave1:ip=192.168.233.105,port=6379,state=online,offset=28,lag=0
master_replid:dabc7652858102cb4f9fe5fb753f787df53e5928 //master启动时生成的40位16进制的随机字符串，用来标识master节点
master_replid2:0000000000000000000000000000000000000000 //切换主从的时候master节点标识会有更改
master_repl_offset:28 //偏移量，相当于MySQL主从同步中的position
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28
在master创建新的库
[root@master utils]# redis-cli
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set k1 1
OK
从服务器查看
[root@slave1 utils]# redis-cli
127.0.0.1:6379> keys *
1) "k1"
127.0.0.1:6379> get k1
"1"
2.哨兵模式
哨兵模式主要功能：
- ① 集群监控:负责监控Redis 主 和 备 进程是否正常工作
- ② 消息通知:如果某个Redis实例有故障，那么哨兵负责发送消息作为告警通知给管理员
- ③ 故障转移:如果 主节点 挂掉了，会自动转移到 备节点 上
- ④ 配置中心:如果故障转移发生了，通知客户端新的master地址
实现步骤：
步骤一：在所有哨兵节点上配置master节点
步骤二：哨兵节点会和配置的主节点建立起两条连接①命令连接、②订阅连接
步骤三：哨兵会通过命令连接周期性（间隔10秒）发送一次info命令，通过info命令，主节点会返回自己的run_id和自己的从节点信息；哨兵通过获取的从节点信息，也会对从节点建立起两条连接：命令连接 和 订阅连接，执行相同的操作。
步骤四：主从节点通过命令连接向哨兵服务器的hello频道发送一条消息，内容包括自己的ip端口、run_id、配置等,用于后续投票使用
步骤五：哨兵集群通过订阅连接对哨兵服务器的hello频道进行监听，所有向该频道发送的消息都能被所有哨兵服务器接受到
步骤六：哨兵集群中每一台哨兵都解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来
步骤七：哨兵集群中每一台哨兵都向观察到的其他的哨兵节点建立命令连接（用于投票），没有订阅连接
哨兵模式下的故障迁移
- 主观下线：哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的主节点发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/LOADING/MASTERDOWN)，哨兵就会将该主节点在本结构体中的状态标记为SRI_S_DOWN主观下线
- 客观下线：当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRI_O_DOWN客观下线。询问命令sentinel is-master-down-by-addr
- master选举：在认为主节点客观下线的情况下，哨兵节点之间会发起一次选举，命令为:sentinel is-master-down-by-addr 只是run_id这次会将自己的run_id带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为leacer的情况下，将由该leader对故障进行迁移
实验
实验环境：（基于以上的主从同步增加三台哨兵服务器）
sentinel-01：192.168.233.101
sentinel-02：192.168.233.102
sentinel-03：192.168.233.106
关闭防火墙、同步时间
[root@sentinel-01 ~]# ntpdate ntp.aliyun.com
[root@sentinel-01 ~]# systemctl stop firewalld
[root@sentinel-01 ~]# setenforce 0
安装好redis
修改配置文件
修改所有哨兵配置文件
//定位17行，关闭保护
17 protected-mode no
//定位21行，是哨兵默认的监听端口不用修改
21 port 26379
//定位26行，开启守护进程
26 daemonize yes
//定位36行，指定日志存放路径
36 logfile "/var/log/sentinel.log"
//定位65行，指定数据库存放路径
65 dir "/var/lib/redis/6379"
//定位84行，指定哨兵节点监控的master节点的IP+端口 2表示至少需要 2 个哨兵节点同意，才能判定主节点故障并进行
84 sentinel monitor mymaster 192.168.233.103 6379 2
//定位113行，判定服务器down掉的时间周期，默认30000毫秒 (30秒 )
113 sentinel down-after-milliseconds mymaster 3000
//定位146行，故障节点的最大超时时间为180000 (180秒)
146 sentinel failover-timeout mymaster 180000
启动哨兵并查看监控信息
[root@sentinel-01 utils]# cd /opt/redis-5.0.9/
[root@sentinel-01 redis-5.0.9]# redis-sentinel sentinel.conf
[root@sentinel-01 redis-5.0.9]# netstat -antp | grep 26379
tcp 0 0 0.0.0.0:26379 0.0.0.0:* LISTEN 12341/redis-sentine
tcp 0 0 192.168.233.101:26379 192.168.233.102:51674 ESTABLISHED 12341/redis-sentine
tcp 0 0 192.168.233.101:38356 192.168.233.106:26379 ESTABLISHED 12341/redis-sentine
tcp 0 0 192.168.233.101:26379 192.168.233.106:32804 ESTABLISHED 12341/redis-sentine
tcp 0 0 192.168.233.101:60032 192.168.233.102:26379 ESTABLISHED 12341/redis-sentine
tcp6 0 0 :::26379 :::* LISTEN 12341/redis-sentine
查看哨兵监控的信息
[root@sentinel-01 redis-5.0.9]# redis-cli -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.233.103:6379,slaves=2,sentinels=3
在主从复制的master节点上模拟故障
[root@master utils]# netstat -antp | grep 6379
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.105:46521 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.106:53302 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.102:39780 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.101:33322 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.102:39782 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.104:44112 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.106:53304 ESTABLISHED 8511/redis-server 0
tcp 0 0 192.168.233.103:6379 192.168.233.101:33324 ESTABLISHED 8511/redis-server 0
[root@master utils]# kill -9 8511
在哨兵上监控sentinel.log日志文件查看master切换变化
[root@sentinel-02 redis-5.0.9]# tail -f /var/log/sentinel.log
6963:X 12 Aug 2021 01:25:58.300 # +sdown master mymaster 192.168.233.103 6379 //哨兵发现master挂了，主观判断master挂了
6963:X 12 Aug 2021 01:25:58.386 # +new-epoch 1
6963:X 12 Aug 2021 01:25:58.389 # +vote-for-leader ce40b282d9f2d4191ad33f994c91e8217c357cd9 1 //选举出哨兵的领导
6963:X 12 Aug 2021 01:25:58.390 # +odown master mymaster 192.168.233.103 6379 #quorum 3/2 超过半数哨兵认为master挂了--客观判断master挂了
6963:X 12 Aug 2021 01:25:58.390 # Next failover delay: I will not start a failover before Thu Aug 12 01:31:58 2021
6963:X 12 Aug 2021 01:25:59.484 # +config-update-from sentinel ce40b282d9f2d4191ad33f994c91e8217c357cd9 192.168.233.101 26379 @ mymaster 192.168.233.103 6379 //选举出的哨兵领导对故障节点进行故障转移
6963:X 12 Aug 2021 01:25:59.484 # +switch-master mymaster 192.168.233.103 6379 192.168.233.105 6379 //将从节点192.168.233.105提升为新的master
6963:X 12 Aug 2021 01:25:59.485 * +slave slave 192.168.233.104:6379 192.168.233.104 6379 @ mymaster 192.168.233.105 6379
6963:X 12 Aug 2021 01:25:59.485 * +slave slave 192.168.233.103:6379 192.168.233.103 6379 @ mymaster 192.168.233.105 6379
6963:X 12 Aug 2021 01:26:29.576 # +sdown slave 192.168.233.103:6379 192.168.233.103 6379 @ mymaster 192.168.233.105 6379 //将原来的master降为slave
在故障切换过程中，status的状态会经过 sdown——》odown——》ok，可以使用 watch -n 1 redis-cli -p 26379 info sentinel 命令间隔一秒查看
再次查看master节点信息
[root@sentinel-01 redis-5.0.9]# redis-cli -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.233.105:6379,slaves=2,sentinels=3 //master变为105
测试105节点
[root@slave2 utils]# redis-cli
127.0.0.1:6379> set k2 2
OK
//104节点查看
[root@slave1 utils]# redis-cli
127.0.0.1:6379> keys *
1) "k1"
2) "k2"
127.0.0.1:6379> get k2
"2"
3.cluster 集群模式
主节点负责读写请求和集群信息的维护，从节点只进行主节点数据和状态信息的复制
作用
-
数据分区
数据分区（或称数据分片）是集群最核心的功能（分布式）
集群将数据分散到多个节点，一方面突破了 Redis 单机内存大小的限制，存储容量大大增加，另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力
Redis 单机内存大小受限问题，在介绍持久化和主从复制时都有提及，例如，如果单机内存太大，bgsave 和 bgrewriteaof 的 fork 操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出 -
高可用
集群支持主从复制（模式）和主节点的自动故障转移（与哨兵类似），当任意节点发送故障时，集群仍然可以对外提供服务 -
数据分片
Redis 集群引入了哈希槽的概念，有 16384 个哈希槽（编号 0~16383）集群的每个节点负责一部分哈希槽，每个 Key 通过 CRC16 校验后对 16384 取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作
实验
实验环境
//三主
cluster1：192.168.233.101
cluster2：192.168.177.102
cluster3：192.168.177.103
//三从
cluster4：192.168.177.104
cluster5：192.168.177.105
cluster6：192.168.177.106
安装redis
[root@cluster01 opt]# tar -xzvf redis-5.0.7.tar.gz
[root@cluster01 opt]# cd redis-5.0.7/
[root@cluster01 redis-5.0.7]# make && make prefix=/usr/local/redis install
[root@cluster01 redis-5.0.7]# cd utils/
[root@cluster01 utils]# ./install_server.sh
//回车，直到出现Please select the redis executable path [/usr/local/bin/redis-server]，手动修改为“/usr/local/redis/bin/redis-server”
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
[root@cluster01 utils]# ln -s /usr/local/redis/bin/* /usr/local/bin/
** 创建6个节点的工作目录**
[root@cluster01 utils]# cd /etc/redis/
[root@cluster01 redis]# mkdir -p redis-cluster/redis600{1..6}
复制redis配置文件
[root@cluster01 redis]# vim /opt/redis.sh
#!/bin/bash
for i in {1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done
[root@cluster01 redis-5.0.7]# bash /opt/redis.sh
修改配置文件
[root@cluster01 ~]# vim /etc/redis/redis-cluster/redis6001/redis.conf
bind 127.0.0.1 //69行，注释掉bind项或不修改，默认监听所有网卡
protected-mode no //88行，修改，关闭保护模式
port 6001 //92行，修改，redis监听端口，
daemonize yes //136行，开启守护进程，以独立进程启动
appendonly yes //700行，修改，开启AOF持久化
cluster-enabled yes //832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf //840行，取消注释，群集名称文件设置
cluster-node-timeout 15000 //846行，取消注释群集超时时间设置
其他5个操作相同。
编写启动脚本
[root@cluster01 ~]# vim /opt/redis.start
#!/bin/bash
for i in {1..6}
do
cd /etc/redis/redis-cluster/redis600$i
redis-server redis.conf
done
[root@cluster01 ~]# sh /opt/redis.start
[root@cluster01 ~]# ps -ef | grep redis
root 9306 1 0 19:53 ? 00:00:03 /usr/local/bin/redis-server 127.0.0.1:6379
root 10319 1 0 20:32 ? 00:00:00 redis-server *:6001 [cluster]
root 10321 1 0 20:32 ? 00:00:00 redis-server *:6002 [cluster]
root 10329 1 0 20:32 ? 00:00:00 redis-server *:6003 [cluster]
root 10334 1 0 20:32 ? 00:00:00 redis-server *:6004 [cluster]
root 10336 1 0 20:32 ? 00:00:00 redis-server *:6005 [cluster]
root 10338 1 0 20:32 ? 00:00:00 redis-server *:6006 [cluster]
root 10378 3923 0 20:34 pts/1 00:00:00 grep --color=auto redis
加入集群
[root@cluster01 ~]# redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
//六个节点，三主三从，每个主对应一个从节点，后面的交互输入yes即可
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 127.0.0.1:6005 to 127.0.0.1:6001
Adding replica 127.0.0.1:6006 to 127.0.0.1:6002
Adding replica 127.0.0.1:6004 to 127.0.0.1:6003
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: db2cace5e18b16d9a1702bbacb9f46c4ca6d6f51 127.0.0.1:6001
slots:[0-5460] (5461 slots) master
M: caa66a520a249177436654fdd80380edf3e957f8 127.0.0.1:6002
slots:[5461-10922] (5462 slots) master
M: 71748418ac40dfc4a43b81a4707c4f173515eba2 127.0.0.1:6003
slots:[10923-16383] (5461 slots) master
S: b9d91ec88cdd06164ba0c52416ec5430f839ea4d 127.0.0.1:6004
replicates 71748418ac40dfc4a43b81a4707c4f173515eba2
S: e1a9073a5a5103037e7cc2dd40f56a622611fc6a 127.0.0.1:6005
replicates db2cace5e18b16d9a1702bbacb9f46c4ca6d6f51
S: 5bc2f4ed0f2f98a3ddde96977afd4433be4c59d6 127.0.0.1:6006
replicates caa66a520a249177436654fdd80380edf3e957f8
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
..
>>> Performing Cluster Check (using node 127.0.0.1:6001)
M: db2cace5e18b16d9a1702bbacb9f46c4ca6d6f51 127.0.0.1:6001
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: e1a9073a5a5103037e7cc2dd40f56a622611fc6a 127.0.0.1:6005
slots: (0 slots) slave
replicates db2cace5e18b16d9a1702bbacb9f46c4ca6d6f51
S: 5bc2f4ed0f2f98a3ddde96977afd4433be4c59d6 127.0.0.1:6006
slots: (0 slots) slave
replicates caa66a520a249177436654fdd80380edf3e957f8
M: 71748418ac40dfc4a43b81a4707c4f173515eba2 127.0.0.1:6003
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: b9d91ec88cdd06164ba0c52416ec5430f839ea4d 127.0.0.1:6004
slots: (0 slots) slave
replicates 71748418ac40dfc4a43b81a4707c4f173515eba2
M: caa66a520a249177436654fdd80380edf3e957f8 127.0.0.1:6002
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
查看各节点对应的哈希槽
[root@cluster01 ~]# redis-cli -p 6001 -c //进入第一个节点，-c表示节点之间可以切换
127.0.0.1:6001> cluster slots //查看各节点对应的哈希槽
1) 1) (integer) 10923
2) (integer) 16383
3) 1) "127.0.0.1"
2) (integer) 6003
3) "71748418ac40dfc4a43b81a4707c4f173515eba2"
4) 1) "127.0.0.1"
2) (integer) 6004
3) "b9d91ec88cdd06164ba0c52416ec5430f839ea4d"
2) 1) (integer) 0
2) (integer) 5460
3) 1) "127.0.0.1"
2) (integer) 6001
3) "db2cace5e18b16d9a1702bbacb9f46c4ca6d6f51"
4) 1) "127.0.0.1"
2) (integer) 6005
3) "e1a9073a5a5103037e7cc2dd40f56a622611fc6a"
3) 1) (integer) 5461
2) (integer) 10922
3) 1) "127.0.0.1"
2) (integer) 6002
3) "caa66a520a249177436654fdd80380edf3e957f8"
4) 1) "127.0.0.1"
2) (integer) 6006
3) "5bc2f4ed0f2f98a3ddde96977afd4433be4c59d6"
测试集群
127.0.0.1:6002> set xzw1 123 //创建一个key键xzw1，发现他对应哈希槽位12227
-> Redirected to slot [12227] located at 127.0.0.1:6003
OK
127.0.0.1:6003> cluster keyslot xzw1 //查看test键的槽编号
(integer) 12227
1215
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
