作为集中式缓存的优秀代表Redis可以帮助我们在项目中完成很多特定的功能。Redis准确的说是一个非关系型数据库但是由于其超高的并发处理性能及其对于缓存场景所提供的一系列能力构建使其成为了分布式系统中的集中缓存的绝佳选择。

数据持久化方案

除了容量有限之外数据丢失无疑是存储在内存中的数据最大的风险点。

因为内存中的数据是非持久化存储的一旦断电或者出现系统异常等情况很容易导致内存数据丢失。所以大部分的系统里面都只是将内存型缓存用作数据库的辅助扛压最终的数据存储在DB等可以持久化存储容器中同步一份数据到缓存中用于并发场景下的业务使用。

这种组网场景下Redis的数据其实是没有持久化的诉求的因为Redis中数据仅仅是一份副本最终数据在DB中都有。即使系统异常或者掉电重启也可以基于数据库的数据进行缓存重建 —— 最多就是数据量特别巨大的时候重建缓存的耗时会比较长。

另外一种场景业务里面会有有些写操作会比较频繁、强依赖Redis特性来实现的功能这部分数据不能丢、但又没有重要到必须每次更新都需要存入DB的地步。比如博客系统中的文章阅读量数据文章每次被读取都需要更新阅读数写操作非常频繁如果阅读量存储到DB中会导致DB压力较大这种情况就希望可以将数据存储在内存中然后内存数据可以持久化保存。

Redis提供了多种持久化方案可以实现将内存数据定期存储到磁盘上重启时候可以从磁盘加载到内存中以此来避免数据的丢失。

RDB全量持久化模式

全量模式很好理解就是定时将当前内存里面所有的key-value键值对内容全部导出一份快照数据存储到磁盘上。这样下次如果需要使用的时候就可以从磁盘上加载快照文件实现内存数据的恢复

RDB全量模式持久化将数据写入磁盘的动作可以分为SAVE与BGSAVE两种。所谓BGSAVE就是background-save也就是后台异步save区别点在于SAVE是由Redis的命令执行线程按照普通命令的方式去执行操作而BGSAVE是通过Fork出一个新的进程在新的独立进程里面去执行save操作。

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据变量、环境变量、程序计数器等 数值都和原进程一致但是是一个全新的进程并作为原进程的子进程

• 在Linux程序中fork()会产生一个和父进程完全相同的子进程但子进程在此后多会exec系统调用出于效率考虑Linux中引入了“写时复制技术”

• 一般情况父进程和子进程会共用同一段物理内存只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程。
  

Redis的请求命令执行是通过单线程的方式执行的所以要尽量避免耗时操作而save动作需要将内存全部数据写入到磁盘上对于redis而言这一操作是非常耗时的会阻塞住全部正常业务请求所以save操作的触发只有两个场景

• 客户端手动发送save命令执行
• Redis在shutdown的时候自动执行
  从数据保存完备性方面看这两种方式都起不到自动持久化备份的能力如果出现一些机器掉电等情况是不会触发redis shutdown操作的将面临数据丢失的风险。

相比而言bgsave的杀伤力要小一些、适用度也更好一些它可以保证在持久化期间Redis主进程可以继续处理业务请求。bgsave增加了过程中自动持久化操作的机制触发条件更加的“智能”

• 客户端手动命令触发bgsave操作
• Redis配置定时任务触发支持间隔时间+变更数据量双重维度综合判断达到任一条件则触发

此外在master-slave主从部署的场景中还支持仅由slave节点触发bgsave操作来降低对master节点的影响。
值得注意的是在fork子进程的时候需要将redis主进程中内存所有数据都复制一份到子进程中所以bgsave操作实际上是将子进程内存中的数据快照导出到磁盘上在执行期间对机器的剩余内存有较高要求如果机器剩余内存不足则可能导致fork的时候两份内存数据量超过机器物理内存大小导致系统启用虚拟内存拷贝速度大打折扣虚拟内存本质上就是把磁盘当内存用操作速度相比物理内存大大降低会阻塞住Redis主进程的命令执行。

如果开启了RDB的bgsave定时触发执行机制在出现异常掉电等情况可能会丢失最后一部分尚未来及持久化的内容。在恢复的时候Redis启动之后会先去读取RDB文件然后将其写入内存中恢复此前的缓存数据数据恢复期间不受理外部业务请求。

优势

适合大规模的数据恢复、对数据完整性和一致性要求不高更适合使用、节省磁盘空间、恢复速度快

劣势

1. Fork的时候内存中的数据被克隆了一份大致2倍的膨胀性需要考虑

2. 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

3. 在备份周期在一定间隔时间做一次备份所以如果Redis意外down掉的话就会丢失最后一次快照后的所有修改

AOF增量同步方式

RDB全量模式简单粗暴直接将内存全量数据存储为快照序列化到本地。AOFAppend Only File与RDB的思路不同AOF更像是记录住Redis的每一次写请求执行命令将每次执行的写操作命令记录存储到磁盘上然后通过一种类似命令重放执行的方式来实现数据的恢复。

AOF持久化流程

1客户端的请求写命令会被append追加到AOF缓冲区内

2AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中

3AOF文件大小超过重写策略或手动重写时会对AOF文件rewrite重写压缩AOF文件容量

4Redis服务重启时会重新load加载AOF文件中的写操作达到数据恢复的目的

AOF具体实现的时候包含几种不同的策略
appendfsync always

可以简单的理解为每一条redis写请求执行的时候会触发一次磁盘写入操作且只有在磁盘写入完成之后请求的响应才会返回。这种方式可以保证AOF记录的准确性但是会严重影响Redis的并发吞吐量。

appendfsync everysec

异步执行任务执行线程执行命令后将命令写入任务放入队列中由子线程异步方式每秒一次将执行命令分批写入文件中相比always方式在异常情况下可能会丢失最后1s的执行记录但可以大大降低对redis命令执行效率的影响。

appendfsync no

redis不控制落盘时间由操作系统去决定什么时候该往磁盘flush这种情况一般不推荐使用无法准确掌控是否落盘可靠性不够。

AOF的方式落盘持久化的时候每次仅写入增量的部分所以对系统整体运行期的影响较小但随着系统在线运行时长的累加AOF中存储的命令也越来越多这样问题也随着出现

• AOF写入的方式类似与日志打印将请求追加写入到磁盘文件中文本文件未经过压缩时间久了之后会占据大量磁盘空间易造成磁盘满的问题。

• 在需要从AOF文件回放重新构建缓存内容时可能会耗时较久相当于要将长期累积下来的写操作命令逐个重新执行一下。

Rewrite压缩

AOF采用文件追加方式文件会越来越大为避免出现此种情况新增了重写机制, 当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

重写原理

AOF文件持续增长而过大时会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)redis4.0版本后的重写是指上就是把rdb 的快照以二级制的形式附在新的aof头部作为已有的历史数据替换掉原来的流水账操作。

no-appendfsync-on-rewrite

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存用户请求不会阻塞但是在这段时间如果宕机会丢失这段时间的缓存数据。降低数据安全性提高性能

如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷但是遇到重写操作可能会发生阻塞。数据安全但是性能降低

触发机制何时重写

Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发重写虽然可以节约大量磁盘空间减少恢复时间。但是每次重写还是有一定的负担的因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage设置重写的基准值文件达到100%时开始重写文件是原来重写后文件的2倍时触发
auto-aof-rewrite-min-size设置重写的基准值最小文件64MB。达到这个值开始重写。

例如文件达到70MB开始重写降到50MB下次什么时候开始重写100MB
系统载入时或者上次重写完毕时Redis会记录此时AOF大小设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下Redis会对AOF进行重写。

重写流程

1bgrewriteaof触发重写判断是否当前有bgsave或bgrewriteaof在运行如果有则等待该命令结束后再继续执行。

2主进程fork出子进程执行重写操作保证主进程不会阻塞。

3子进程遍历redis内存中数据到临时文件客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

4子进程写完新的AOF文件后向主进程发信号父进程更新统计信息主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

5使用新的AOF文件覆盖旧的AOF文件完成AOF重写。

优势

• 备份机制更稳健丢失数据概率更低。

• 可读的日志文本通过操作AOF稳健可以处理误操作。

劣势

比起RDB占用更多的磁盘空间。恢复备份速度要慢。 每次读写都同步的话有一定的性能压力。存在个别Bug造成恢复不能。

RDB与AOF混合使用

RDB在过程中每次写磁盘的时候对Redis业务处理的性能影响较大但是从磁盘加载到内存重建缓存的时候效率很高。

AOF通过增量的方式降低了运行过程中对Redis业务处理的影响但是命令回放重建缓存的时候效率较差。
如果将两者结合起来使用是否可以取长补短呢事实似乎的确如此。从4.0版本开始Redis支持了RDB + AOF的混合持久化方式通过rewrite机制来实现。需要在redis的配置文件中开启对应开关

aof-use-rdb-preamble yes

开启之后redis在每次执行aof操作的时候会判断下是否达到了触发rewrite的条件如果达到则fork出一个新的子进程进行RDB操作将当前时刻全量内存数据生成RDB数据然后写入到AOF文件中而后续的写操作命令则继续append方式追加记录到AOF文件中。这样一来AOF文件实际上由两部分内容组成。如下图所示

通过RDB + AOF混合的策略很好的实现了两者的优势互补

• 先通过AOF的方式记录命令达到门槛的时候才执行rewrite操作生成RDB最大限度降低了RDB执行频率降低了对redis业务命令处理过程的影响。

• 通过RDB的方式替代了前期大量的AOF命令存储有效的降低了磁盘占用。

• 通过RDB(恢复数据快) + AOF解决RDB部分数据丢失问题的方式系统重建缓存的时候先加载RDB文件完成主体数据的重建然后在此基础上重放AOF增量命令大大降低了启动时AOF重放的耗时。

两种策略同时开启

AOF和RDB同时开启系统默认取AOF的数据数据不会存在丢失