集群
1.redis群集
redis集群是一个提供在多个redis键节点间共享数据的程序集，redis集群并不支持多个keys的命令，因为这需要不用的节点间移动数据，从而达不到像redis那样的性能，在高负载的情况下可能导致不可预料的错误，redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或不可达的情况下继续处理命令。
2.redis集群的优势和实现方法
- redis集群的优势
- 自动分割数据到不同节点上
- 整个集群的部分节点失败或者不可达的情况能够继续处理命令
- redis集群的实现方法
- 有客户端分片
- 代理分片
- 服务器端分片
3.redis三种模式
3.1主从复制
通过持久化功能，redis保证了即使在服务器重启的情况下也不会丢失(或少量丢失)数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据，但是由于数据是存儲在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。
为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务，为此， redis提供了复制(replication)功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
在复制的概念中，数据库分为两类，一类是主数据库(master) ，另一类是从数据(slave) 。主数据可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库，而从数据库一般是只读的，并接受主数据同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。
3.1.1主从复制流程
- 启动slave进程，它会向master机器发送一个“sync command”命令，请求同步连接
- master会启动一个后台进程，无论是第一次连接还是重新连接，将数据快照（RDB）保存到数据文件中（执行RDB操作），同时master还会记录修改数据的所有命令，并缓存在数据文件中
- 后台进程完成缓存操作后，master机器就会向slave机器发送数据文件，slave端机器将数据文件保存在硬盘上，然后将其加载到内存中，接着master机器就会将修改数据的所有操作一并发送给slave端机器。若slave出现故障导致宕机，则恢复正常后会自动重新连接
- master机器收到slave端机器的连接后，将其完整的数据文件发送给slave端机器，如果master同时收到多个slave发来的同步请求，则master会在后台启动一个进程以保存数据文件，然后将其发送给所有的slave端机器，确保所有的slave端机器都正常工作
3.2哨兵模式
- redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障需要人为干预的问题
3.2.1哨兵模式主要功能
- 集群监控：负责监控redismster和slave进程是否正常工作
- 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
- 故障转移：如果master节点挂了，会自动转移到slave节点上
- 配置中心：如果故障转移发生了，通知客户端新的master地址
3.2.2哨兵监控整个系统节点过程
- 主节点的信息是配置在哨兵的配置文件中
- 哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
- 哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，主节点会返回自己的run_id 和自己的从节点信息
- 哨兵会对这些从节点也建立两条连接命令连接和订阅连接
- 哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息：run_id（redis服务器id），role（职能），从服务器的复制偏移量 offset
- 通过命令连接向服务器的 _sentinel:hello 频道发送一条消息，包括自己的ip端口、run_id、配置（后续投票的时候会用到）等
- 通过订阅连接对服务器的 _sentinel:hello 频道做监听，所以所有的向该频道发送的哨兵消息都能被接收到
- 解析监听到的消息，进行分析提取，就可以知道还有哪些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来
- 向观察到的其他的哨兵节点建立命令连接
3.3哨兵模式下的故障迁移
3.3.1主观下线
哨兵节点会每秒一次的频率向建立了命令节点的实例发送ping命令，如果在 down-after-milliseconds 毫秒内没有做出有效响应包括（pong/loading/masterdown）以外的响应，哨兵就会将该实例在本结构体中的状态标记为 sri_s_down 主观下线
3.3.2客观下线
当一个哨兵节点发现主节点处于主观下线状态时，就会向其他的哨兵节点发出询问，该节点是否已经主观下线。如果超过配置参数 quorum 个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为 sri_o_down 客观下线
3.3.3master 选举
在认为主节点客观下线的情况下，哨兵节点间会发起一次选举，命令为： SENTINEL is-master-down-by-addr，只是 run_id 这次会将自己的 run_id 带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为 leader 的情况下，会有该 leader 对故障进行迁移
3.3.4故障迁移
- 在从节点中挑选出新的从节点
通讯正常
优先级排序
优先级相同时选择offset最大的 - 将该节点设置成新的主节点 slaveof no one ，并确保在后续的 INGO 命令时，该节点返回状态为 master
- 将其他的从节点设置成从新的主节点服务，slaveof 命令
- 将旧的主节点变成新的主节点的从节点
3.4Cluster群集
redis的哨兵模式基本已经可以实现高可用、读写分离，但是在这种模式，每台redis服务器都存储相同的数据，很浪费内存资源，所以加入了 Cluster 群集模式，实现了redis的分布式存储，也就是说，每台redis节点存储着不同的内容，Cluster 群集由多个redis服务器组成的分布式网络服务群集，群集中有多个master主节点，每个主节点都可读可写，节点之间会互相通信，两两相连，redis群集无中心节点。
- 在 redis-Cluster 群集中，可以给每个主节点添加从节点，主节点和从节点直接遵循主从模型的特性，当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能
- redis-Cluster 的故障转移：redis群集的主节点内置了类似 redis sentinel 的节点故障检测和自动故障转移功能，当群集中的某个主节点下线时，群集中的其他在线主节点会注意到这点，并且对已经下线的主节点进行故障转移
- 群集进行故障转移的方法和 redis sentinel 进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点复制进行的，所以群集不必另外使用 redis sentinel
4.主从复制配置
- 需求
| master | 192.168.20.11 |
|---|---|
| slave1 | 192.168.20.22 |
| slave2 | 192.168.20.33 |
且三台都需要安装redis
- master
[root@localhost utils]# vim /etc/redis/6379.conf
- 修改监听地址
- 开启守护进程
[root@localhost utils]# /etc/init.d/redis_6379 restart //重启
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
- slave1、slave2
[root@localhost utils]# vim /etc/redis/6379.conf
- 开启守护进程
[root@localhost utils]# /etc/init.d/redis_6379 restart //重启
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
Starting Redis server...
- master
执行实时查看日志命令，并从其两个slave节点
[root@localhost utils]# tail -f /var/log/redis_6379.log
[root@localhost utils]# redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.20.22,port=6379,state=online,offset=336,lag=1
slave1:ip=192.168.20.33,port=6379,state=online,offset=336,lag=1
master_replid:84fcd30bbbfcb33b3d5966d3dbc7b75625bbe252
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:336
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:336
- 验证
- master
[root@localhost utils]# redis-cli //在master上创建键、字段
127.0.0.1:6379> set wo xx
OK
- slave1
[root@localhost utils]# redis-cli
127.0.0.1:6379> keys *
1) "wo"
- slave2
[root@localhost utils]# redis-cli
127.0.0.1:6379> keys *
1) "wo"
5.搭建哨兵
上文中提到哨兵基于主从，那么依然需要三台redis并配置好主从
- 所有的节点都需要配置
[root@localhost ~]# vim /opt/redis-5.0.7/sentinel.conf //哨兵的配置文件
[root@localhost redis-5.0.7]# redis-sentinel sentinel.conf & //启动哨兵先启动master，再启动slave
[1] 77639
[root@localhost redis-5.0.7]# 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.20.11:6379,slaves=2,sentinels=3 //可以看到，一个mymaster的ip，有两个slve，和三个哨兵
- 验证
给master再开一个终端2
[root@localhost ~]# watch -n 1 redis-cli -p 26379 info sentinel //再开启一个终端，实时查看sentinel
在master终端1中查看并杀死redis主进程
[root@localhost redis-5.0.7]# netstat -natp | grep redis //得知进程号为77192
tcp 0 0 0.0.0.0:26379 0.0.0.0:* LISTEN 77639/redis-sentine
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN 77192/redis-server
tcp 0 0 192.168.20.11:6379 192.168.20.33:33196 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:6379 192.168.20.22:36554 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:6379 192.168.20.11:48450 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:6379 192.168.20.33:33198 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:26379 192.168.20.22:46540 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:42394 192.168.20.33:6379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:38004 192.168.20.33:26379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:60322 192.168.20.22:6379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:6379 192.168.20.11:48448 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:33974 192.168.20.22:26379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:26379 192.168.20.33:52034 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:6379 192.168.20.22:43547 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:48450 192.168.20.11:6379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:6379 192.168.20.22:36552 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:48448 192.168.20.11:6379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:42392 192.168.20.33:6379 ESTABLISHED 77639/redis-sentine
tcp 0 0 192.168.20.11:6379 192.168.20.33:34880 ESTABLISHED 77192/redis-server
tcp 0 0 192.168.20.11:60324 192.168.20.22:6379 ESTABLISHED 77639/redis-sentine
tcp6 0 0 :::26379 :::* LISTEN 77639/redis-sentine
[root@localhost redis-5.0.7]# kill -9 77192 //杀死
[root@localhost redis-5.0.7]# tail -f /var/log/sentinel.log
在mster终端2中查看变化
6.cluster集群
因为一些硬件原因（其实就是本人电脑辣鸡），这里本来想要6台搞一下，但是想想电脑几斤几两，罢了，简便一点吧
- 节点端口号
| 主 | 6001 | 6002 | 6003 |
|---|---|---|---|
| 从 | 6004 | 6005 | 6006 |
[root@localhost redis]# mkdir -p redis-cluster/redis600{1..6} //递归创建6个工作目录
[root@localhost redis]# ls
6379.conf redis-cluster
[root@localhost redis]# cd redis-cluster/
[root@localhost redis-cluster]# ls
redis6001 redis6002 redis6003 redis6004 redis6005 redis6006
[root@localhost opt]# vim /opt/redis.sh
#!/bin/bash
#将主配置文件和启动命令、启动脚本复制到6个文件下
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@localhost opt]# sh -x /opt/redis.sh
+ for i in '{1..6}'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6001
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6001
+ for i in '{1..6}'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6002
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6002
+ for i in '{1..6}'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6003
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6003
+ for i in '{1..6}'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6004
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6004
+ for i in '{1..6}'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6005
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6005
+ for i in '{1..6}'
+ cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6006
+ cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6006
[root@localhost opt]# cd /etc/redis/redis-cluster/ //验证
[root@localhost redis-cluster]# ls
redis6001 redis6002 redis6003 redis6004 redis6005 redis6006
[root@localhost redis-cluster]# cd redis6001
[root@localhost redis6001]# ls
redis-cli redis.conf redis-server
[root@localhost redis6001]# cd /etc/redis/redis-cluster/redis6001
[root@localhost redis6001]# vim redis.conf
- 复制配置到redis6002、6003、6004、6005、6006
[root@localhost redis6001]# cp redis.conf ../redis6002/
cp：是否覆盖"../redis6002/redis.conf"？ y
[root@localhost redis6001]# cp redis.conf ../redis6003/
cp：是否覆盖"../redis6003/redis.conf"？ y
[root@localhost redis6001]# cp redis.conf ../redis6004/
cp：是否覆盖"../redis6004/redis.conf"？ y
[root@localhost redis6001]# cp redis.conf ../redis6005/
cp：是否覆盖"../redis6005/redis.conf"？ y
[root@localhost redis6001]# cp redis.conf ../redis6006/
cp：是否覆盖"../redis6006/redis.conf"？ y
然后依次在另外五个redis600*中变更端口为对应端口例如将redis6002中的两个需要改端口的地方改为6002
- 编写脚本根据对应文件启动redis
[root@localhost redis6001]# vim /opt/redis_start.sh
#!/bin/bash
for a in {1..6}
do
cd /etc/redis/redis-cluster/redis600$a
redis-server redis.conf
done
[root@localhost redis6001]# sh -x /opt/redis_start.sh //执行脚本
+ for a in '{1..6}'
+ cd /etc/redis/redis-cluster/redis6001
+ redis-server redis.conf
77530:C 09 Aug 2021 22:20:20.670 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
77530:C 09 Aug 2021 22:20:20.670 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=77530, just started
77530:C 09 Aug 2021 22:20:20.670 # Configuration loaded
+ for a in '{1..6}'
+ cd /etc/redis/redis-cluster/redis6002
+ redis-server redis.conf
77532:C 09 Aug 2021 22:20:20.701 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
77532:C 09 Aug 2021 22:20:20.701 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=77532, just started
77532:C 09 Aug 2021 22:20:20.701 # Configuration loaded
+ for a in '{1..6}'
+ cd /etc/redis/redis-cluster/redis6003
+ redis-server redis.conf
77537:C 09 Aug 2021 22:20:20.741 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
77537:C 09 Aug 2021 22:20:20.741 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=77537, just started
77537:C 09 Aug 2021 22:20:20.741 # Configuration loaded
+ for a in '{1..6}'
+ cd /etc/redis/redis-cluster/redis6004
+ redis-server redis.conf
77542:C 09 Aug 2021 22:20:20.759 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
77542:C 09 Aug 2021 22:20:20.759 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=77542, just started
77542:C 09 Aug 2021 22:20:20.759 # Configuration loaded
+ for a in '{1..6}'
+ cd /etc/redis/redis-cluster/redis6005
+ redis-server redis.conf
77547:C 09 Aug 2021 22:20:20.778 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
77547:C 09 Aug 2021 22:20:20.778 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=77547, just started
77547:C 09 Aug 2021 22:20:20.778 # Configuration loaded
+ for a in '{1..6}'
+ cd /etc/redis/redis-cluster/redis6006
+ redis-server redis.conf
77552:C 09 Aug 2021 22:20:20.810 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
77552:C 09 Aug 2021 22:20:20.810 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=77552, just started
77552:C 09 Aug 2021 22:20:20.810 # Configuration loaded
[root@localhost redis6001]# ps -ef | grep redis //查看是否开启
root 76988 1 0 21:42 ? 00:00:02 /usr/local/redis/bin/redis-server 127.0.0.1:6379
root 77531 1 0 22:20 ? 00:00:00 redis-server 127.0.0.1:6001 [cluster]
root 77536 1 0 22:20 ? 00:00:00 redis-server 127.0.0.1:6002 [cluster]
root 77541 1 0 22:20 ? 00:00:00 redis-server 127.0.0.1:6003 [cluster]
root 77546 1 0 22:20 ? 00:00:00 redis-server 127.0.0.1:6004 [cluster]
root 77551 1 0 22:20 ? 00:00:00 redis-server 127.0.0.1:6005 [cluster]
root 77556 1 0 22:20 ? 00:00:00 redis-server 127.0.0.1:6006 [cluster]
root 77570 72553 0 22:20 pts/1 00:00:00 grep --color=auto redis
[root@localhost redis6001]# 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才可以创建，-replicas 1 表示每个主节点有一个从节点
>>> 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: 6e6ae7bb6b0d8f732c73f022fbde79747c343e0c 127.0.0.1:6001
slots:[0-5460] (5461 slots) master
M: ce121376eb627be8939910ccd489e99c2cf8fe79 127.0.0.1:6002
slots:[5461-10922] (5462 slots) master
M: 496838dd19ee4f27cddc7491dfedd4f05cb41c4e 127.0.0.1:6003
slots:[10923-16383] (5461 slots) master
S: e3dd518050a462aaed26f4f63d67733f375e662d 127.0.0.1:6004
replicates ce121376eb627be8939910ccd489e99c2cf8fe79
S: aa22b5a5459e6dc443fc787297645d3db79f0040 127.0.0.1:6005
replicates 496838dd19ee4f27cddc7491dfedd4f05cb41c4e
S: 7e704c66a5921013d28185c5fc88df361798925b 127.0.0.1:6006
replicates 6e6ae7bb6b0d8f732c73f022fbde79747c343e0c
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: 6e6ae7bb6b0d8f732c73f022fbde79747c343e0c 127.0.0.1:6001
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: aa22b5a5459e6dc443fc787297645d3db79f0040 127.0.0.1:6005
slots: (0 slots) slave
replicates 496838dd19ee4f27cddc7491dfedd4f05cb41c4e
M: 496838dd19ee4f27cddc7491dfedd4f05cb41c4e 127.0.0.1:6003
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: e3dd518050a462aaed26f4f63d67733f375e662d 127.0.0.1:6004
slots: (0 slots) slave
replicates ce121376eb627be8939910ccd489e99c2cf8fe79
S: 7e704c66a5921013d28185c5fc88df361798925b 127.0.0.1:6006
slots: (0 slots) slave
replicates 6e6ae7bb6b0d8f732c73f022fbde79747c343e0c
M: ce121376eb627be8939910ccd489e99c2cf8fe79 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@localhost redis6001]# redis-cli -p 6001 -c
127.0.0.1:6001> cluster slots //查看节点的哈希槽编号范围
1) 1) (integer) 10923
2) (integer) 16383 //华西操编号范围
3) 1) "127.0.0.1"
2) (integer) 6003 //主节点ip和端口号
3) "496838dd19ee4f27cddc7491dfedd4f05cb41c4e"
4) 1) "127.0.0.1"
2) (integer) 6005 //从节点ip和端口号
3) "aa22b5a5459e6dc443fc787297645d3db79f0040"
2) 1) (integer) 5461
2) (integer) 10922
3) 1) "127.0.0.1"
2) (integer) 6002
3) "ce121376eb627be8939910ccd489e99c2cf8fe79"
4) 1) "127.0.0.1"
2) (integer) 6004
3) "e3dd518050a462aaed26f4f63d67733f375e662d"
3) 1) (integer) 0
2) (integer) 5460
3) 1) "127.0.0.1"
2) (integer) 6001
3) "6e6ae7bb6b0d8f732c73f022fbde79747c343e0c"
4) 1) "127.0.0.1"
2) (integer) 6006
3) "7e704c66a5921013d28185c5fc88df361798925b"
127.0.0.1:6001> set wo xx
OK
127.0.0.1:6001> CLUSTER KEYSLOT wo
(integer) 3207
127.0.0.1:6002> set home hangzhou
OK
127.0.0.1:6002> cluster keyslot home
(integer) 10814
那么结果告诉我们wo被放在了6001哈希槽、home被放在6002哈希槽中
扫一扫
505
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
