鸿 网 互 联 www.68idc.cn

当前位置 : 服务器租用 > 数据库 > nosql > >

Redis主从复制

来源:互联网 作者:佚名 时间:2018-02-03 14:53
大家可以先看这篇文章ASP.NET Redis 开发对Redis有个初步的了解 Redis 的主从复制功能非常强大,一个 master 可以拥有多个 slave ,而一个 slave 又可以拥有多个 slave ,如此下去,形成了强大的多级服务器集群架构 。 在 master 上执行写操作,在slave上面

大家可以先看这篇文章ASP.NET Redis 开发对Redis有个初步的了解

Redis的主从复制功能非常强大,一个master可以拥有多个slave,而一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构

master上执行写操作,在slave上面进行读操作,因为我们大多数场景查多一些。

实现步骤如下:

1.Windows某个磁盘上创建两个目录,例如; MasterRedis(存储的是Master服务) SlaveRedis(存储的是Slave服务).

把Reidis文件分别拷贝一份到这两个目录中。

2.Master服务中的配置文件redis.conf修改 :bind 127.0.0.1.

3.Slave服务中的配置文件redis.conf修改: 

      port 6381(服务端口号要分开)

      bind 127.0.0.1

      slaveof 127.0.0.1 6379 (设置masterHost以及Port

4.分别启动Master服务与Slave服务。

启动Master服务,开始——运行——CMD

启动Slave服务,开始——运行——CMD

这个时候会发现我们主从服务器配置都正确了。

接下来,我们尝试在master服务器里面写一条数据,然后看slave服务器上面能查询到么

再打开一个CMD窗口,

D:\Redis服务\MasterRedis>redis-cli.exe -h 127.0.0.1 -p 6379
redis 127.0.0.1:6379> set name "邹琼俊"
OK
redis 127.0.0.1:6379>

 由于我们默认的redis配置:Save 900 1,表示有1个key改变,900秒以后执行快照,那么15分钟后才会同步到slave服务器。

15分钟后,打开slave服务器目录下面的dump.rdb进行查看:,表示已经同步到slave上面去了。

注意到,当我启动master,然后启动一个slave的时候,可以发现slave上: 

[5444] 17 Apr 08:39:57 * MASTER <-> SLAVE sync started
[5444] 17 Apr 08:39:57 * Non blocking connect for SYNC fired the event.
[5444] 17 Apr 08:39:58 * MASTER <-> SLAVE sync: receiving 10 bytes from master
[5444] 17 Apr 08:39:58 * MASTER <-> SLAVE sync: Loading DB in memory
[5444] 17 Apr 08:39:58 * MASTER <-> SLAVE sync: Finished with success

会发送一个SYNC请求,从Master上面进行相应,而且它支持自动重连,

即当master掉线的情况下,它会处于等待请求的状态。

Master上:

 

第一次SlaveMaster同步的实现是:SlaveMaster发出同步请求,Masterdumprdb文件,然后将rdb文件全量传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。第二次以及以后的同步实现是:Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致SlaveMaster断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上,只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞,但由于Redis使用单线程服务,如果Master快照文件比较大,那么第一次全量传输会耗费比较长时间,且文件传输过程中Master可能无法提供服务,也就是说服务会中断。

Redis数据快照

数据快照的原理是将整个Redis内存中的所有的数据遍历一遍存储到一个扩展名为rdb的数据文件中,通过save命令

可以调用这个过程。数据快照配置如下:

Save 900 1

Save 300 10

Save 60 10000

以上在redis.conf中的配置指出在多长时间内,有多少次更新操作,就将数据同步到数据文件中,这个可以多个条件进行配合,上面的含义是900秒后有一个key发生改变就执行save,300秒后有10key发生改变就执行save,60秒有10000key发生改变就执行save.

数据快照的缺点是持久化之后如果出现系统宕机则会丢失一段数据,因此增加了另外一种追加式的操作日志记录,叫append only file,其日志文件以aof结尾,我们称为aof文件,要开启aof日志的记录,需要在配置文件中进行如下配置: appendonly yes

Appendonly配置不开启,可能在断电时导致一段时间的数据丢失,因为redis本身同步数据文件时按save条件来同步的,所以有的数据会在一段时间内只存在于内存中。

Appendfsync no/always/everysec

no:表示等操作系统进行数据缓存同步到磁盘。性能最好,持久化没有保障。

Always:表示每次更新操作后手动调用fsync()将数据写到磁盘.每次收到写命令就立即强制写入磁盘,最慢的,但是保障完全的持久化。

Everysec:表示每秒同步一次.每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中。

为了定时减小AOF文件的大小,Redis2.4以后增加了自动的bgrewriteaof的功能,Redis会选择一个自认为负载低的情况下执行bgrewriteaof,这个重写AOF文件的过程是很影响性能的。解决方案:Master关闭Save功能,关闭AOF日志功能,以求达到性能最佳。Slave开启Save并开启AOF日志功能,并开启bgrewriteaof功能,不对外提供服务,这样Slave的负载总体上会高于Master负载,但是Master性能达到最好.

Bgrewriterof内部实现:

 1.Redis通过fork一个子进程,遍历数据,写入新临时文件

 2.父进程继续处理client请求,子进程继续写临时文件。

 3.父进程把新写入的AOF写在缓冲区。

 4.子进程写完退出,父进程接收退出消息,将缓冲区AOF写入临时文件。

 5.临时文件重命名成appendonly.aof,原来文件被覆盖,整个过程完成。

Redis数据恢复

Redis服务器挂掉以后,重启时将按以下优先级恢复数据到内存:

1.如果只配置了AOF,重启时加载AOF文件恢复数据。

2.如果同时配置了RBDAOF,启动时只加载AOF文件恢复数据。

3.如果只配置了RDB,启动时将加载dump文件恢复数据。

网友评论
<