Redis——redis的安装以及实现redis的主从复制

一.什么是redis

redis是一个开源的，遵守BSD协议，是一个高性能的key-value数据库，内存存储的数据结构服务器，可用作数据路，高速缓存和消息队列的代理。支持字符串，哈希表，列表，集合，有序集合，位图，hyperloglogs等数据类型。内置复制，lua脚本，LRU收回，事务以及不同级别磁盘持续化功能，同时通过redis sentinel提供了高可用，通过redis cluster提供了自动分区。Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，Redis支持数据的备份，即master-slave模式的数据备份。

中文官网请点击

redis的持久化的两种方式（AOF和RDB）：

AOF的概念：

• 以日志的形式记录每个写操作，将 redis 执行过的所有写指令记录下来(读操作不记录)。
• 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，redis重启的话就根据日志文件的内容将写指令从前到后执行一次一完成数据恢复工作。
• 使用 AOF 持久化会让 Redis 变得非常耐久：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

AOF的优点：

• 使用AOF 会让你的Redis更加耐久:
  你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好 (fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.

• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.

• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子，如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF的缺点：

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB可以提供更有保证的最大延迟时间（latency）。

RDB的概念：

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时就是将快照文件直接读到内存里。

Redis 会单独的创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化的文件。整个过程主进程是不进行任何 IO 操作，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。（因为是隔一段时间才把数据集写入磁盘，当突然redis被crash，本次的数据丢失）

RDB的优点：

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集

• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.

• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.

• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点：

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点
  (例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.

• RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

二.redis的安装

前提：

这里我们需要一个全新的实验环境，所以可以创建新的虚拟机，我是采用创建快照将原本虚拟机覆盖，这里覆盖的多，是为了后面做实验所准备。

将所需的安装包发送到做实验的虚拟机

在server1上面安装redis：

第一步：解压安装包并编译

[root@server1 ~]# cd /mnt
[root@server1 mnt]# tar zxf redis-5.0.3.tar.gz 
[root@server1 mnt]# cd redis-5.0.3/
[root@server1 redis-5.0.3]# yum install -y gcc     #编译需要安装gcc
[root@server1 redis-5.0.3]# make && make install 

第二步：执行”./install_server.sh”文件，一路敲回车。会生成配置文件，端口信息等

[root@server1 redis-5.0.3]# cd utils/
[root@server1 utils]# ./install_server.sh

至此redis的安装，也就完成了。当redis安装完成之后，redis服务就已经开启。可以来用查看端口的方法（redis服务的端口是6379），来查看redis服务是否开启。

但是我们想让redis去监听所有ip网段，就要进行以下编辑

第三步：配置redis，修改配置文件

[root@server1 utils]# vim /etc/redis/6379.conf
 bind 0.0.0.0             #监听本机的所有ipv4地址

修改完配置文件后，重启redis服务（因为执行完./install_server.sh脚本之后，redis服务已经开启，所以这里是重启redis服务，而不是开启redis服务）

注意：

• systemctl管理redis服务的时候，不能采取restart，因为脚本里没有定义，只能采取stop——>start这种方式来达到重启服务的作用

第四步：测试

[root@server1 init.d]# redis-cli
127.0.0.1:6379> set name westos
OK
127.0.0.1:6379> get name
"westos"
127.0.0.1:6379> get name
"westos"
127.0.0.1:6379> del name
(integer) 1
127.0.0.1:6379> get name
(nil)
127.0.0.1:6379> exit

三.实现redis的主从复制

主从复制的原理（全量复制+增量复制）：

全量复制：

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

1）从服务器连接主服务器，发送SYNC命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写名令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量复制：

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

redis主从复制策略：

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

redis的复制机制：

对于slave端来说，主从复制主要经历四个阶段：

• 1.与master建立连接；
• 2.向master发起同步请求（SYNC）；
• 3.接受master发来的RDB数据；
• 4.载入RDB文件

Redis配置文件中几个重要的配置项含义

daemonize yes

默认情况下，redis 是在后台运行的，如果不需要在后台运行，把该项的值更改为no。

databases 16

设置数据库的个数，可以使用SELECT 命令来切换数据库。默认使用的数据库是0号库。默认16个库

save 900 1
save 300 10
save 60 10000

保存数据快照的频率，即将数据持久化到dump.rdb文件中的频度。用来描述”在多少秒期间至少多少个变更操作”触发snapshot数据保存动作。

默认设置，意思是：

在900 秒之内有1 个keys 发生了变化，进行镜像备份

在300 秒之内有10 个keys 发生了变化，进行镜像备份

在60 秒之内有10000 个keys 发生变化时，进行镜像备份

其备份文件所在的位置为：/var/lib/redis/6379/dump.rdb文件中

slaveof

设置该数据库为其他数据库的从数据库，并为其指定master信息。

#min-slaves-to-write 3
#min-slaves-max-lag 10

如果少于 N 个 slave 连接，且延迟时间 <=M 秒，则 master 可配置停止接受写操作。

配置示例：

min-slaves-to-write 1

min-slaves-max-lag 10

上述示例的含义是：需要至少 1 个 slave 连接，且延迟 <=10 秒的配置，master才可以接受写的操作

实现redis的主从复制实验步骤如下所示：

实现redis的主从复制，我们需要在setrver2上面配置redis，安装redis的步骤与server1相同，这里就不多做说明。

在server2上面安装redis

第二步：修改配置文件，部署redis的从节点

[root@server2 utils]# vim /etc/redis/6379.conf
bind 0.0.0.0                      #监听所有IP网段
replicaof 172.25.27.1 6379          #同步172.25.27.1的6379端口的数据

修改完配置文件后，重启redis服务

第三步：测试redis的主从复制

主机设定key-value

[root@server1 bin]# redis-cli 
127.0.0.1:6379> set name mengmeng
OK
127.0.0.1:6379> get name       #可以设定键和value，那么当然也可以删除键及其对应的value。对应的命令就是"del name"
"mengmeng"

在从（server2）查看：可以查看到

结论：

在主机设定的key-value，在从机可以看到，表示redis的主从配置成功。

从库默认是只读的，是不可以写的，如下所示：