一文道明Redis持久化

一文道明Redis持久化方案的区别与联系

本文会重点讲清楚如下问题：

一、什么是Redis

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。
以上解释是来自于百度。简单讲他就是基于C语言实现的一种K,V结构的内存级的单线程的数据库。单机可以支持百万级别的并发，性能非常的强大。常用于做缓存和分布式锁。（内存级别：因为是内存级别的数据库，所以免去了多线程的上下文切换带来的损耗，所以性能很高）

1 Redis的单线程

Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

2 单线程的Redis如何处理那么多的客户连接？

redis采用的一个叫IO多路复用技术。redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。如下图：

3 Redis安装

下载地址：http://redis.io/download
安装步骤：
# 安装gcc
yum install gcc
# 把下载好的redis‐5.0.3.tar.gz放在/usr/local文件夹下，并解压
tar xzf redis‐5.0.3.tar.gz
cd redis‐5.0.3
# 进入到解压好的redis‐5.0.3目录下，进行编译与安装
make
# 修改配置
daemonize yes #后台启动
protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
# 需要注释掉bind
#bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip,代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

# 启动服务
src/redis‐server redis.conf
# 验证启动是否成功
ps ‐ef | grep redis
# 进入redis客户端
src/redis‐cli
# 退出客户端
quit
# 退出redis服务：
（1）pkill redis‐server
（2）kill 进程号
（3）src/redis‐cli shutdown

安装上述的步骤redis安装就已经完成了。测试是否安装启动成功；如下图：

这些都是辅助工作。接下来我们就谈一下今天分享的重点内容，redis持久化。

二、RDB持久化配置与详解

RDB持久化也叫RDB快照（snapshot）。在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集：# save 60 1000 //关闭
在redis的配置文件（redis.conf）里面可以配置自动保存的策略，如下图：

默认的策略：900s内有一个改动，300s内有10个改动，60s内有10000个改动都会触发rdb的持久化。当然，客户端也可以手动触发持久化。
RDB只需要将所有的save保存策略注释掉即可还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

这里解释一下上面提到的bgsave，这是一种写时复制机制（COW）

Redis 借助操作系统提供的写时复制技术（Copy-On-Write, COW），在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

那save和bgsave有什么区别和联系？

1. save是同步去执行持久化的，而bgsave是异步执行持久化的
2. save它会阻塞客户端的redis命令，而bgsave则不会（只是在主进程调用fork生成子进程时可能有短暂的阻塞）
3. save不会消耗额外内存，bgsave由于要创建子进程，所以需要消耗额外内存

AOF配置与详解

如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中(先写入os cache，每隔一段时间fsync到磁盘)。redis默认是采用rdb作为持久化的。所以，要使用AOF，先必须开启。在redis的配置文件中配置就行了。如下：

appendonly no  //默认是no，改为yes 然后需要重启redis

重启后，redis的根目录下面会出现一个appendonly.aof文件。这个文件里面保存的就是我们客户端发送过来的redis操作命令。只不过，aof他是采用一种resp格式来保存。例如，我在客户端执行一条“set name luxiaohua",appendonly.aof文件内容如下：

这是一种resp协议格式数据，星号后面的数字代表命令有多少个参数，$号后面的数字代表这个参数有几个字符。
注意，如果执行带过期时间的set命令，aof文件里记录的是并不是执行的原始命令，而是记录key过期的时间戳，例如：
set wife xiaohua ex 10
aof文件内容：

只有这样，重启redis时，redis会自动根据aof文件里的命令帮我们重建缓存中的数据。
那redis到底多久将redis客户端发送的命令刷新到aof文件里面那？redis.conf文件里面也是可以配置的。

appendfsync always   //每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全
appendfsync everysec  //每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据
appendfsync no   //从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

AOF文件重写

为什么要重写AOF文件那？

*2
$4
incr
$7
tuofafa
*2
$4
incr
$7
tuofafa
*2
$4
incr
$7
tuofafa
*2
$4
incr
$7
tuofafa

其实上面aof文件记录的就是incr tuofafa这条命令执行了4次。最终。我们get tuofafa的时候返回的值肯定是4,但是我们aof文件记录的是redis命令。所以，这就导致一旦我们的redis宕掉以后恢复数据的时候会比较慢？那怎么办？重写AOF，
AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件
配置AOF重写也是在redis.conf文件里面：

auto-aof-rewrite-percentage 100   //aof文件自上一次重写后文件大小增长了100%则再次触发重写
auto-aof-rewrite-min-size 64mb    //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大

当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF
注意，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响
生产环境可以都启用，redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。

Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。

开启混合持久化：
设置为true

aof-use-rdb-preamble no   //ture表示开启 4.0以上版本默认是开启状态

总结

Redis三种持久化总结

Redis有三种持久化方式。RDB有save和bgsave两种。save是同步的方式，会阻断Redis客户端发送的命令。但是不会额外消耗内存。bgsave是异步的方式，他是通过主线程fork一个子线程，在子线程中完成持久化操作的。会消耗额外的内存。AOF他是通过记录Redis执行的命令来完成数据的重建。当然，AOF 的文件肯定要不RDB庞大的多，所以，恢复起来肯定也比RDB慢。RDB中是二进制文件，AOF中是resp格式数据。AOF虽然慢但是数据不容易丢失，RDB容易丢失数据。AOF重写就是对AOF中的指令进行一个优化，直接记录最终的修改结果而放弃对过程的修改。看的出来这两种持久化策略都各有优缺点。所以，混合持久化可以理解为结合了两者的优点。

相关命令总结

1 save 60 10   //设置rdb持久策略
2 appendonly yes/no   //开启或关闭AOF持久化 

## aof刷新的策略
3 appendfsync always  //每次有新命令追加到aof文件时就执行一次
4 appendfsync everysec  //每秒执行一次
5 appendfsync no  //从不fsync 将数据交给操作系统处理 

## aof重写的策略
6 auto-aof-rewrite-min-size 64mb   //aof文件至少要达到64M才会自动重写
7 auto-aof-rewrite-percentage 100  //aof文件自上一次重写文件大小增长了100%再次触发重写
## 配置混合持久化
8 aof-use-rdb-preamble yes   //必须先开启aof

在目前的生产环境中，这种混合持久化比较受欢迎。因为它最大程度保证数据不丢失以及最快速度恢复。