redis多实例常见部署方法和使用

blackoon88

已于 2022-05-09 12:01:54 修改

阅读量2.6k

点赞数

分类专栏：运维文章标签： redis 缓存数据库

于 2022-05-01 23:17:51 首次发布

本文链接：https://blog.csdn.net/blackoon88/article/details/124531409

版权

运维专栏收录该内容

10 篇文章 0 订阅

订阅专栏

前言

之前讲过Redis的基本操作和应用场景，里面的Redis是单台部署。由于线上生产环境对并发和性能要求高，所以介绍下Redis不同的集群部署方式。

本地安装Redis最新版本：redis_version:6.2.6

一、主从复制

1.一主多从架构

1.1应用场景

主从复制（读写分离）

对于单台来说的优点：
- 避免redis单点故障，出现宕机需要手动处理恢复
- 构建读写分离架构，满足读多写少的应用场景
缺点：
- Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
- 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
- Redis较难支持在线扩容，在单台内存容量达到上限时扩容会变得很复杂（在设计之初要评估好内存大小）。

1.2安装步骤

构建6379（Master）、6380（Slave）、6381（Slave）三个实例

创建6380、6381目录，分别将安装目录下的redis.conf拷贝到这两个目录下。三个目录，本地有一个是brew安装生成的，基于此复制出2个目录文件。

mkdir redis6380
mkdir redis6381
cp redis.conf redis6380/
cp redis.conf redis6381/

修改配置文件redis6380

vi redis6380/redis.conf

文件如下：

port 6380
daemonize yes
pidfile /var/run/redis_6380.pid
logfile /usr/local/var/log/redis6380.log
replicaof 127.0.0.1 6379

修改配置文件redis6381

vi redis6381/redis.conf

文件如下：

port 6381
daemonize yes
pidfile /var/run/redis_6381.pid
logfile /usr/local/var/log/redis6381.log
replicaof 127.0.0.1 6379

启动三个redis实例

brew services start redis
redis-server /usr/local/etc/redis6380/redis.conf 
redis-server /usr/local/etc/redis6381/redis.conf

成功状态如下：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=630,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=630,lag=1
master_failover_state:no-failover
master_replid:bfb02a26755a18025b30fe33e2c73419d9680a50
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:630
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:630

注意：Redis如要要设置密码，建议3台都设置密码且密码一致。不仅是从需要配置主的密码，后面要讲到的哨兵也要配置密码。

1.3客户端使用方法

cli客户端
redis-cli -p 6379 -a ws
查看主从信息：INFO Replication
Java端调用 JedisPool 连接池。

1.4故障处理

从Redis宕机

在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；从库在断开期间，主库的变化不大，从库再次启动后，主库依然不会将所有的数据做RDB操作，只是增量复制（从库有做持久化的前提下）

主Redis宕机

在从数据库中执行SLAVEOF NO ONE或者 REPLICAOF NO ONE命令，断开主从关系并且提升为主库继续服务；
将主库重新启动后，执行SLAVEOF或者replicaof命令，将其设置为从库，这时数据就能更新回来；
（replicaof 127.0.0.1 6381 ）

2、主从从架构

2.1应用场景

主从复制（读写分离）

主从复制的好处：
- 避免redis单点故障
- 构建读写分离架构，满足读多写少的应用场景
- Slave接受Slave的连接和同步请求，可以有效的分载Master的同步压力。
主从复制的缺点：
- Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
- 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
- Redis较难支持在线扩容，在单台内存容量达到上限时扩容会变得很复杂。
- Slave连接Slave的层越多，从主同步到最后一个Slave同步完成，必然存在一个时间上的较大延迟，导致数据不一致的时间窗口较大，所以要合理选择层数。

注意：从连从，看起来前面的从是主，实际上丛丛的主还是master，中间的Slave只是一个代理主，将master的数据同步给下一个Slave。理由如下：如果只是在Slave写数据，是不会同步给下一个Slave的。如果Master挂了，两个Slave的Master也就都挂了(master_link_status:down).

2.2安装步骤

构建6379（Master）、6380（Slave）、6381（Slave）三个实例

修改配置文件redis6381

vi redis6381/redis.conf

文件如下：

replicaof 127.0.0.1 6380
# masterauth ws #注释掉

启动三个redis实例

brew services start redis
redis-server /usr/local/etc/redis6380/redis.conf 
redis-server /usr/local/etc/redis6381/redis.conf

2.3客户端使用方法

cli
redis-cli -p 6379 -a ws
查看主从信息：INFO replication
java 端
java 端读写分离：可以采用不同的Java程序来实现。

2.4故障处理

可以参照主从故障处理。

二、哨兵

1.1 单个哨兵的架构

1.1.1应用场景

一般在生产环境，采用哨兵架构。主从复制(一主多从)，采用哨兵，可以实现宕机主动修复，不需要手动恢复，起到高可用的效果。

哨兵对Redis的系统的运行情况进行监控，它是一个独立进程。
作用如下：
1、监控主数据库和从数据库是否运行正常；
2、主数据出现故障后自动将从数据库转化为主数据库；

1.1.2配置哨兵

配置哨兵前先准备好一主多从的三个实例。
创建哨兵配置文件：

vi sentinel.conf

daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 2
#sentinel auth-pass mymaster ws
sentinel down-after-milliseconds mymaster 3000
# 指定多少毫秒之后主节点没有应答哨兵sentinel；即哨兵主观上认为主节点下线，默认30秒，这里设置为3秒

sentinel monitor mymaster 127.0.0.1 6379 1说明如下：
mymaster：监控主数据的名称，可以使用大小写字母和“.-_”符号自定义
127.0.0.1：监控的主数据库的IP
6379：监控的主数据库的端口
1：最低通过票数
sentinel auth-pass mymaster ws说明如下：
所有节点设置了密码这里需要指定master密码

启动哨兵进程：
redis-sentinel /usr/local/etc/redis-sentinel.conf
哨兵无需配置slave，只需要指定master，哨兵会自动发现slave
主从从架构，哨兵无法发现从的从。

1.1.3故障处理

slave新加入一台和master宕机，都是自动处理，日志如下

(base) valley@valleyMacBook-Pro ~ % redis-sentinel /usr/local/etc/redis-sentinel.conf
47391:X 29 Apr 2022 16:54:13.429 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
47391:X 29 Apr 2022 16:54:13.429 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=47391, just started
47391:X 29 Apr 2022 16:54:13.429 # Configuration loaded
47391:X 29 Apr 2022 16:54:13.430 * Increased maximum number of open files to 10032 (it was originally set to 2560).
47391:X 29 Apr 2022 16:54:13.430 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 6.2.6 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 47391
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

47391:X 29 Apr 2022 16:54:13.433 # Sentinel ID is 708b67a44c42916e70d4186dad02b8dbdbbb7473
47391:X 29 Apr 2022 16:54:13.433 # +monitor master mymaster 127.0.0.1 6379 quorum 1
47391:X 29 Apr 2022 16:54:13.438 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:33:42.726 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.119 # +sdown master mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.119 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
47391:X 29 Apr 2022 17:34:42.119 # +new-epoch 1
47391:X 29 Apr 2022 17:34:42.119 # +try-failover master mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.121 # +vote-for-leader 708b67a44c42916e70d4186dad02b8dbdbbb7473 1
47391:X 29 Apr 2022 17:34:42.121 # +elected-leader master mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.121 # +failover-state-select-slave master mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.184 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.184 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.247 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.889 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.889 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:42.976 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
47391:X 29 Apr 2022 17:34:43.941 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

注意：哨兵模式下，主从切换，会将节点的主信息写入到配置文件。replicaof 127.0.0.1 6381

1.2多个哨兵的架构

多个哨兵（我这里设置2个哨兵），不仅同时监控主从redis实例，而且哨兵之间互为监控。

cp redis-sentinel.conf /usr/local/etc/redis-sentinel2.conf
vi sentinel2.conf

port 26380
daemonize yes
pidfile /var/run/redis-sentinel2.pid
log /usr/local/var/log/redis-sentinel2.log
sentinel monitor mymaster 127.0.0.1 6379 1
#sentinel auth-pass mymaster ws
sentinel down-after-milliseconds mymaster 3000
# 指定多少毫秒之后主节点没有应答哨兵sentinel；即哨兵主观上认为主节点下线，默认30秒，这里设置为3秒

成功结果如下：

63649:X 01 May 2022 18:22:44.395 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=63649, just started
63649:X 01 May 2022 18:22:44.395 # Configuration loaded
63649:X 01 May 2022 18:22:44.396 * Increased maximum number of open files to 10032 (it was originally set to 2560).
63649:X 01 May 2022 18:22:44.397 * monotonic clock: POSIX clock_gettime
63649:X 01 May 2022 18:22:44.398 * Running mode=sentinel, port=26380.
63649:X 01 May 2022 18:22:44.400 # Sentinel ID is a787af8718389e36bedf516ea8d9a30e0e2bf403
63649:X 01 May 2022 18:22:44.400 # +monitor master mymaster 127.0.0.1 6379 quorum 1
63649:X 01 May 2022 18:22:44.401 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 18:22:44.402 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 18:22:45.858 * +sentinel sentinel acc1fb84c37f69688409ccc36dd8fafe033e7758 127.0.0.1 26379 @ mymaster 127.0.0.1 6379

63570:X 01 May 2022 17:58:59.111 # Redis version=6.2.6, bits=64, commit=00000000, modified=0, pid=63570, just started
63570:X 01 May 2022 17:58:59.111 # Configuration loaded
63570:X 01 May 2022 17:58:59.112 * Increased maximum number of open files to 10032 (it was originally set to 2560).
63570:X 01 May 2022 17:58:59.113 * monotonic clock: POSIX clock_gettime
63570:X 01 May 2022 17:58:59.119 * Running mode=sentinel, port=26379.
63570:X 01 May 2022 17:58:59.120 # Sentinel ID is acc1fb84c37f69688409ccc36dd8fafe033e7758
63570:X 01 May 2022 17:58:59.120 # +monitor master mymaster 127.0.0.1 6379 quorum 2
63570:X 01 May 2022 17:58:59.127 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
63570:X 01 May 2022 17:58:59.128 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
63570:X 01 May 2022 18:22:46.437 * +sentinel sentinel a787af8718389e36bedf516ea8d9a30e0e2bf403 127.0.0.1 26380 @ mymaster 127.0.0.1 6379

关掉主实例，哨兵日志文件如下：

63649:X 01 May 2022 19:18:26.206 # +sdown master mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.207 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
63649:X 01 May 2022 19:18:26.207 # +new-epoch 1
63649:X 01 May 2022 19:18:26.208 # +try-failover master mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.211 # +vote-for-leader a787af8718389e36bedf516ea8d9a30e0e2bf403 1
63649:X 01 May 2022 19:18:26.216 # acc1fb84c37f69688409ccc36dd8fafe033e7758 voted for a787af8718389e36bedf516ea8d9a30e0e2bf403 1
63649:X 01 May 2022 19:18:26.271 # +elected-leader master mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.272 # +failover-state-select-slave master mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.373 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.374 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.428 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.728 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.728 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:26.783 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:27.763 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:27.764 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:27.830 # +failover-end master mymaster 127.0.0.1 6379
63649:X 01 May 2022 19:18:27.830 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
63649:X 01 May 2022 19:18:27.831 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
63649:X 01 May 2022 19:18:27.831 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
63649:X 01 May 2022 19:18:57.869 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

我这里启动了两个哨兵，生产环境建议开启3个哨兵，一般的哨兵为奇数个。

1.3客户端使用方法

Java客户端调用创建JedisSentinelPool 高可用连接池。

三、切片(分片)集群（采用hash槽）

1.应用场景

哨兵模式比主从模式提高了系统的高可用性，但是该模式不能水平扩容和不能动态的增、删节点，限制了哨兵模式广泛应用。

集群好处
- 实现扩容
- 分摊压力
- 主机写，从机读
- 无中心化主从集群，无论从哪台主机写的数据，其他主机上都能读到数据
集群不足
- 部分功能不支持,比如不在一个slot下的键值，是不能使用mget,mset等多键操作。

2.集群配置

一个集群至少要有三个主节点，那就是最小需要6个实例。

修改redis.conf

#注释只能本机访问
#bind 127.0.0.1 -::1
pidfile /var/run/redis.pid
logfile /usr/local/var/log/redis.log
#replicaof 127.0.0.1 6381 注释掉
#修改端口号
port 6379
#守护线程改为yes
daemonize yes
#放开集群的注释
cluster-enabled yes    #打开集群模式
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000   #设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。
#是否开启保护模式，由yes改为no
protected-mode no

修改其他redis.conf的端口以及文件，其他参数参照以上
新建一个启动脚本start.sh

./redis-server redis.conf
./redis-server redis6380.conf
./redis-server redis6381.conf
./redis-server redis6382.conf
./redis-server redis6383.conf
./redis-server redis6384.conf

其中一台实例启动成功日志如下

65123:M 01 May 2022 21:42:57.315 * monotonic clock: POSIX clock_gettime
65123:M 01 May 2022 21:42:57.316 * Node configuration loaded, I'm e8db286926e1fddfc7999137364e227bc2dcee12
65123:M 01 May 2022 21:42:57.316 * Running mode=cluster, port=6379.
65123:M 01 May 2022 21:42:57.316 # Server initialized
65123:M 01 May 2022 21:42:57.317 * Loading RDB produced by version 6.2.6
65123:M 01 May 2022 21:42:57.317 * RDB age 458 seconds
65123:M 01 May 2022 21:42:57.317 * RDB memory usage when created 1.52 Mb
65123:M 01 May 2022 21:42:57.317 # Done loading RDB, keys loaded: 4, keys expired: 0.
65123:M 01 May 2022 21:42:57.317 * DB loaded from disk: 0.000 seconds
65123:M 01 May 2022 21:42:57.317 * Ready to accept connections

start.sh 赋权限(写和执行的权限),执行start.sh

chmod u+x start.sh
./start.sh

创建集群

redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

创建集群时redis中不要有数据,否则会报错如下
[ERR] Node 127.0.0.1:6379 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0.
重新启动还报以上错误时，要注意删除所有nodes-*.conf。

集群成功日志如下

(base) valley@192 redis % redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-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:6383 to 127.0.0.1:6379
Adding replica 127.0.0.1:6384 to 127.0.0.1:6380
Adding replica 127.0.0.1:6382 to 127.0.0.1:6381
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: 478d2e80d16a3006a8cad8fe696b0a0cd1d7b157 127.0.0.1:6379
   slots:[0-5460] (5461 slots) master
M: 82ef60f671bb1df96cbe8b4f521d7adc58834f02 127.0.0.1:6380
   slots:[5461-10922] (5462 slots) master
M: 68dac12a3369a7296b79b0c5f3b3b9b0e0f66aa3 127.0.0.1:6381
   slots:[10923-16383] (5461 slots) master
S: 88988b2442d9d04b8dd8d852b0a6b743dcc21b86 127.0.0.1:6382
   replicates 68dac12a3369a7296b79b0c5f3b3b9b0e0f66aa3
S: b0ff37c8daacbcfbc728e34ced4255aa19c786d4 127.0.0.1:6383
   replicates 478d2e80d16a3006a8cad8fe696b0a0cd1d7b157
S: 50a82ce62b096c77f855c3bf604c274ceed2dc75 127.0.0.1:6384
   replicates 82ef60f671bb1df96cbe8b4f521d7adc58834f02
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:6379)
M: 478d2e80d16a3006a8cad8fe696b0a0cd1d7b157 127.0.0.1:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: 50a82ce62b096c77f855c3bf604c274ceed2dc75 127.0.0.1:6384
   slots: (0 slots) slave
   replicates 82ef60f671bb1df96cbe8b4f521d7adc58834f02
S: 88988b2442d9d04b8dd8d852b0a6b743dcc21b86 127.0.0.1:6382
   slots: (0 slots) slave
   replicates 68dac12a3369a7296b79b0c5f3b3b9b0e0f66aa3
M: 68dac12a3369a7296b79b0c5f3b3b9b0e0f66aa3 127.0.0.1:6381
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
M: 82ef60f671bb1df96cbe8b4f521d7adc58834f02 127.0.0.1:6380
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: b0ff37c8daacbcfbc728e34ced4255aa19c786d4 127.0.0.1:6383
   slots: (0 slots) slave
   replicates 478d2e80d16a3006a8cad8fe696b0a0cd1d7b157
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
(base) valley@192 redis %

3.故障恢复

3.1主节点宕掉

默认15秒超时，从节点自动升为主节点
主节点恢复后，主节点变成从机

3.2某一段插槽的主从节点都宕掉

当redis.conf中的参数cluster-require-full-coverage 为yes ，整个集群都挂掉
当redis.conf中的参数cluster-require-full-coverage 为no ，该插槽数据无法读写。

4.客户端使用方法

4.1cli

命令客户端连接集群 (-c 表示以集群方式进行连接)

redis-cli -h 127.0.0.1 -p 6379 -c

查看集群中的节点

cluster nodes

127.0.0.1:6380> cluster nodes
68dac12a3369a7296b79b0c5f3b3b9b0e0f66aa3 127.0.0.1:6381@16381 master - 0 1651417187000 3 connected 10923-16383
478d2e80d16a3006a8cad8fe696b0a0cd1d7b157 127.0.0.1:6379@16379 master - 0 1651417187511 1 connected 0-5460
82ef60f671bb1df96cbe8b4f521d7adc58834f02 127.0.0.1:6380@16380 myself,master - 0 1651417186000 2 connected 5461-10922
b0ff37c8daacbcfbc728e34ced4255aa19c786d4 127.0.0.1:6383@16383 slave 478d2e80d16a3006a8cad8fe696b0a0cd1d7b157 0 1651417187005 1 connected
50a82ce62b096c77f855c3bf604c274ceed2dc75 127.0.0.1:6384@16384 slave 82ef60f671bb1df96cbe8b4f521d7adc58834f02 0 1651417187511 2 connected
88988b2442d9d04b8dd8d852b0a6b743dcc21b86 127.0.0.1:6382@16382 slave 68dac12a3369a7296b79b0c5f3b3b9b0e0f66aa3 0 1651417188017 3 connected

查看集群状态

cluster info

127.0.0.1:6380> 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:6
cluster_my_epoch:2
cluster_stats_messages_ping_sent:229
cluster_stats_messages_pong_sent:233
cluster_stats_messages_meet_sent:1
cluster_stats_messages_sent:463
cluster_stats_messages_ping_received:233
cluster_stats_messages_pong_received:230
cluster_stats_messages_received:463

使用集群

127.0.0.1:6380> set key1 1
OK
127.0.0.1:6380> set key2 2
-> Redirected to slot [4998] located at 127.0.0.1:6379
OK

4.2java 端

采用JedisCluster

public class JedisClusterTest {
  public static void main(String[] args) { 
     Set<HostAndPort>set =new HashSet<HostAndPort>();
     set.add(new HostAndPort("127.0.0.1",6379));
     JedisCluster jedisCluster=new JedisCluster(set);
     jedisCluster.set("k1", "hello world");
  }
}

总结

默认情况下redis数据库充当slave角色时只读操作。可以在配置文件中开启非只读：replica-read-only no。非必要，尽量不要开启，因为从数据修改不会同步到主，容易出现数据不一致。数据同步方向：主到从。主从从部署，哪怕是中间的从写入数据，是不会同步到它的从的。但是从主写的数据，从从数据都会更新。
宕机监控告警到运维人员,可以采用第三方工具采集Redis数据可视化，这一点涉及到运维监控，后面文章讲解。
持久化问题：save 默认是关闭的，正式环境需要开启(save 300 100)。并通过修改appendonly为yes，将rdb改为aof，可以防止数据丢失。
多主机部署：注释 #bind 127.0.0.1 -::1 ；是否开启保护模式protected-mode，由yes改为no

blackoon88

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
打赏
0
评论
redis多实例常见部署方法和使用

文章目录前言一、主从复制1.一主多从架构1.1应用场景1.2安装步骤1.3客户端使用方法1.4故障处理2、主从从架构2.1应用场景2.2安装步骤2.3客户端使用方法2.4故障处理二、哨兵1.1 单个哨兵的架构1.1.1应用场景1.1.2配置哨兵1.1.3故障处理1.2多个哨兵的架构1.3客户端调用三、切片(分片)集群（采用hash槽）1.应用场景2.集群配置3.故障恢复3.1主节点宕掉3.2某一段插槽的主从节点都宕掉4.客户端clijava 端总结前言之前讲过Redis的基本操作和应用场景，里面的Re
复制链接

扫一扫