redis如何实现高可用【主从复制、哨兵机制】

原创itcats_cn 最后发布于2018-09-05 21:07:27 阅读数 5135 收藏
展开
实现redis高可用机制的一些方法:
保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。

主从复制的作用:数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。

redis主从复制原理
首先主从复制需要分为两个角色:master(主) 和 slave(从) ,注意:redis里面只支持一个主,不像Mysql、Nginx主从复制可以多主多从。

1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库(master)一类是从数据库(slave),主数据库可以进行读写操作,当发生写操作的时候自动将数据同步到从数据库,而从数据库一般是只读的,并接收主数据库同步过来的数据,一个主数据库可以有多个从数据库,而一个从数据库只能有一个主数据库。

2、通过redis的复制功能可以很好的实现数据库的读写分离,提高服务器的负载能力。主数据库主要进行写操作,而从数据库负责读操作。

主从复制全量同步的过程:见下图

Redis主从复制可以根据是否是全量分为全量同步和增量同步

Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。

全量同步过程:

1:当一个从数据库启动时,会向主数据库发送sync命令,

2:主数据库接收到sync命令后会开始在后台保存快照(执行rdb操作),并用缓存区记录后续的所有写操作

3:当主服务器快照保存完成后,redis会将快照文件发送给从数据库。

4:从数据库收到快照文件后,会丢弃所有旧数据,载入收到的快照。

5:   主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令。

6:   从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令。

增量同步的过程:

Redis增量复制是指slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。

增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。

Redis主从复制全量与增量同步的选择:

主从服务器刚刚连接的时候,会先进行全量同步;全同步结束后,再进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。

redis主从复制如何配置呢?
修改从服务器redis/conf中的redis.conf文件

修改IP地址和端口号为主服务器的IP和端口
slaveof 10.211.55.9 6379

masterauth 123456--- 如果主redis服务器配置了密码,则需要配置
只需要配置从服务器的redis.conf即可,主服务器无需配置。验证是否成功可以通过1、先登录主服务器redis-cli客户端,输入info。若role显示master、slave0能正常显示从服务器的ip,则表示主从服务配置成功,主从复制配置成功了,也同时实现了读写分离,不信?你看看试试看你的从服务器还能不能写入操作了?答案是:不能。从服务器只有读操作!

Redis哨兵机制
哨兵机制需要主从复制的支持。

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

·        监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

·        提醒(Notification):当被监控的某个Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

·        自动故障迁移(Automatic failover):当一个Master不能正常工作时,哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).

若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器,你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).

哨兵(sentinel) 的一些设计思路和zookeeper非常类似

单个哨兵(sentinel)

哨兵模式如何配置?
注意:哨兵机制是redis自带的功能,不需要接入第三方实现

实现步骤:                                                               哨兵机制端口号默认为26379

配置之前注意防火墙是否关闭

1.修改sentinel.conf配置文件(该文件存在于redis安装包根目录下)

注意:初次配置,不需要打开#sentinel monitor mymaster注释,因为后几行有默认当台服务器为主服务器

原配置:sentinel monitor mymaster 127.0.0.1 6379 2 通过这句来修改为:

sentinel monitor mymaster  10.211.55.3  6379  1   #主服务器名称 IP 端口号 选举次数(redis集群服务器不多时可以配置成1)

2.修改下一行:sentinel auth-pass mymaster 123456 # 第一个参数mymaster为主节点名称,123456为主服务器密码。

3. 修改心跳检测 5000毫秒【默认为30秒】

sentinel down-after-milliseconds mymaster 5000

4.sentinel parallel-syncs mymaster 2 --- 指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长

5. 启动哨兵模式【cd到redis安装根目录下启动,因为需要运行redis-server】

./redis-server sentinel.conf --sentinel &

启动后如果打印+ monitor master 主节点名 ip     和    +slave slave  ip则表示启动成功

6.可以通过模拟——主服务器进入redis-cli,输入shutdown,观察哨兵所在服务器日志打印。原从服务器本不能写操作,后由于哨兵自动故障迁移把某一个slave服务器升级为master服务器,则该升级后的服务器又可以进行写操作。

光靠redis主从复制和哨兵机制不足以实现redis高可用。为什么呢?

因为若某一节点宕机后,不会实现自动重启。最稳健实现高可用的做法 :

redis主从复制+哨兵机制(监控、提醒、自动故障迁移)+keepalived(自动重启),若重启多次仍不成功,可以通过邮件短信等方式通知。
————————————————
版权声明:本文为CSDN博主「itcats_cn」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/itcats_cn/article/details/82428716

原文地址:https://www.cnblogs.com/fengff/p/12576506.html

时间: 2024-10-12 11:43:36

redis如何实现高可用【主从复制、哨兵机制】的相关文章

Redis高可用方案哨兵机制------ 配置文件sentinel.conf详解

redis的哨兵机制是官方推荐的一种高可用(HA)方案,我们在使用Redis的主从结构时,如果主节点挂掉,这时是不能自动进行主备切换和通知客户端主节点下线的. Redis-Sentinel机制主要用三个功能: (1)监控:不停监控Redis主从节点是否安装预期运行 (2)提醒:如果Redis运行出现问题可以 按照配置文件中的配置项 通知客户端或者集群管理员 (3)自动故障转移:当主节点下线之后,哨兵可以从主节点的多个从节点中选出一个为主节点,并更新配置文件和其他从节点的主节点信息. 这里先把哨兵

Redis(六)——高可用之哨兵sentinel配置与启动及主从服务宕机与恢复

.主从复制高可用 #主从复制存在的问题: 1 主从复制,主节点发生故障,需要做故障转移,可以手动转移:让其中一个slave变成master 2 主从复制,只能主写数据,所以写能力和存储能力有限 哨兵是对Redis的系统的运行情况的监控,它是一个独立进程,它会独立运行,功能有二个: 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器. 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机.

Redis Cluster搭建高可用Redis服务器集群

原文:Redis Cluster搭建高可用Redis服务器集群 一.Redis Cluster集群简介 Redis Cluster是Redis官方提供的分布式解决方案,在3.0版本后推出的,有效地解决了Redis分布式的需求,当一个节点挂了可以快速的切换到另一个节点,当遇到单机内存.并发等瓶颈时,可以采用分布式方案要解决问题. 二.集群原理 Redis Cluster架构图 Redis Cluster集群采用了P2P的模式,完全去中心化,Redis把所有的Key分成了16384个slot,每个R

Redis+Keeplived实现高可用

博文说明[前言]: 本文将通过个人口吻介绍Redis+Keeplived实现高可用的相关知识,在目前时间点[2017年6月23号]下,所掌握的技术水平有限,可能会存在不少知识理解不够深入或全面,望大家指出问题共同交流,在后续工作及学习中如发现本文内容与实际情况有所偏差,将会完善该博文内容. 本文为我编写的部署文档(word格式)中关于redis部分的内容复制粘贴而来,因此会存在一些格式问题,因不影响阅读和理解,也没有改的必要了,这样反而便于大家慢下来理解.发表此处,一来是有方便自己查看,二来是给

redis主从配置及通过keepalived实现redis自动切换高可用

一:环境介绍: Master: 192.168.1.4 Slave: 192.168.1.5 Virtural IP Address (VIP): 192.168.1.253 二:设计思路: 当 Master 与 Slave 均运作正常时, Master负责服务,Slave负责Standby: 当 Master 挂掉,Slave 正时, Slave接管服务,同时关闭主从复制功能: 当 Master 恢复正常,则从Slave同步数据,同步数据之后关闭主从复制功能,恢复Master身份,于此同时Sl

003.MySQL高可用主从复制新增slave

一 基础环境 主机名 系统版本 MySQL版本 主机IP master CentOS 6.8 MySQL 5.6 172.24.8.10 slave01 CentOS 6.8 MySQL 5.6 172.24.8.11 slave02 CentOS 6.8 MySQL 5.6 172.24.8.20 二 新增slave2方案 2.1 方案1:-复制主库 复制主库要步骤: 将内存中的数据同步到表中: 锁定表,不让出现新数据: 备份: 解锁: 将备份传送到slave02,在slave02上同步数据:

MySQL高可用主从复制新增slave

目录 一 基础环境 二 新增slave2方案 2.1 方案1:-复制主库 2.2 方案2:复制从库 2.3 方案对比 二 新增slave2 2.1 部署主从 2.2 slave-02安装MySQL 2.2 初始化MySQL 三 方案1形式 3.1 锁定主库 3.2 备份主库 3.3 解锁主库 3.4 传递备份文件至slave02 3.5 主库继续新建数据库 3.6 备库slave02开启主从复制 3.7 备库slave02恢复mysqltest 3.8 备库slave02开启主从复制 3.9 验

Redis 高可用之哨兵模式

参考   : https://mp.weixin.qq.com/s/Z-PyNgiqYrm0ZYg0r6MVeQ 一.redis高可用解决方案 redis主从 优点:1.高可靠性,主从实时备份,有效解决单节点数据丢失问题. 2.可做读写分离,从库分担读操作,缓解主库压力 缺点:主库异常,需要手动主从切换    2.redis哨兵模式 优点:1.有效解决主从模式主库异常手动主从切换的问题 缺点:1.运维复杂,哨兵选举期间,不能对外提供服务 其他解决方案优缺点,可以查看 高可用 ,本篇主要介绍哨兵解

Redis集群,备份,哨兵机制

原文:https://blog.csdn.net/zy345293721/article/details/87536144 1.集群        先来简单了解下redis中提供的集群策略, 虽然redis有持久化功能能够保障redis服务器宕机也能恢复并且只有少量的数据损失,但是由于所有数据在一台服务器上,如果这台服务器出现硬盘故障,那就算是有备份也仍然不可避免数据丢失的问题.       在实际生产环境中,我们不可能只使用一台redis服务器作为我们的缓存服务器,必须要多台实现集群,避免出现