1，下载编译安装redis

http://www.redis.cn/download.html
redis 安装配置_第1张图片

下载完成，使用rz命令上传至linux 服务器
tar -xvf redis-5.0.5.tar.gz            #解压源码包
mv redis-5.0.5 /usr/local/redis #将源码包移动到/usr/local/目录下，重命名为redis
cd /usr/local/redis/                      #cd 到源码目录里

redis 安装配置

redis 安装配置_第2张图片

make #编译
中间有两个报错，解决

redis 安装配置_第3张图片
#没有安装gcc 包，yum install gcc -y 解决
redis 安装配置_第4张图片
#加个环境变量一起编译　　　　make MALLOC=libc　用这句命令能正常编译
redis 安装配置_第5张图片

make install #安装编译完成的程序，也可以不用安装,cd 到src目录 执行也行
cd /usr/local/bin/ #这个目录是安装完成后 生成的脚本，打开关闭 客户端工具都在里面

redis 安装配置_第6张图片

2.配置 配置文件，启动 关闭 redis

vim /usr/local/redis/redis.conf  #配置 redis 配置文件，修改以下选项
bind 0.0.0.0 #监听IP 0.0.0.0 表示此计算机所有IP都监听
daemonize  yes  #是否后台启动redis，打开
protected-mode no # redis的安全机制，打开可能会报错
#requirepass 123456 #设置密码，默认注释状态。

redis-server /usr/local/redis/redis.conf  #指定配置文件启动 redis

redis 安装配置
netstat -nltp|grep 6379 #检查6379 是否被监听了，这个端口是redis默认端口
redis 安装配置
redis-cli #登陆客户端，输入几个值，查看以下
redis 安装配置_第7张图片

redis-cli shutdown #关闭redis服务

3.RDB持久化

RDB持久化方式是通过快照(snapshotting)完成的，当符合一定条件时，redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。当redis重启时，并且AOF持久化未开启时，redis会读取RDB持久化生成的二进制文件(默认名称dump.rdb，可通过设置dbfilename修改)进行数据恢复，对于持久化信息可以用过命令“info Persistence”查看。

快照触发条件

RDB生成快照可自动促发，也可以使用命令手动触发，以下是redis触发执行快照条件，后续会对每个条件详细说明：

客户端执行命令save和bgsave会生成快照；
根据配置文件save m n规则进行自动快照；
主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照；
客户端执行数据库清空命令FLUSHALL时候，触发快照；
客户端执行shutdown关闭redis时，触发快照；

save命令触发和shutdown触发

客户端执行save命令，该命令强制redis执行快照，这时候redis处于阻塞状态，不会响应任何其他客户端发来的请求，直到RDB快照文件执行完毕，所以请慎用。
 首先使用redis-cli info Persistence 查看最近一次持久化时间：

redis 安装配置_第8张图片

 #可以看到数据是一组时间戳看的 不方便看，我们可以用AWK 配合date命令转换下
 date "+%Y-%m-%d %H:%M:%S" -d @`redis-cli info Persistence|awk -F":" 'NR==5{print$2}'`

redis 安装配置
#可以看到运行了 redis-cli save 命令，最后一次的保存时间已经发生了改变

shutdown触发

redis 安装配置_第9张图片
#注意只有正常关闭才会触发保存，直接kill是无法触发的

bgsave命令触发

basave 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程（在此期间父进程不响应请求），原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。
redis 安装配置
#用法和save 差不多，但是阻塞时间比save 大大减少了

save m n规则触发

这个配置在配置文件里
默认
save 900 1          #表示900秒内有1个键发生修改，触发bgsave
save 300 10        #表示300秒内有10个键发生修改，触发bgsave
save 60 10000    #表示60秒内有10000个键发生修改，触发bgsave
#上面关系式或的意思，满足一个即可触发bgsave

FLUSHALL触发和主从触发

flushall命令用于清空数据库，请慎用，当我们使用了则表明我们需要对数据进行清空，那redis当然需要对快照文件也进行清空，所以会触发bgsave。
在redis主从复制中，从节点执行全量复制操作，主节点会执行bgsave命令，并将rdb文件发送给从节点。

RDB持久化配置——配置文件

save m n
#配置快照(rdb)促发规则，格式：save  
#save 900 1  900秒内至少有1个key被改变则做一次快照
#save 300 10  300秒内至少有300个key被改变则做一次快照
#save 60 10000  60秒内至少有10000个key被改变则做一次快照
#关闭该规则使用svae “” 

dbfilename  dump.rdb
#rdb持久化存储数据库文件名，默认为dump.rdb

stop-write-on-bgsave-error yes 
#yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。

rdbchecksum yes
#在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

dir ./ 
#数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限，编译安装的默认就在当前目录。

rdbcompression yes
#是否开启RDB文件压缩，该功能可以节约磁盘空间

4.AOF持久化

AOF持久化和Mysql的二级制日志写入原理一样，AOF可以将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中,在redis启动时候优先选择从AOF文件恢复数据。由于每一次的写操作，redis都会记录到文件中，对磁盘I/O有以一定影响，与RDB持久化相比，AOF持久化数据（1秒左右的数据）丢失更少，其消耗内存更少(RDB方式执行bgsve会有内存拷贝)。
开启AOF
redis 安装配置_第10张图片
#默认情况下，redis是关闭了AOF持久化，开启AOF通过配置appendonly为yes开启，我们修改配置文件或者在命令行直接使用config set修改，在用config rewrite同步到配置文件。通过客户端修改好处是不用重启redis，AOF持久化直接生效。

AOF持久化过程

redisAOF持久化过程可分为以下阶段：

1.追加写入
redis将每一条写命令以redis通讯协议添加至缓冲区aof_buf,这样的好处在于在大量写请求情况下，采用缓冲区暂存一部分命令随后根据策略一次性写入磁盘，这样可以减少磁盘的I/O次数，提高性能。

2.同步命令到硬盘
当写命令写入aof_buf缓冲区后，redis会将缓冲区的命令写入到文件，redis提供了三种同步策略，由配置参数appendfsync决定，下面是每个策略所对应的含义：

▪ no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据丢失严重。
▪ always：表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低。
▪ everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从   内核刷新到磁盘。 这是折中的方案，兼顾性能和数据安全，所以redis默认推荐使用该配置。

3.文件重写(bgrewriteaof)
当开启的AOF时，随着时间推移，AOF文件会越来越大,当然redis也对AOF文件进行了优化，即触发AOF文件重写条件（后续会说明）时候，redis将使用bgrewriteaof对AOF文件进行重写。这样的好处在于减少AOF文件大小，同时有利于数据的恢复。

为什么重写？比如先后执行了“set foo bar1 set foo bar2 set foo bar3” 此时AOF文件会记录三条命令，这显然不合理，因为文件中应只保留“set foo bar3”这个最后设置的值，前面的set命令都是多余的，下面是一些重写时候策略：

▪ 重复或无效的命令不写入文件
▪ 过期的数据不再写入文件
▪ 多条命令合并写入（当多个命令能合并一条命令时候会对其优化合并作为一个命令写入，例如“RPUSH list1 a RPUSH list1 b" 合并为“RPUSH list1 a b” ）

重写触发条件

AOF文件触发条件可分为手动触发和自动触发：

手动触发：客户端执行bgrewriteaof命令。

自动触发：自动触发通过以下两个配置协作生效：

▪ auto-aof-rewrite-min-size: AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb。
▪ auto-aof-rewrite-percentage：当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。

redis开启在AOF功能开启的情况下，会维持以下三个变量

▪ 记录当前AOF文件大小的变量aof_current_size。
▪ 记录最后一次AOF重写之后，AOF文件大小的变量aof_rewrite_base_size。
▪ 增长百分比变量aof_rewrite_perc。

每次当serverCron（服务器周期性操作函数）函数执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：

▪ 没有bgsave命令（RDB持久化）/AOF持久化在执行；
▪ 没有bgrewriteaofF在进行；
▪ 当前AOF文件大小要大于server.aof_rewrite_min_size的值；
▪ 当前AOF文件大小和最后一次重写后的大小之间的比率等于或者大于指定的增长百分比（auto-aof-rewrite-percentage参数）

AOF配置参数--配置文件

auto-aof-rewrite-min-size 64mb
#AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb。

auto-aof-rewrite-percentage  100
#当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。

appendfsync everysec
#no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据
#always：表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低。
#everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从内核刷新到磁盘。 这是折中的方案，兼顾性能和数据安全，所以redis默认推荐使用该配置。

aof-load-truncated yes
#当redis突然运行崩溃时，会出现aof文件被截断的情况，Redis可以在发生这种情况时退出并加载错误，以下选项控制此行为。
#如果aof-load-truncated设置为yes，则加载截断的AOF文件，Redis服务器启动发出日志以通知用户该事件。
#如果该选项设置为no，则服务将中止并显示错误并停止启动。当该选项设置为no时，用户需要在重启之前使用“redis-check-aof”实用程序修复AOF文件在进行启动。

appendonly no 
#yes开启AOF，no关闭AOF

appendfilename appendonly.aof
#指定AOF文件名，4.0无法通过config set 设置，只能通过修改配置文件设置。

dir ./
#RDB文件和AOF文件存放目录

两个保存文件检查

redis-check-aof appendonly.aof  #ＡＯＦ
redis-check-rdb dump.rdb　　　＃ＲＤＢ