因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。（推荐学习：Redis视频教程）
Redis 的持久化机制有两种，第一种是快照，第二种是 AOF 日志。快照是一次全量备份，AOF 日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。AOF 日志在长期的运行过程中会变得无比庞大，数据库重启时需要加载 AOF 日志进行指令重放，这个时间就会无比漫长，所以需要定期进行 AOF 重写，给 AOF 日志进行瘦身。
快照原理
我们知道 Redis 是单线程程序，这个线程要同时负责多个客户端套接字的并发读写操作和内存数据结构的逻辑读写。
在服务线上请求的同时，Redis 还需要进行内存快照，内存快照要求 Redis 必须进行文件 IO 操作，可文件 IO 操作是不能使用多路复用 API。
这意味着单线程在服务线上请求的同时，还要进行文件 IO 操作，而文件 IO 操作会严重拖累服务器请求的性能。
还有个重要的问题，为了不阻塞线上的业务，Redis 就需要一边持久化，一边响应客户端的请求。持久化的同时，内存数据结构还在改变，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它给删掉了，可是还没持久化完呢，这该怎么办呢？
Redis 使用操作系统的多进程 COW（Copy On Write）机制来实现快照持久化，这个机制很有意思，也很少人知道。
AOF原理
AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。
假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过对一个空的 Redis 实例顺序执行所有的指令——也就是“重放”，来恢复 Redis 当前实例的内存数据结构的状态。
Redis 会在收到客户端修改指令后，进行参数校验、逻辑处理，如果没问题，就立即将该指令文本存储到 AOF 日志中，也就是说，先执行指令才将日志存盘。这点不同于 leveldb、hbase 等存储引擎，它们都是先存储日志再做逻辑处理。
Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF 日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志瘦身。
更多Redis相关技术文章，请访问Redis数据库使用入门教程栏目进行学习！
以上就是redis宕机了怎么办的详细内容，更多请关注自由互联其它相关文章！