Redis主从复制机制详解

Redis主从复制机制详解

Redis有两种不同的持久化方式,Redis服务器通过持久化,把Redis内存中持久化到硬盘当中,当Redis宕机时,我们重启Redis服务器时,可以由RDB文件或AOF文件恢复内存中的数据。

不过持久化后的数据仍然只在一台机器上,因此当硬件发生故障时,比如主板或CPU坏了,这时候无法重启服务器,有什么办法可以保证服务器发生故障时数据的安全性?或者可以快速恢复数据呢?想做到这一点,我们需要再了解Redis另外一种机制:主从复制。

什么是主从复制

Redis的主从复制机制是指可以让从服务器(slave)能精确复制主服务器(master)的数据,如下图所示:

上面的图表示的是一台master服务器与slave服务器的情况,其实一台master服务器也可以对应多台slave服务器,如下图所示:

另外,slave服务器也可以有自己的slave服务器,这样的服务器称为sub-slave,而这些sub-slave通过主从复制最终数据也能与master保持一致,如下图所示:

主从复制的方式和工作原理

Redis的主从复制是异步复制,异步分为两个方面,一个是master服务器在将数据同步到slave时是异步的,因此master服务器在这里仍然可以接收其他请求,一个是slave在接收同步数据也是异步的。

复制方式

Redis主从复制分为以下三种方式:

一、当master服务器与slave服务器正常连接时,master服务器会发送数据命令流给slave服务器,将自身数据的改变复制到slave服务器。

二、当因为各种原因master服务器与slave服务器断开后,slave服务器在重新连上master服务器时会尝试重新获取断开后未同步的数据即部分同步,或者称为部分复制。

三、如果无法部分同步(比如初次同步),则会请求进行全量同步,这时master服务器会将自己的rdb文件发送给slave服务器进行数据同步,并记录同步期间的其他写入,再发送给slave服务器,以达到完全同步的目的,这种方式称为全量复制。

工作原理

master服务器会记录一个replicationId的伪随机字符串,用于标识当前的数据集版本,还会记录一个当数据集的偏移量offset,不管master是否有配置slave服务器,replication Id和offset会一直记录并成对存在,我们可以通过以下命令查看replication Id和offset:

> info repliaction
复制代码

通过redis-cli在master或slave服务器执行该命令会打印类似以下信息(不同服务器数据不同,打印信息不同):

connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=9472,lag=1
master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee
master_repl_offset:9472
复制代码

当master与slave正常连接时,slave使用PSYNC命令向master发送自己记录的旧master的replication id和offset,而master会计算与slave之间的数据偏移量,并将缓冲区中的偏移数量同步到slave,此时master和slave的数据一致。

而如果slave引用的replication太旧了,master与slave之间的数据差异太大,则master与slave之间会使用全量复制的进行数据同步。

配置主从复制

Redis的主从配置非常简单,我们可以使用两种方式来配置主从服务器,在这时我们先假设Redismaster服务器地址为192.168.0.101

客户端发送同步命令

# 向客户端
saveof 192.168.1.101 6379
复制代码

slave服务器配置主服务器

在这里slave服务器的redis.conf通过saveof选项,可以指定master服务器,如下:

slaveof 192.168.1.101 6379
复制代码

通过上面两种方式的配置,master服务器与slave服务器便已经可以开始进行数据同步了。

master要求验证

上面配置的是master服务器没有设置密码的情况,如果master设置了密码,则可以在连接到slave服务器redis-cli执行下面的命令:

# <password>指代实际的密码
config set masterauth <password>
复制代码

或者在slave服务器的redis.conf中配置下面的选项:

# <password>指代实际的密码
masterauth <password>
复制代码

避免slave被清空

slave会被清空?slave不用同步了master的数据吗?备份的数据怎么会清空了呢?

当master服务器关闭了持久化时,如果发生故障后自动重启时,由本地没有保存持久化的数据,重启的Redis内存数据为空,而slave会自动同步master的数据,这时候,slave服务器的数据也会被清空。

如何避免slave被清空呢?

如果条件允许(一般都可以的),master服务器还是要开启持久化,这样master故障重启时,可以快速恢复数据,而同步这台master的slave数据也不会被清空。

如果master不能开启持久化,则不应该设置让master发生故障后重启(有些机器会配置自动重启),而是将某个slave服务器升级为master服务器,对外继续提供服务。

slave默认为只读的

Redis2.6以后,slave只读模式是默认开启的,我们可以通过配置文件中的slave-read-only选项配置是否开启只读模式:

# 默认是yes
slave-read-only yes/no
复制代码

或者在客户端中通过config set命令设置是否开启只读模式:

config set slave-read-only no
复制代码

上面将slave服务器设置为可以写入,但是要注意,如果slave也配置了自己的从服务器(sub-slave),那么sub-slave只会同步从master服务器同步到slave的数据,而并会同步我们直接写入slave服务器的数据。

主从复制中的key过期问题

我们都知道Redis可以通过设置key的过期时间来限制key的生存时间,Redis处理key过期有惰性删除和定期删除两种机制,而在配置主从复制后,slave服务器就没有权限处理过期的key,这样的话,对于在master上过期的key,在slave服务器就可能被读取,所以master会累积过期的key,积累一定的量之后,发送del命令到slave,删除slave上的key。

如果slave服务器升级为master服务器 ,则它将开始独立地计算key过期时间,而不需要通过master服务器的帮助。

主从复制的作用

保存Redis数据副本

当我们只是通过RDBAOFRedis的内存数据持久化毕竟只是在本地,并不能保证绝对的安全,而通过将数据同步slave服务器上,可以保留多一个数据备份,更好地保证数据的安全。

读写分离

在配置了主从复制之后,如果master服务器的读写压力太大,可以进行读写分离,客户端向master服务器写入数据,在读数据时,则访问slave服务器,从而减轻master服务器的访问压力。

高可用性与故障转移

服务器的高可用性是指服务器能提供7*24小时不间断的服务,Redis可以通过Sentinel系统管理多个Redis服务器,当master服务器发生故障时,Sentineal系统会根据一定的规则将某台slave服务器升级为master服务器,继续提供服务,实现故障转移,保证Redis服务不间断。

小结

Redis的主从复制可以让我们把Redis中的数据同步到其他服务器上,为数据安全提供更加安全的保障,也可以让我们的服务器在发生故障时而无法重启时,可以更加快速地切换服务器,继续对外提供服务。

原文地址:https://www.cnblogs.com/weilingfeng/p/11156422.html

时间: 2024-10-29 20:42:49

Redis主从复制机制详解的相关文章

Redis常见配置文件详解

Redis常见配置文件详解 # vi redis.conf   daemonize yes #是否以后台进程运行 pidfile /var/run/redis/redis-server.pid    #pid文件位置 port 6379#监听端口 bind 127.0.0.1   #绑定地址,如外网需要连接,设置0.0.0.0 timeout 300     #连接超时时间,单位秒 loglevel notice  #日志级别,分别有: # debug :适用于开发和测试 # verbose :

Redis高可用详解:持久化技术及方案选择

Redis高可用详解:持久化技术及方案选择 Java架构师那些事 关注 0.3 2018.08.23 22:55 字数 9774 阅读 542评论 0喜欢 9 前言 本文将先说明上述几种技术分别解决了Redis高可用的什么问题,然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案.在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时还会介绍持久化实现的一些原理细节及需要注意的问题.最后,介绍在实际使用中持久化方案的选择以及经常遇到的问题等内容. 一.Redis高可用概述

Redis 复制过程详解

Redis 的复制功能分为同步( sync )和命令传播( command propagate )两个步骤: 同步用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态. 命令传播则用于在主服务器的数据库状态被修改,导致主从服务器的数据库状态出现不一致时,让主从服务器的数据库重新回到一致状态. 同步 Redis 使用 psync 命令完成主从数据同步,同步过程分为:全量复制和部分复制. 全量复制:一般用于初次复制场景,它会把主节点全部数据一次性发送给从节点发送给从节点,当数据量较大时,会对

Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)

1 背景 还记得前一篇<Android触摸屏事件派发机制详解与源码分析一(View篇)>中关于透过源码继续进阶实例验证模块中存在的点击Button却触发了LinearLayout的事件疑惑吗?当时说了,在那一篇咱们只讨论View的触摸事件派发机制,这个疑惑留在了这一篇解释,也就是ViewGroup的事件派发机制. PS:阅读本篇前建议先查看前一篇<Android触摸屏事件派发机制详解与源码分析一(View篇)>,这一篇承接上一篇. 关于View与ViewGroup的区别在前一篇的A

【Hibernate步步为营】--锁机制详解

上篇文章详细讨论了hql的各种查询方法,在讨论过程中写了代码示例,hql的查询方法类似于sql,查询的方法比较简单,有sql基础的开发人员在使用hql时就会变得相当的简单.Hibernate在操作数据库的同时也提供了对数据库操作的限制方法,这种方法被称为锁机制,Hibernate提供的锁分为两种一种是乐观锁,另外一种是悲观锁.通过使用锁能够控制数据库的并发性操作,限制用户对数据库的并发性的操作. 一.锁简介 锁能控制数据库的并发操作,通过使用锁来控制数据库的并发操作,Hibernate提供了两种

浏览器缓存机制详解

对于浏览器缓存,相信很多开发者对它真的是又爱又恨.一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了"错误"的东西,而在开发过程中千方百计地想把缓存禁掉.那么浏览器缓存究竟是个什么样的神奇玩意呢? 什么是浏览器缓存: 简单来说,浏览器缓存就是把一个已经请求过的Web资源(如html页面,图片,js,数据等)拷贝一份副本储存在浏览器中.缓存会根据进来的请求保存输出内容的副本.当下一个请求来到的时候,如果是相同的URL,缓存会根据缓存机制决定是直接使用副本响应访问请求,还是

Android触摸屏事件派发机制详解与源码分析

请看下面三篇博客,思路还是蛮清晰的,不过还是没写自定义控件系列哥们的思路清晰: Android触摸屏事件派发机制详解与源码分析一(View篇) http://blog.csdn.net/yanbober/article/details/45887547 Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇) http://blog.csdn.net/yanbober/article/details/45912661 Android触摸屏事件派发机制详解与源码分析三(Activi

SpringMVC视图机制详解[附带源码分析]

目录 前言 重要接口和类介绍 源码分析 编码自定义的ViewResolver 总结 参考资料 前言 SpringMVC是目前主流的Web MVC框架之一. 如果有同学对它不熟悉,那么请参考它的入门blog:http://www.cnblogs.com/fangjian0423/p/springMVC-introduction.html 本文将分析SpringMVC的视图这部分内容,让读者了解SpringMVC视图的设计原理. 重要接口和类介绍 1. View接口 视图基础接口,它的各种实现类是无

Shiro的Filter机制详解---源码分析

Shiro的Filter机制详解 首先从spring-shiro.xml的filter配置说起,先回答两个问题: 1, 为什么相同url规则,后面定义的会覆盖前面定义的(执行的时候只执行最后一个). 2, 为什么两个url规则都可以匹配同一个url,只执行第一个呢. 下面分别从这两个问题入手,最终阅读源码得到解答. 问题一解答 相同url但定义在不同的行,后面覆盖前面 如 /usr/login.do=test3 /usr/login.do=test1,test2 不会执行test3的filter