Redis集群介绍——主从、哨兵、集群

原创 已于 2025-08-28 16:48:09 修改 · 1.2k 阅读 · 17 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #集群模式 #哨兵模式 #主从模式 #Redis

于 2025-08-27 21:09:35 首次发布

Redis集群介绍

集群里有三大模式：

Redis主从模式：一主一从或一主多从，自带读写分离，负载均衡；

Redis哨兵模式：高可用，主服务器宕机，从服务器变为主服务器；

Redis集群模式（分片）：将数据拆分存储到多个Redis主从集群中。访问任何一台服务器都可以查到所有数据。

Redis主从模式

原理：第一次同步时，使用RDB（快照），在同步时，主服务器产生的数据，会记录偏移量，在同步完成后，进行偏移量的同步。

之后的同步的数据是通过AOF日志方式同步的。

工作机制（了解）

  • 当slave启动后，主动向master发送SYNC命令；
  • master接受到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令；
  • 然后将保存的快照文件和缓存的命令发送给slave；
  • slave收到快照文件和命令后加载快照文件和缓存的执行命令；
  • 复制初始化后，master每次收到的写命令都会同步发送给slave，保证主从数据一致性。

缺点：只有主服务器能写入数据，从服务器只能读，主服务器一旦宕机，导致无法写入数据。

哨兵模式

功能：

  1. 监控所有Redis服务器，重点监控主服务器，1秒ping一次主，10秒ping一次从；
  2. 主服务器宕机主观下线，10秒后未恢复，客观下线，选举新的主服务器，根据条件（数据完整性、服务器性能）；
  3. 通知其他从服务器，主从变更，让其他从服务器链接新的主服务器。

多哨兵模式：

·哨兵监控主从的同时，也监控其他哨兵。

·当主宕机，哨兵中选出一个哨兵，这个哨兵再从其他从服务器中选出新的主。

工作机制（了解）

  • 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令
  • 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。
  • 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态
  • 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线
  • 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令
  • 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次
  • 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；
  • 若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

Redis集群模式

集群=哨兵+主从+分片，实现高扩展性

集群模式特点

多个redis节点网络互联，数据共享

支持在线增加、删除节点

客户端可以连接任何一个主节点进行读写

优点：

  • 多个redis节点网络互联，数据共享；
  • 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用；
  • 支持在线增加、删除节点；
  • 客户端可以连接任何一个主节点进行读写；

缺点：

  • 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上；
  • 并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。

集群工作方式

哈希槽：默认Redis官方在Redis集群模式中内置了16384个槽

插槽的取值范围是：0-16383。cluster，可以理解为是一个集群管理的插件。

当我们的存取 Key的时候，Redis 会根据算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

1 % 16384 = 1

Redis重定向：在Redis集群任意节点查询或存储修改数据时，通过哈希槽运算，未命中节点，则会重新计算查找节点。

集群模式的搭建⭐⭐⭐（单机多实例）

  1. 第一步：创建一个文件夹redis-cluster，然后在其下面分别创建6个文件夹如下：

[root@localhost ~]# cd /usr/local/redis

[root@localhost redis]# ls

bin  data  etc  logs  redis.pid

[root@localhost redis]# mkdir redis-cluster

[root@localhost redis]# cd redis-cluster/

[root@localhost redis-cluster]# mkdir 700{1..6}

[root@localhost redis-cluster]# ls

7001  7002  7003  7004  7005  7006

  1. 第二步：把之前的redis.conf配置文件分别copy到700*下

# 返回redis目录里

cd ../

[root@localhost redis]# cp ./etc/redis.conf ./redis-cluster/7001/redis.conf

[root@localhost redis]# cp ./etc/redis.conf ./redis-cluster/7002/redis.conf

[root@localhost redis]# cp ./etc/redis.conf ./redis-cluster/7003/redis.conf

[root@localhost redis]# cp ./etc/redis.conf ./redis-cluster/7004/redis.conf

[root@localhost redis]# cp ./etc/redis.conf ./redis-cluster/7005/redis.conf

[root@localhost redis-cluster]# cp ../etc/redis.conf 7006

[root@localhost redis-cluster]# tree

  1. 第三步：修改集群配置

[root@zuolaoshi redis]# vim ./redis-cluster/7001/redis.conf

以下是全部修改内容：

bind 192.168.221.129

port 7001

pidfile /usr/local/redis/redis-cluster/7001/redis.pid

logfile "/usr/local/redis/logs/redis-7001.log"

dir /usr/local/redis/redis-cluster/7001/

appendonly yes

cluster-enabled yes

cluster-config-file nodes7001.conf

cluster-node-timeout 5000

# 切换到cluster比较方便

[root@localhost redis]# cd redis-cluster/

# 刷新一下7001的配置文件

[root@localhost redis-cluster]# redis-server 7001/redis.conf 

# 查看是否开启

[root@localhost redis-cluster]# netstat -lnutp | grep 7001

#会出现

tcp        0      0 192.168.221.129:17001    0.0.0.0:*               LISTEN      66164/redis-server  

tcp        0      0 192.168.221.129:7001     0.0.0.0:*               LISTEN      66164/redis-server  

tcp6       0      0 ::1:17001               :::*                    LISTEN      66164/redis-server  

tcp6       0      0 ::1:7001                :::*                    LISTEN      66164/redis-server

# 把修改好的配置文件覆盖到7002到7006的配置文件上

[root@localhost redis-cluster]# cp 7001/redis.conf 7002/redis.conf

cp：是否覆盖"7002/redis.conf"？ y

# 修改每一个配置文件（五个文件都重复这个步骤）

[root@localhost redis-cluster]# vim 7002/redis.conf

:%s/7001/7002/g

[root@localhost redis-cluster]# redis-server 7002/redis.conf 

[root@localhost redis-cluster]# netstat -lnutp | grep 7002

！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

中途换成Ubuntu，安装了Redis，互传了redis-cluster目录，改了IP，别的都没有变，建议下次直接使用Ubuntu：

scp -r root@192.168.221.10:/usr/local/redis/redis-cluster /usr/local/redis/

先进入/usr/local/redis目录里

cd /usr/local/redis/

！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

# 安装ruby

apt install ruby                  Y

gem install redis

# 创建集群

root@cqh-virtual-machine:/usr/local/redis# ./bin/redis-cli --cluster create 192.168.221.129:7001 192.168.221.129:7002 192.168.221.129:7003 192.168.221.129:7004 192.168.221.129:7005 192.168.221.129:7006 --cluster-replicas 1

出现

最后出现绿色OK就成功了

# 查看Redis服务状态

ps -ef | grep redis

# 进入7001端口

root@cqh-virtual-machine:/usr/local/redis# ./bin/redis-cli -c -h 192.168.221.129 -p 7001

192.168.221.129:7001> info cluster

# Cluster

cluster_enabled:1       #节点是否为cluster模式，1是0否

# 测试操作

192.168.221.129:7001> exit

root@cqh-virtual-machine:/usr/local/redis# ./bin/redis-cli -c -h 192.168.221.129 -p 7005

192.168.221.129:7005> set b fdfsfsd

-> Redirected to slot [3300] located at 192.168.221.129:7001

OK

192.168.221.129:7001> get b

"fdfsfsd"

192.168.221.129:7001> set c fdsfdfdsfds

-> Redirected to slot [7365] located at 192.168.221.129:7002

OK

192.168.221.129:7002> get c

"fdsfdfdsfds"

192.168.221.129:7002> set x fdsfdsfsdf

-> Redirected to slot [16287] located at 192.168.221.129:7003

OK

192.168.221.129:7003> keys *

1) "x"

192.168.221.129:7003> get b

-> Redirected to slot [3300] located at 192.168.221.129:7001

"fdfsfsd"

192.168.221.129:7001> keys *

1) "b"

192.168.221.129:7001> set d fdsfdsfsd

-> Redirected to slot [11298] located at 192.168.221.129:7003

OK

192.168.221.129:7003> get d

"fdsfdsfsd"

192.168.221.129:7003> set x zhangsan

OK

192.168.221.129:7003> get x

"zhangsan"

192.168.221.129:7003> exit

实验：一主两从三哨兵⭐⭐⭐

一、安装好Redis

192.168.221.20 Redis（主）

192.168.221.30 Redis（从）

192.168.221.40 Redis（从）

安装Redis

二、多机主从配置一主二从

2.1、准备工作

开启三台虚拟主机20、30、40，分别安装redis

检查防火墙、挂载光盘

systemctl status firewalld

mount /dev/cdrom /media

2.2、配置主机和从机

# 修改配置文件redis.conf

vim /usr/local/redis/etc/redis.conf

主机配置

bind 0.0.0.0      #将bind127.0.0.1注释掉 或者改成 bind 0.0.0.0

port 6379        #改变其服务端口为6379

daemonize yes   #修改服务为后台运行

#指定不同的pid文件，注意三份配置文件不同。

pidfile /usr/local/redis/redis.pid

#指定log日志路径，自己配，要求不同。

logfile "/usr/local/redis/logs/redis.log"  

#这个指定rdb文件和aof文件的路径配置，要求改成不同。

dir /usr/local/redis/data

# 密码设置

masterauth 123  #从服务到主服务的认证密码（三台都配置）

requirepass 123  #客户端访问需要密码验证（三台都配置）

从机配置

#主服务这句话注释，从服务配置的两台需要开启。配置主服务的ip的port。

replicaof 192.168.221.20 6379

2.3、启动服务

分别启动三台主机的redis服务器端服务

./bin/redis-server ./etc/redis.conf

ps -ef|grep redis

分别启动三台主机客户端服务

./bin/redis-cli

# 查看主从的从属信息

127.0.0.1:6379> info replication

# 如果从服务器没有变成从服务，就手动设置从属

127.0.0.1:6379> slaveof 192.168.221.20 6379

# 关闭从属功能

127.0.0.1:6379> slaveof no one

# 转而对新服务器进行同步

127.0.0.1:6379> slaveof host port(比如：slaveof 192.168.221.30 6379)

三、设置单哨兵（在主服务器上）

# 备份配置文件

[root@localhost /]#cp /usr/local/src/redis-6.2.14/sentinel.conf /usr/local/redis/etc/sentinel.conf

# 进入etc目录

[root@localhost /]#cd /usr/local/redis/etc/

# 排除哨兵配置文件里的注释信息（如果没注释大约在第84行）

[root@localhost etc]#grep -Ev "^$|^#" /usr/local/src/redis-6.2.14/sentinel.conf > /etc/redis/sentinel.conf

# 编辑哨兵配置文件

[root@localhost etc#vim sentinel.conf

++++++++++++++++++++++++++++++++

pidfile "/var/run/redis-sentinel.pid"

logfile "/usr/local/redis/logs/sentinel.log"

dir "/usr/local/redis/data"

sentinel monitor mymaster 192.168.221.20 6379 1    # mymaster是监控主数据的名称，命名时可以使用大小写字母和“.-_”符号；后面是主机IP、端口号和哨兵的数量，少数服从多数的命令

sentinel down-after-milliseconds mymaster 10000

sentinel failover-timeout mymaster 15000

++++++++++++++++++++++++++++++++

# 返回到redis目录里

[root@localhost etc]# cd ../

# 启动哨兵实时查看情况

[root@localhost redis]# ./bin/redis-sentinel ./etc/sentinel.conf  或者  ./bin/redis-server ./etc/sentinel.conf --sentinel

从机宕机

[[root@localhost bin]# cd

[root@localhost ~]# /etc/init.d/redis stop

Stopping Redis...

Redis stopped.

# 哨兵认为主观宕机

[root@localhost ~]# /etc/init.d/redis start

Starting Redis...

Redis started.

# 哨兵取消主观宕机，检测到192.168.221.30重启/恢复上线

# 192.168.221.30重新同步为从节点

主机宕机

[root@localhost redis]# cd

[root@localhost ~]# /etc/init.d/redis stop

Stopping Redis...

Redis stopped.

# 哨兵主观+客观宕机

（达到法定票数，这里quorum 1/1表示1个哨兵同意即可）

# 进入新的 “纪元”（类似选举轮次），保障故障转移流程有序

# 尝试执行故障转移，选主从节点重新挂载

# 哨兵集群选举出“主导哨兵”，由它主导后续故障转移操作

# 把一个从节点选为新的主节点

# 其他从节点重新挂载新的主节点

# 测试哨兵连接

redis-cli -p 26379 sentinel masters

# 通过哨兵获取当前主节点的IP和端口

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

四、多哨兵连接（一主两从都配置）

# 接单哨兵结尾的192.168.221.40变为主节点开始：

# 修改主节点配置文件：

vim /etc/redis/redis.conf

++++++++++++++++++++++++++++++++++++++++++++++++++

bind 0.0.0.0

protected no         # 关闭加密保护 否则从节点无法连接

daemonize yes        # 开启后台模式将no改为yes

timeout 300 # 连接超时时间

port 6379            # 端口号

logfile "/usr/local/redis/logs/redis.log"     # 存放日志

pidfile /usr/local/redis/redis.pid           # 定义pid文件

dbfilename dump.rdb

dir /usr/local/redis/data                  # 用于存放数据（目录需提前创建）

save 3600 1

save 300 100

save 60 10000                          # snapshot触发的时机

stop-writes-on-bgsave-error yes          # 当snapshot时出现错误无法继续时，阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等

rdbcompression yes                     # 启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间

appendonly yes                         # 开启aof功能,只有在“yes”下，aof重写/文件同步等特性才会生效

++++++++++++++++++++++++++++++++++++++++++++++++++

# 修改从节点配置文件:

vim /etc/redis/redis.conf

+++++++++++++++++++++++++++++++++

replicaof 192.168.221.40 6379     ##添加 master IP和端口（注意：老版本的redis是搜索 slaveof 有些许区别）

+++++++++++++++++++++++++++++++++

启动测试

测试

##-->master节点操作

/etc/init.d/redis restart

127.0.0.1:6379> ping

PONG

127.0.0.1:6379> set name jack

OK

127.0.0.1:6379> get name

"jack"

##查看连接状态

127.0.0.1:6379> info replication

# Replication

role:master

connected_slaves:2  ##两个从节点

slave0:ip=192.168.8.12,port=6379,state=online,offset=6535,lag=0

slave1:ip=192.168.8.13,port=6379,state=online,offset=6535,lag=0

##-->从节点操作

/etc/init.d/redis restart

127.0.0.1:6379> ping

PONG

127.0.0.1:6379> get name

"jack"

##查看连接状态

127.0.0.1:6379> info replication

# Replication

role:slave

master_host:192.168.221.40

master_port:6379

master_link_status:up

# 排除哨兵配置文件里的注释信息并把它生成一个新文件（如果不注释，大约在第84行，需要提前备份一个新的配置文件cp /usr/local/src/redis-6.2.14/sentinel.conf /usr/local/redis/sentinel.conf）

[root@localhost ~]#grep -Ev "^$|^#" /usr/local/src/redis-6.2.14/sentinel.conf > /usr/local/redis/sentinel.conf

# 编辑哨兵配置文件

[root@localhost ~]#vim /usr/local/redis/sentinel.conf

++++++++++++++++++++++++++++++++++++++++++++++++++

port 26379

protected-mode no

daemonize yes

pidfile /var/run/redis-sentinel.pid

logfile "/usr/local/redis/logs/sentinel.log"

dir /tmp

sentinel monitor mymaster 192.168.221.40 6379 2

sentinel down-after-milliseconds mymaster 30000

acllog-max-len 128

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

sentinel deny-scripts-reconfig yes

SENTINEL resolve-hostnames no

SENTINEL announce-hostnames no

++++++++++++++++++++++++++++++++++++++++++++++++++

保存退出

# 将配置文件发送到另外两台服务器

scp /usr/local/redis/sentinel.conf 192.168.221.20:/usr/local/redis/

yes

输入20的密码

scp /usr/local/redis/sentinel.conf 192.168.221.30:/usr/local/redis/

yes

输入30的密码

# 如需查看是否一致，可以在另外两台输入

cat /usr/local/redis/sentinel.conf   一致则说明发送成功

# 启动测试（三台机器均启动）

## 启动哨兵

cd /usr/local/redis/

redis-sentinel sentinel.conf

## 动态查看

tail -f /usr/local/redis/logs/sentinel.log

Ctrl+C退出

##主节点

[root@localhost redis]# redis-cli

127.0.0.1:6379> info replication

# Replication

role:master

connected_slaves:2

slave0:ip=192.168.221.20,port=6379,state=online,offset=547559,lag=0

slave1:ip=192.168.221.30,port=6379,state=online,offset=547559,lag=0

## 停止主节点redis（后面要有耐心，多等待一会儿）

127.0.0.1:6379> exit

[root@redis-master redis]# netstat -tnlp

# 会出现

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    

tcp        0      0 0.0.0.0:26379           0.0.0.0:*               LISTEN      15630/redis-sentine

tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      14351/redis-server  

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      743/rpcbind         

tcp        0      0 0.0.0.0:6032            0.0.0.0:*               LISTEN      1562/proxysql       

tcp        0      0 0.0.0.0:6033            0.0.0.0:*               LISTEN      1562/proxysql       

tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      1698/dnsmasq        

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1116/sshd           

tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1119/cupsd          

tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1622/master         

tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      13696/sshd: root@pt

tcp        0      0 127.0.0.1:6011          0.0.0.0:*               LISTEN      15015/sshd: root@pt

tcp6       0      0 :::26379                :::*                    LISTEN      15630/redis-sentine

tcp6       0      0 ::1:6379                :::*                    LISTEN      14351/redis-server  

tcp6       0      0 :::111                  :::*                    LISTEN      743/rpcbind         

tcp6       0      0 :::22                   :::*                    LISTEN      1116/sshd           

tcp6       0      0 ::1:631                 :::*                    LISTEN      1119/cupsd          

tcp6       0      0 ::1:25                  :::*                    LISTEN      1622/master         

tcp6       0      0 ::1:6010                :::*                    LISTEN      13696/sshd: root@pt

tcp6       0      0 ::1:6011                :::*                    LISTEN      15015/sshd: root@pt

tcp6       0      0 :::33060                :::*                    LISTEN      1595/mysqld         

tcp6       0      0 :::3306                 :::*                    LISTEN      1595/mysqld         

[root@localhost redis]# kill 14351

##--新的主节点机器192.168.221.30（到时候两台都登陆）

127.0.0.1:6379> redis-cli

127.0.0.1:6379> info replication

# 出现下面这个说明正在转换身份

Error: Server closed the connection

# Replication

role:master

connected_slaves:1

slave0:ip=192.168.221.20,port=6379,state=online,offset=738791,lag=1

##已实现故障转移

##--启动故障机器192.168.221.40

[root@localhost redis]# /etc/init.d/redis start

[root@localhost redis]# redis-cli

127.0.0.1:6379> info replication

# Replication

role:slave

master_host:192.168.221.30

master_port:6379

master_link_status:up     #恢复的机器会自动加入集群降为从节点

redis集群搭建（一主两从三哨兵）完整版带验证报告
qq_39323945的博客
07-18 3171
基于docker-compose搭建主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性。redis.conf可以在redis.io官网下载对应版本的redis.conf文件，但需要注意修改的地方在下面标出。拉取镜像5.0.12在/usr/local/docker/redis对应的目录启动redis服务器下可以查看是否启动成功。两台服务器也同样可以根据上述命令进行查看。如果启动不成功可以通过查看到对应的启动日志，方便我们定位错误。.........
Redis集群架构搭建——主从、哨兵、集群
沐雨橙风ιε的博客
09-22 1958
Redis集群架构搭建——主从、哨兵、集群
Redis数据库——主从、哨兵、群集
一坨小橙子的博客
04-04 1610
Redis主从复制、哨兵模式Sentinel、群集模式Cluster详解及搭建
linux—redis集群搭建（主从哨兵）
m0_56353506的博客
04-24 1509
配置哨兵的作用是确保 Redis 系统的高可用性。Redis Sentinel（哨兵）是一个用于监控和管理 Redis 集群的自动化系统，它可以检测 Redis 主节点和从节点的故障，并在需要时进行自动故障转移和节点恢复。而有三个或更多的哨兵节点可以确保在大多数节点达成一致的情况下进行投票，增加了投票的可靠性。：多个哨兵节点可以分布在不同的服务器上，从而可以更好地监控 Redis 集群的各个节点。到了这里 就算是已经配置好了一个最基础的配置了 可以开启一个简单的redis服务了。
Redis——主从&哨兵配置
Lemon__ing的博客
06-08 1640
Redis 通过内存计算、灵活数据结构与分布式架构，重塑了高性能数据处理的范式，成为现代应用中缓解数据库压力、实现复杂逻辑的关键组件。单线程模型（6.0 前）通过多路复用处理并发请求，确保原子性操作，延迟低至微秒级，支撑 10W+ QPS 高并发场景。超越传统 KV 存储，提供集合运算、范围查询、排序等能力，直接实现排行榜（ZSet）、好友关系（Set）等场景。作为缓存层，将热点数据置于内存，减轻后端数据库压力，提升响应速度（如秒杀系统）。集群与哨兵模式保障服务连续性，满足企业级可用性要求。
搭建redis主从集群、哨兵集群
m0_38137988的博客
06-19 1085
创建主从集群和哨兵集群
redis数据库——————主从复制、哨兵模式、集群
m0_63761361的博客
04-22 323
目录 一、Redis主从复制 主从复制流程 Redis主从复制的作用 二、哨兵模式 1、哨兵模式集群架构 2、哨兵模式主要功能 3、哨兵监控整个系统节点的过程​ 4、主观下线 5、客观下线 6、master 选举 7、故障迁移 8、优点与缺点 三、Cluster群集 1、集群的作用 2、Redis集群的数据分片 四、实验一（主从复制） 五、实验二（哨兵模式） Redis 集群部署步骤 一、Redis主从复制 通过持久化功能，redis保证...
redis高可用——主从复制、哨兵模式、cluster集群
Breeze_nebula的博客
09-08 1158
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。主从切换技术的方法是，当服务器宕机后，需要手动一台从机切换为主机，这需要人工干预，不仅费时费力而日还会造成一段时间内服务不可用。为了解决主从复制的缺点，就有了哨兵机制。
Redis 集群进阶：主从、哨兵与 Cluster 详解
qq_57828911的博客
11-05 966
场景推荐方案小项目，数据量小，能接受手动恢复主从复制中等规模，要求自动故障转移，写压力不大哨兵模式大规模，高并发写，数据量大（>50GB）最后一句大实话：别为了“高大上”硬上 Cluster！很多业务用哨兵 + 读写分离 + 缓存预热，完全够用。先压测，再扩容，别让架构提前复杂化。
浅谈Redis集群架构与主从架构
~
08-03 1799
我们要看业务选择不同的Redis方案，当然，Redis集群还可以搭配Redis主从一起使用，我们可以在某一个集群节点上配置一套主从模型。Redis 集群将数据自动分片到多个 Redis 节点，Redis 集群还在分区期间提供一定程度的可用性，当某些节点发生故障或无法通信时，Redis集群能够继续运行。Redis集群的主从模型选举主节点和Redis哨兵选举出主节点非常相似，但大家不要搞混了，Redis集群中并没有哨兵的概念。Redis主从对数据的完整性更看重，Redis主从节点都保存了完整的一套数据库状态。
Redis集群-Redis安装、Redis主从复制、哨兵、Redis集群
12-25
本文将对Redis集群进行详细的介绍，包括Redis安装、主从复制、哨兵和集群的配置和实现。 一、Redis安装 在Windows环境中，我们可以使用Redis的安装程序来安装Redis。在实际的企业环境中，我们通常使用Linux环境来...
02-Redis持久化、主从与哨兵架构详解.zip
11-18
通过理解并熟练掌握Redis的持久化、主从复制和哨兵架构，开发者可以构建出稳定、高效、容错的Redis集群，为应用程序提供强大的数据存储与访问支持。在实际应用中，根据业务需求和性能指标，灵活选择和调整这些特性，...
docker-compose redis主从哨兵 redis多节点高可用 redis集群高可用
04-12
3. **Redis集群高可用**：Redis集群通过分片（Sharding）和槽区（Slot）分配，将数据分散到多个节点上，这样即使部分节点故障，其他节点仍能提供服务。Docker Compose配置中，我们需要定义多个集群节点，每个节点都...
Redisson的multilock原理
最新发布
2401_83708850的博客
11-24 259
Redisson 的 RedissonMultiLock（联合锁）是用来同时持有多把独立锁，从而兼顾多资源一致性的“打包锁”。它的工作原理可以分成“加锁”“释放”“故障处理”三个阶段。
Redis 集群模式优化和备份
小五
11-21 51
本文针对Rocky Linux 9.5系统（16G内存、8核CPU、SSD存储）提出多项调优建议。内存管理方面建议降低vm.swappiness至10，调整脏页写回参数；文件系统建议提高最大文件描述符数；网络参数优化包括增加TCP连接队列和缓冲区大小；CPU调度推荐使用performance模式；I/O子系统建议为SSD选用noop调度器。同时提供了包含内存、网络、安全等参数的完整sysctl配置模板，强调需根据实际负载测试调整参数，并注意过度调优可能导致系统不稳定或影响SSD寿命。
Redis如何设置密码
2509_94006941的博客
11-20 914
为什么redis要设置密码？内网环境可以不设置密码，但是个人服务器，以及线上公网服务器就有必要设置密码了。昨天我查看了一下minio的redis事件通知，查看redis的key时发现多了几个奇怪的key。然后我猜想应该是挖矿病毒。如下面所示：这样就将定时任务和脚本注入到了我们机器当中，就会开始执行 init.sh 脚本backup1 "backup2 "backup3 "backup4 "公网的redis一定要设置密码阿，不要不设置密码，设置密码就一个指令，非常容易，可不要偷懒噢。
Redis的安装教程（Windows+Linux）【超详细】
2509_94004515的博客
11-21 879
点这里Redis是开放源代码（BSD许可）的内存中数据结构存储，用作数据库，缓存和消息代理。Redis提供数据结构，例如 字符串，哈希，列表，集合，带范围查询的排序集合，位图，超日志，地理空间索引和流。Redis具有内置的复制，Lua脚本，LRU逐出，事务和不同级别的磁盘持久性，并通过以下方式提供高可用性：Redis Sentinel和Redis Cluster自动分区。您可以 对这些类型运行原子操作，例如追加到字符串；在哈希中增加值;将元素推送到列表;计算集的交， 并与差;或获得排序集中排名最高的成员。
golang 设计高并发之引入redis
shao.bing的专栏
11-23 118
核心依赖：Redis的原子命令HINCRBYZINCRBY）是高并发安全的关键，避免竞态条件。数据结构选型：Hash存用户维度数据，ZSet天然支持排名，是抽奖场景的最优组合。性能优化：连接池、限流、Pipeline等手段可显著提升系统在高并发下的稳定性和响应速度。这套方案能轻松支撑每秒数万次的抽奖请求，且排名实时更新，完全满足高并发抽奖场景的需求。
redis集群之主从、哨兵、分片
03-21
<think>嗯，用户想了解Redis集群中的主从复制、哨兵机制和分片的概念及实现方式。首先，我需要回忆一下这些技术的基本原理和它们之间的关系。 主从复制，我记得是Redis实现高可用性的基础。主节点负责写操作，从节点复制主节点的数据，处理读请求。引用中提到主从复制是单向的，从节点只能有一个主节点。需要说明复制的流程，比如全量复制和增量复制的区别，以及如何配置。用户提供的引用[2]和[3]里提到主从架构的优势，比如数据冗余和高可用性，这些需要整合到回答中。 然后是哨兵模式。主从复制如果主节点挂了，需要手动切换，而哨兵可以自动监控和故障转移。哨兵的作用包括监控、通知、自动故障转移和配置提供。要解释哨兵如何检测主节点下线，如何选举新的主节点，以及如何通知客户端。这里可能需要提到主观下线和客观下线的概念，但用户提供的引用中没有详细说明，所以是否需要补充？不过根据用户的问题，可能需要简要说明。 接下来是分片和集群模式。分片是将数据分布到多个节点，Redis Cluster是官方解决方案。需要解释哈希槽的概念，数据如何分配到16384个槽，节点如何负责这些槽。还要提到客户端重定向和节点间通信，比如Gossip协议。用户提到分片原理，所以需要详细说明数据分片的机制，可能涉及一致性哈希或者Redis的特定实现。 现在，需要确保回答符合用户的要求：结构清晰，分点说明每个概念的定义、原理、实现方式、优缺点。同时，要引用提供的参考文献中的内容，比如引用[2]和[3]关于主从复制的部分，引用[1]可能涉及配置文件的设置，但用户的问题更多是理论上的，所以可能引用较少。 需要检查是否有遗漏的部分，比如主从复制的配置步骤，哨兵的选举过程，集群模式的数据迁移等。但用户可能不需要过于详细的步骤，而是概念和原理层面的解释。另外，用户提到的分片原理是否和集群模式是一回事，需要明确说明Redis Cluster是分片的实现方式。 可能需要注意术语的准确性，比如分片（Sharding）和集群（Cluster）的关系，确保不混淆。此外，回答中需要包含用户提供的引用内容，例如主从复制的数据冗余优势来自引用[2]，主节点可写从节点只读来自引用[3]。 最后，生成相关问题时要围绕这三个技术点，可能涉及比较、原理深入、应用场景等。比如主从复制与集群的区别，哨兵如何选举，分片的数据分布方式等。 总结步骤：分三个大点，每个点下分定义、原理、实现、优缺点。使用引用标注来源。确保LaTeX格式正确，行内公式用$，独立公式用$$。最后生成相关问题。</think>### Redis集群架构解析 #### 一、主从复制 **定义** 主从复制是通过数据单向复制实现读写分离的机制，主节点（Master）负责写操作，从节点（Slave）通过复制主节点数据提供读服务[^2][^3]。 **原理** 1. **全量复制**：从节点首次连接主节点时，主节点生成RDB快照文件并传输给从节点，从节点加载数据完成初始化同步。 2. **增量复制**：后续主节点将写命令通过`replication buffer`异步发送给从节点，保持数据一致性。 **实现方式** - 配置从节点：在从节点配置文件中添加`replicaof <master-ip> <master-port>`[^1]。 - 验证：通过`INFO replication`命令查看主从关系。 **优缺点** - 优点：读写分离提升性能；数据冗余提高可用性[^2]。 - 缺点：主节点故障需手动切换；写操作仍为单点瓶颈。 --- #### 二、哨兵模式（Sentinel） **定义** 哨兵模式是主从复制的升级方案，通过独立进程监控主节点状态，实现自动故障转移。 **原理** 1. **监控**：哨兵每秒向主/从节点发送`PING`命令检测存活状态。 2. **故障判定**：若主节点未响应，哨兵集群通过投票机制将其标记为**客观下线**。 3. **选举新主**：根据优先级、复制偏移量等规则，从从节点中选举新主节点。 4. **切换通知**：更新客户端连接至新主节点。 **实现方式** - 配置文件：启动哨兵进程需配置`sentinel monitor <master-name> <ip> <port> <quorum>`。 - 示例： ```conf sentinel monitor mymaster 127.0.0.1 6379 2 ``` **优缺点** - 优点：自动化故障恢复；支持高可用。 - 缺点：配置复杂；扩容需手动调整。 --- #### 三、分片与集群模式（Cluster） **定义** 分片（Sharding）通过数据分区实现水平扩展，Redis Cluster是其官方分布式解决方案。 **原理** 1. **哈希槽分配**：将数据划分为16384个槽（slot），每个节点负责部分槽。 $$ \text{slot} = \text{CRC16}(key) \mod 16384 $$ 2. **节点通信**：采用Gossip协议交换节点状态信息。 3. **重定向机制**：客户端访问错误节点时，返回`MOVED`指令引导至正确节点。 **实现方式** - 集群配置： ```bash redis-cli --cluster create <node1-ip:port> <node2-ip:port> ... --cluster-replicas 1 ``` - 数据迁移：通过`CLUSTER ADDSLOTS`动态分配槽。 **优缺点** - 优点：支持海量数据；无中心化架构。 - 缺点：跨槽事务不支持；运维复杂度高。 --- ### 对比总结 | 方案 | 适用场景 | 数据一致性 | 扩展性 | |--------------|----------------------|------------|--------| | 主从复制 | 读写分离、备份 | 最终一致 | 垂直 | | 哨兵模式 | 高可用、自动故障转移 | 最终一致 | 有限 | | 集群模式 | 大规模数据、高并发 | 分区一致 | 水平 | ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值