edis持久化方案包括(edis持久化方案有哪些)

导语：redis持久化方案

持久化背景

记得几年前，还有很多人会纠结和调研，redis和memcached的区别和优缺点，甚至面试时也会经常被问到。这几年不多了，因为大部分场景都在用redis，成了缓存中间件的默认选型。

为什么redis会胜出呢，其他一个原因应该就是他的持久化能力。一个缓存中间件，为什么要进行持久化呢，这里面有两方面的诉求：

1、缓存数据快速恢复（日常运维诉求&异常运维诉求）

缓存服务日常重启，或者服务异常（比如宕机）之后重启，内存中的数据都会丢失。而现在缓存数据越来越复杂，缓存数据量也越来越大，要想完全恢复需要一定的时间，时间长了业务可能会受到影响；而且在编码实现上会有一定的投入，整体上看架构方案不太优雅。

2、避免缓存数据丢失的风险

现在的缓存场景，有很多是一件没有MySQL等持久层兜底，数据加工之后直接到redis，日常或异常重启之后，数据就会丢失。

持久化方案

redis持久化方式主要有三种，第一种是快照，第二种是AOF日志，第三种是混合持久化。

快照（RDB)持久化

快照持久化是把内存中的缓存数据，通过二进制序列化的方式存储到磁盘上。

redis快照持久化

redis在实现快照持久化功能时，是把持久化处理和读写请求处理分开的。这里快照持久化时会调用glibc的函数fork出一个子进程，专门用来进行持久化操作持久化过程中，有些数据会存在更新操作，那持久化是怎么实现的呢？这里用到了操作系统的多进程COW（copy on write）机制

COW机制

缓存数据存储在n个数据页（每个页4k）上，对某个数据进行操作，数据所在的页将会复制一份出来进行读写，确保快照操作的数据不变，还是当时时刻的数据

快照持久化优势

1、数据存储紧凑，占用的存储空间较小

2、重启数据恢复效率较高

快照持久化不足

1、持久化比较耗性能，一般定期持久化，期间产生的数据存储丢失风险（如果服务异常或宕机）

AOF日志持久化

AOF日志持久化是存储对缓存修改的指令记录。类似于修改命令的记录日志。

AOF日志持久化

这里指令记录是实时写入到内存缓存，但是如果只是协同到内存缓存，未到刷新到磁盘，还是存在丢失的风险。linux操作系统提供fsync函数刷新到磁盘，

fsync--指令记录更新到磁盘的时机

1、一条命令调用一次刷新 —— 刷新很及时，但是比较耗性能

2、不主动调用，控制器让给操作系统 —— 比较危险，可能很长时间才会调用一次

3、定时调用（1秒） —— 定时刷新到磁盘，选用比较多的方案，在安全和性能之间的权衡方案

另外，redis也提供了定时对之前的AOF日志进行重写的bgrewriteaof命令，fork一个子进程，便利内存转化成一系列的更新指令，重新存储和特换，可以减少aof的存储空间。

AOF日志持久化优势

1、可以做到今后实时的持久化，服务异常时可降低数据丢失量（aof秒级，rdb分钟级）

AOF日志持久化不足

1、比较占用存储空间，重启恢复时比较耗时（重启恢复一般不会选用它）

混合持久化

混合持久化是在redis4.0开放出来的特性，结合快照持久化和AOF日志持久化的优势，组合形成的持久化方案。

此方案缓存持久化数据是由快照持久化 + AOF日志持久化组合形成的，前大部分是由快照持久化存储，后小部分是在快照持久化的基础上AOF日志持久化存储的。运行过程中不断推进快照持久化的大小。

混合持久化

本文内容由小海整理编辑！