redis的官方文档：www.redis.cn/
一.redis介绍
1.
redis是一个开源的，遵守BSD协议，是一个高性能的key-value数据库，内存存储的数据结构服务器，可用作数据路，高速缓存和消息队列的代理。支持字符串，哈希表，列表，集合，有序集合，位图，hyperloglogs等数据类型。内置复制，lua脚本，LRU收回，事务以及不同级别磁盘持续化功能，同时通过redis sentinel提供了高可用，通过redis cluster提供了自动分区。Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用，Redis支持数据的备份，即master-slave模式的数据备份。中文官网（http://www.redis.net.cn）。
2.redis的持久化的两种方式（AFO和RDB）：
（1）AFO和RDB的介绍
AFO：以日志的形式记录每个写操作，将 redis 执行过的所有写指令记录下来(读操作不记录)。只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，redis重启的话就根据日志文件的内容将写指令从前到后执行一次一完成数据恢复工作。使用 AOF 持久化会让 Redis 变得非常耐久：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。
RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时就是将快照文件直接读到内存里。
Redis 会单独的创建(fork) 一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化的文件。整个过程主进程是不进行任何 IO 操作，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。（因为是隔一段时间才把数据集写入磁盘，当突然redis被crash，本次的数据丢失）
（2）AFO的优缺点及RDB的优缺点
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,但是你可以调节重写日志文件的频率来提高数据集的耐久 度.
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）。
二.redis的主从复制
1.主从复制的原理（全量复制+增量复制）：
全量复制：
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。
1）从服务器连接主服务器，发送SYNC命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写名令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
增量复制：
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
2.redis主从复制策略：
主从刚刚连接的时候，进行全量同步；全量同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。
3.redis的复制机制：
对于slave端来说，主从复制主要经历四个阶段：(1)与master建立连接；(2)向master发起同步请求（SYNC）；(3)接受master发来的RDB数据；(4)载入RDB文件
三.Redis配置文件中几个重要的配置项含义
1.daemonize yes
默认情况下，redis 是在后台运行的，如果不需要在后台运行，把该项的值更改为no。
2.port
监听端口，默认为6379
3.databases 16
设置数据库的个数，可以使用SELECT 命令来切换数据库。默认使用的数据库是0号库。默认16个库
4.
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文件中
5.slaveof
设置该数据库为其他数据库的从数据库，并为其指定master信息。
6.
# 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才可以接受写的操作
四.实验环境(rhel7.3版本)
1.selinux和firewalld状态为disabled
2.各主机信息如下：
| 主机 | ip |
|---|---|
| server1（主机） | 172.25.83.1 |
| server2（从机） | 172.25.83.2 |
五.redis主从复制的部署
1.配置server1（主机）：
<1>安装redis
（1）下载安装包：redis-5.0.3.tar.gz，并解压
[root@server1 ~]# tar zxf redis-5.0.3.tar.gz
（2）下载编译依赖的软件gcc
[root@server1 ~]# yum install gcc -y
（3）cd redis-5.0.3进行编译
[root@server1 redis-5.0.3]# make
[root@server1 redis-5.0.3]# make install
（4）cd utils执行”./install_server.sh”，一路敲回车。会生成配置文件，端口信息等。
[root@server1 utils]# ./install_server.sh
至此redis的安装，也就完成了。当redis安装完成之后，redis服务就已经开启。可以来用查看端口的方法（redis服务的端口是6379），来查看redis服务是否开启。
<2>配置redis
（1）修改配置文件
[root@server1 utils]# vim /etc/redis/6379.conf
bind 0.0.0.0 #将70行的bind这行改掉，监听所有IP网段
（2）修改完配置文件后，重启redis服务（因为执行完./install_server.sh脚本之后，redis服务已经开启，所以这里是重启redis服务，而不是开启redis服务）
[root@server1 utils]# /etc/init.d/redis_6379 restart
至此redis的配置也就完成了。此时再次查看redis的端口信息，可以看到，redis监控的端口信息是0.0.0.0:6379和127.0.0.1:6379，而并不再只是127.0.0.1:6379。
2.配置server2（从机）：
<1>安装redis，安装过程同server1
或者直接将server1上安装好的目录发送给server2，然后再在server2上执行剩下的操作，过程如下：
（1）将server1上安装好的目录发送给server2：
（2）在server2上执行剩下的操作：
<2>配置redis
（1）修改配置文件
[root@server2 utils]# vim /etc/redis/6379.conf
bind 0.0.0.0 #将70行的bind这行改掉，监听所有IP网段
slaveof 172.25.83.1 6379 #在配置文件的最后一行指定主机的IP和端口（slaveof IP port做一主多从就在每台从机的配置文件中加上这行参数即可）
<2>修改完配置文件后，重启redis服务（因为执行完./install_server.sh脚本之后，redis服务已经开启，所以这里是重启redis服务，而不是开启redis服务）
[root@server2 utils]# /etc/init.d/redis_6379 restart
3.测试：
<1>主机设定key-value
[root@server1 bin]# redis-cli
127.0.0.1:6379> set name xjj
OK
127.0.0.1:6379> get name #可以设定键和value，那么当然也可以删除键及其对应的value。对应的命令就是"del name"
"xjj"
<2>查看从机能否获取到value值
[root@server2 bin]# redis-cli
结论：
在主机设定的key-value，在从机可以看到，表示redis的主从配置成功。
值的注意的是：从库默认是只读的，是不可以写的。
[root@server2 bin]# redis-cli