Redis高可用技术介绍及部署（主从复制、集群、哨兵）

最新推荐文章于 2023-05-23 12:25:38 发布
最新推荐文章于 2023-05-23 12:25:38 发布
阅读量239 收藏
点赞数 1
分类专栏： redis 文章标签： 分布式 数据库 redis 运维 linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/bugggggggg/article/details/116651963
版权

文章目录

一、Redis高可用技术

在Redis中，实现高可用的技术主要包括持久化、主从复制、哨兵和集群

  • 主从复制：是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。
  • 哨兵:在主从复制的基础上，哨兵实现了自动化的故障恢复。缺陷﹔写操作无法负载均衡;存储能力受到单机的限制。
  • 集群﹔通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

二、Redis主从复制

  • 简而言之就是将一台Redis服务器的数据备份到一台或多台Redis服务器，备份的服务器为主服务器，接收备份数据的服务器则为从服务器，备份是单向的，主>>>>从 从—xxx–主
  • 一主可以有多从，但一丛只能有一主
1. 主从复制的作用
  • 高可用架构基础
  • 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
  • 故障恢复：在主从复制基础上，配置MHA，当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余
  • 负载均衡：单纯的主从复制只能提供冗余备份作用，但可以在此基础上配置读写分离，来将读操作和数据修改操作分离到不同服务器，以此实现负载均衡
2. 主从复制流程

Redis主从复制流程跟MySQL的是不一样的

  1. 若启动一个Slave机器进程，则它会向Master机器发送一个“sync command”命令，请求同步连接。

  2. 无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中。

  3. 后台进程完成缓存操作之后，Maste机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。

  4. Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个Slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。

3. 搭建主从复制
  • 实验服务器为一主两从（最低搭配）都只需安装redis即可
  • 软件包Redis介绍那篇博客，有需要自取

安装Redis（三台相同）步骤略过，在Redis介绍那篇博客里也有

1. 修改Master节点配置文件

修改 70和700行即可 其他可保持默认

vim /etc/redis/6379.conf
bind 0.0.0.0						#70行，修改bind 项，0.0.0.0监听所有网段
daemonize yes						#137行，开启守护进程
logfile /var/log/redis_6379.log		#172行，指定日志文件目录
dir /var/lib/redis/6379				#264行，指定工作目录
appendonly yes						#700行，开启AOF持久化功能

/etc/init.d/redis_6379 restart      #重启
2. 修改Slave节点配置文件（两台相同）
vim /etc/redis/6379.conf
bind 0.0.0.0						#70行，修改bind 项，0.0.0.0监听所有网卡
daemonize yes						#137行，开启守护进程
logfile /var/log/redis_6379.log		#172行，指定日志文件目录
dir /var/lib/redis/6379				#264行，指定工作目录
replicaof 192.168.100.133 6379		#288行，指定要同步的Master节点IP和端口
appendonly yes						#700行，开启AOF持久化功能


/etc/init.d/redis_6379 restart

在这里插入图片描述

3. 验证主从复制
进入redis输入 info replication 查看信息或者直接输入 redis-cli info replication 同样的命令

tail -f /var/log/redis_6379.log   查看master服务器日志

在这里插入图片描述
在这里插入图片描述
至此，Redis主从复制搭建完成，相比于MySQL主从复制，较为简单

三、Redis哨兵

  • 哨兵(sentinel)：是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master 并将所有 Slave 连接到新的 Master。并将故障转移的结果发送给客户端；所以整个运行哨兵的集群的数量不得少于3个节点。
  • 故其作用为在主从复制的基础上，通过监控各个服务器，实现故障转移功能
1.哨兵模式结构

哨兵结构由两部分组成，哨兵节点和数据节点：

  • 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
  • 数据节点：主节点和从节点都是数据节点。

切换机制：

  • 哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上都需要部署哨兵模式，哨兵模式会监控所有的 Redis 工作节点是否正常，当 Master 出现问题的时候，因为其他节点与主节点失去联系，因此会投票，投票过半就认为这个 Master 的确出现问题，然后会通知哨兵间，然后从 Slaves 中选取一个作为新的 Master。

  • 需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

主客观下线解释：

主观下线（SDOWN:subjectively down）

  • 即当前sentinel实例认为某个redis服务为”不可用”状态.

客观下线（ODOWN:objectively down）

  • 即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制.
2. 哨兵模式配置

哨兵模式不需要独立软件包，基于Redis主从同步基础上修改配置文件进行配置即可

vim /opt/redis-5.0.7/sentinel.conf

protected-mode no								#17行，取消注释，关闭保护模式
port 26379										#21行，Redis哨兵默认的监听端口
daemonize yes									#26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log"					#36行，指定日志存放路径
dir "/var/lib/redis/6379"						#65行，指定数据库存放路径

sentinel monitor mymaster 192.168.100.133 6379 2	#84行，修改 指定该哨兵节点监控192.168.100.133:6379这个主节点，
#该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000	#113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000		#146行，故障节点的最大超时时间为180000（180秒）

在这里插入图片描述

3. 启动哨兵模式

先启动master上的 再启动slaves服务器上的

cd /opt/redis-5.0.7/

redis-sentinel sentinel.conf &  后台启动哨兵

在这里插入图片描述
在这里插入图片描述

4. 模拟故障恢复

在这里插入图片描述

查看哨兵信息 和master日志
redis-cli -p 26379 INFO Sentinel

tail -f /var/log/sentinel.log

在这里插入图片描述

5. 故障转移过程

  • 故障转移是由 sentinel 领导者节点来完成的(只需要一个sentinel节点),关于 sentinel 领导者节点的选取也是每个 sentinel 向其他 sentinel 节点发送我要成为领导者的命令,超过半数sentinel 节点同意,并且也大于quorum ,那么他将成为领导者,如果有多个sentinel都成为了领导者,则会过段时间在进行选举.

  • sentinel 领导者节点选举出来后,会通过如下几步进行故障转移:

一、从 slave 节点中选出一个合适的 节点作为新的master节点.这里的合适包括如下几点:

  • 选择 slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续下一步判断.

  • 选择复制偏移量最大的 slave 节点(复制的最完整),如果存在则返回,不存在则继续.

  • 选择runId最小的slave节点(启动最早的节点)

二、对上面选出来的 slave 节点执行 slaveof no one 命令让其成为新的 master 节点.

三、向剩余的 slave 节点发送命令,让他们成为新master 节点的 slave 节点,复制规则和前面设置的 parallel-syncs 参数有关.

四、更新原来master 节点配置为 slave 节点,并保持对其进行关注,一旦这个节点重新恢复正常后,会命令它去复制新的master节点信息.(注意:原来的master节点恢复后是作为slave的角色)

四、集群模式

  • Redis 3.0开始引入的分布式存储方案
  • 集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。
  • Cluster 群集由多个redis服务器组成的分布式网络服务群集，群集中有多个master主节点，每个主节点都可读可写，节点之间会互相通信，两两相连，redis群集无中心节点
  • 群集进行故障转移的方法和 redis sentinel 进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点复制进行的，所以群集不必另外使用 redis sentinel
1. 集群作用
  • 高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务
  • 数据分片：集群将数据分散到多个节点（分布式），一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。
    Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。

关于数据分片

Redis集群有16384个哈希槽（编号0-16383）

  • 以3个节点组成的集群为例
    节点A包含0到5460号哈希槽
    节点B包含5461到10922号哈希槽
    节点C包含10923到16383号哈希槽

每个Key通过CRC16校验后对16384取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

集群的主从复制解读：

  • 例如上述的A节点挂了，那么就会有0-5460哈希槽失效，这时若没有A的从服务器来接管 那么整个集群就会不可用，所以需要给每个主节点最少分配一个从节点，用来被集群推举接替工作
2. 集群模式搭建
  • 因为群集至少三台主服务器。所以最低配置为六台（三主三从）
  • 分别安装Redis即可

嫌麻烦的可以复制这个安装Redis的shell脚本

这个脚本是编译安装，执行前将软件包放到/opt目录下即可

#!/bin/bash
systemctl stop firewalld
setenforce 0
yum install -y gcc gcc-c++ make
yum -y install expect
cd /opt
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install

cd /opt/redis-5.0.7/utils
/usr/bin/expect <<EOF
spawn ./install_server.sh
expect "instance" {send "\r"} 
expect "config" {send "\r"}
expect "log" {send "\r"}
expect "data" {send "\r"}
expect "executable" {send "/usr/local/redis/bin/redis-server\r"}
expect "abort" {send "\r"}
expect eof
EOF

ln -s /usr/local/redis/bin/* /usr/local/bin/
/etc/init.d/redis_6379 restart

sed -i '/bind 127.0.0.1/c bind 0.0.0.0' /etc/redis/6379.conf
sed -i 's/appendonly no/appendonly yes/' /etc/redis/6379.conf

/etc/init.d/redis_6379 restart
/etc/init.d/redis_6379 status
netstat -natp | grep redis
1. 修改节点配置文件
  • 我这里为了实验省事，就用了三台虚拟机，分别配置两张网卡模拟两个服务器
  • 首先进入redis目录 创建集群目录
  • 【若是每台服务器分别只承担一个节点，只创建一个目录即可，并且不用修改端口也可以（默认6379）；但是如果像我这种一台服务器上做两个节点或多个的 就需要创建同数量的目录用来提供不同服务，端口和文件名也要有区分，以免冲突】
cd /etc/redis/

mkdir -p redis-cluster/redis6379  创建集群节点目录

cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis6379/   拷贝配置文件
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis6379/   拷贝命令

这里为第一个服务器上的配置（192.168.100.133 192.168.100.36两个节点）
在这里插入图片描述

cd /etc/redis/redis-cluster/redis6371
vim redis.conf

bind 192.168.100.133					#69行，修改bind项，监听自己的IP
protected-mode no						#88行，修改，关闭保护模式
port 6371								#92行，修改，redis监听端口，
daemonize yes							#136行，以独立进程启动
appendonly yes							#699行，修改，开启AOF持久化
cluster-enabled yes						#832行，取消注释，开启群集功能
cluster-config-file nodes-6379.conf		#840行，取消注释，群集名称文件设置，无需修改
cluster-node-timeout 15000				#846行，取消注释群集超时时间设置

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
其他节点都是几乎相同的配置，只有监听地址和端口不一样（都为自己的节点ip和端口）

为节省时间可以用scp远程复制

scp /etc/redis/redis-cluster/redis6371/redis.conf root@192.168.100.134:/etc/redis/redis-cluster/redis6373

仅供参考 目录名文件名自行修改、复制过去之后  把文件的监听ip和端口修改下即可

在这里插入图片描述

2. 所有节点启动redis
cd /etc/redis/redis-cluster/redis6371/
redis-server redis.conf

cd /etc/redis/redis-cluster/redis6372/
redis-server redis.conf

cd /etc/redis/redis-cluster/redis6373/
redis-server redis.conf
..........
..................
..........................各个节点都重复此操作即可

在这里插入图片描述

3. 启动集群（任何一个节点输入都可以）
redis-cli --cluster create 192.168.100.133:6371 192.168.100.136:6372 192.168.100.134:6373 192.168.100.137:6374 192.168.100.135:6375 192.168.100.138:6376 --cluster-replicas 1

在这里插入图片描述

4. 查看节点哈希槽及测试

在这里插入图片描述
在这里插入图片描述

bugggggggg
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
【Redis学习3】Redis四种模式之主从复制
LCreator的博客
03-07 805
Redis四种模式的主从复制模式的技术学习
Redis主从复制（Master&Slave）
FANYULAN201510的博客
06-09 204
什么是Redis主从赋值（Master&Slave）? 1、主从复制：主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为 主，Slave以读为主。 　 2、主要作用：1）、读写分离2）、容灾恢复 Redis主从复制的配置使用（Windwos下） 1、安装主服务器，打开排至文件绑定ip ...
redis的主从复制、哨兵、集群
sj199728的博客
05-23 528
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。主从关系确定好后，开启从节点时，会发送一个sync的同步命令给主节点，主节点接收到后会把redis内存中的数据以快照的方式压缩保存成rdb文件，在这个期间如果有新的数据就会进行缓存保存，当rdb文件生成后会和缓存文件一起发送给从节点，从节点进行保存，这就完成了主从复制。
【Redis6--4】Redis持久化，主从复制，哨兵，集群
m0_64337991的博客
01-28 1595
目录 1.Redis持久化之RDB 1.1是什么 1.2备份是如何执行的 1.3Fork ​​​​​​​1.4RDB持久化流程 ​​​​​​​1.5dump.rdb文件的备份 ​​​​​​​1.6优势 1.7劣势 1.8总结 2.Redis持久化之AOF 2.1是什么 2.2​​​​​​​AOF持久化流程 ​​​​​​​2.3AOF同步频率设置 2.4​​​​​​​Rewrite压缩 1.是什么： 2.重写原理，如何实现重写 3.重写流程 2.5 优势 2.6劣势.
redis集群之主从复制
qq_39329062的博客
07-13 776
主从复制
Redis集群-Redis安装、Redis主从复制、哨兵、Redis集群
最新发布
12-25
Redis集群是Redis的一种高可用性解决方案，通过主从复制、哨兵和集群三大技术模块来实现高可用性和可扩展性。本文将对Redis集群进行详细的介绍，包括Redis安装、主从复制、哨兵和集群的配置和实现。 一、Redis安装 ...
docker-compose redis主从哨兵 redis多节点高可用 redis集群高可用
04-12
1. **Redis主从复制**：这是基础的高可用方案，通过将数据实时同步到一个或多个从节点，即使主节点故障，从节点也能无缝接管服务。在Docker Compose文件中，我们需要定义三个服务，一个为主节点，两个为从节点，并...
Redis高级特性解析：持久化、主从复制与哨兵机制全面探讨
12-14
其高级特性包括持久化、主从复制和哨兵机制，这三大特性是保障 Redis 高可用性和数据安全的关键。 **持久化**： Redis 提供了两种持久化方式：RDB（Redis Database）和 AOF（Append Only File）。RDB 模式通过定时...
Redis高可用之哨兵+主从模式总结
04-29
主从模式是 Redis 提供的一种基础的高可用策略，它通过数据复制来实现读写分离。主节点负责处理写操作，而从节点则处理读操作，从而分散负载，提高系统的处理能力。主节点的数据会实时同步到从节点，确保数据的一致...
【中间件篇-Redis缓存数据库06】Redis主从复制/哨兵 高并发高可用
11-13
总结，Redis的主从复制和哨兵系统是构建高并发、高可用缓存数据库的关键技术。主从复制提供了数据备份和读写分离，哨兵系统则确保了在主节点故障时能自动进行故障恢复，两者结合使用，可以显著提升Redis集群的稳定性...
Redis（主从复制、哨兵模式、集群）概述及部署
愿你成为自己喜欢的模样，不抱怨，不将就，有自由，有光芒！
02-25 3157
文章目录一、Redis主从复制1、Redis主从复制的概念2、Redis主从复制的作用3、Redis主从复制的流程4、Redis主从复制的搭建1、环境配置/安装包2、安装Redis（所有主机）3、修改Master节点Redis配置文件4、修改Slave节点Redis配置文件5、验证主从效果二、Redis 哨兵模式1、哨兵模式的原理2、哨兵模式的作用3、哨兵模式的结构4、哨兵模式的搭建1、环境配置2、修改 Redis 配置文件（所有节点操作）2、启动哨兵模式3、故障模拟4、验证结果三、Redis 群集模式1、
Redis集群的主从复制模型是怎么样的？
qqqq0199181的博客
06-15 2080
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品。
Redis主从复制、哨兵与集群架构详解
cj1561435010的博客
07-31 525
一、主从复制架构 1、主从复制架构说明        主从复制架构只能用来解决数据的冗余备份，只有master节点可以接受客户端的请求并执行写入操作，而slave节点仅仅做数据的同步，客户端无法将数据写入到从节点中。因为主从复制架构无法保证主节点宕机时的自动故障转移即高可用。 2、主从复制架构原理图 3、主从复制架构的搭建        在从节点的配置文件中增加下
基于Redis的主从复制、哨兵模式以及集群的使用，史上最详细的教程来啦~
smilehappiness的博客
07-19 930
创作不易，如果觉得这篇文章对你有帮助，欢迎各位老铁点个赞支持下呗，您的支持是我创作的最大动力！ 文章目录1 前言2 Redis的主从复制（master/slave）2.1 为什么要进行主从复制2.2 如何实现数据的自动同步更新2.3 Redis主从复制实现（一主多从架构）2.3.1 什么是主从复制2.3.2 实现Redis的主从复制2.3.3 主从复制的验证2.3.4 主从复制模式的容灾处理2.3.5 主从复制原理2.3.5.1 **全量复制**2.3.5.2 增量复制2.3.5.3 无硬盘复制2.3..
Redis 中的 复制（主从复制）
norang的博客
08-24 438
第18章 复制         复制功能是Redis提供的多机功能中最基础的一个，这个功能是通过主从复制（master-slave replication）模式实现的，它允许用户为存储着目标数据库的服务器创建出多个拥有相同数据库副本的服务器，其中存储 目标数据库的服务器被称为主服务器（master server），而存储数据库 副本的服务器则被称为从服务器（slave server，或者称为replica），如图18-1所示。
Redis 复制详解
pizicai007的博客
01-28 492
Redis 复制详解1. 复制配置1.1 建立复制1.2 断开复制1.3 安全性1.4 只读1.5 传输延迟2. 拓扑2.1 一主一从结构2.2 一主多从结构2.3 树状主从结构3. 复制原理3.1 复制过程3.2 数据同步3.3 全量复制3.4 部分复制   在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他机器，满足故障恢复和负载均衡等需求。Redis 也是如此，它为我们提供了复制功能，实现了相同数据的多个 Redis 副本。    1. 复制配置 1.1 建立复制   参与复制的 Re
redis的主从复制、哨兵模式和集群
zzn0109的博客
07-06 150
redis的主从、哨兵、集群
Redis 学习笔记（十二）Redis 复制功能详解
men_wen的博客
05-20 9161
Redis 复制(Replication)1. 复制介绍分布式数据库为了获取更大的存储容量和更高的并发访问量，会将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上。Redis为了解决单点数据库问题，会把数据复制多个副本部署到其他节点上，通过复制，实现Redis的高可用性，实现对数据的冗余备份，保证数据和服务的高度可靠性。2. 复制的建立建立复制的配置方式有三种。 在redis.co
Windows环境Redis高可用实践：主从复制与哨兵监控指南
"该资源主要介绍了如何在Windows环境下设置Redis的高可用性，包括主从复制和哨兵监控。提供了Redis 3.2.100版本的安装和配置步骤，以及相关的配置文件修改建议。" 在Windows环境中实现Redis的高可用性，主从复制和...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值