如果redis停机了怎么办？
所以必须有一个机制来保证Redis的数据不会因为失败而丢失，这个机制就是Redis的持久化机制。(推荐学习:Redis视频教程)
Redis有两种持久化机制，第一种是快照，第二种是AOF日志。快照是完整备份，AOF日志是连续增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而AOF日志记录的是内存数据修改的指令记录文本。在长期的运行过程中，AOF日志会变得极其庞大。数据库重启时需要加载进行指令重放，这个时间会特别长。因此，有必要定期重写AOF日志来瘦身AOF日志。
快照原理
我们知道Redis是一个单线程程序，这个线程负责多个客户端套接字的同时读写和内存数据结构的逻辑读写。
在服务在线请求的同时，Redis还需要拍摄内存快照，这需要Redis执行文件IO操作，但文件IO操作不能使用多路复用API。
这意味着单个线程在服务在线请求的同时必须执行文件IO操作，文件IO操作会严重拖累服务器请求的性能。
还有一个重要的问题。为了不阻塞在线业务，Redis需要在响应客户端请求的同时坚持。持久化的同时，内存中的数据结构还在变化。例如，一个大的散列字典正在被持久化，一个请求来删除它，但是它还没有被持久化。我该怎么办？
Redis利用操作系统的多进程COW(写时复制)机制实现快照持久化，很有意思，也鲜为人知。
AOF原则
AOF日志存储Redis服务器的顺序指令序列，AOF日志只记录修改内存的指令记录。
假设AOF日志记录了Redis实例创建以来所有修改过的指令序列，那么通过在一个空的Redis实例上顺序执行所有指令，即“replay”，就可以恢复Redis当前实例的内存数据结构的状态。
Redis收到客户端修改指令后，会进行参数验证和逻辑处理。如果没有问题，它会立即将指令文本存储在AOF日志中，也就是说，该指令会在日志保存之前执行。这与leveldb、hbase等存储引擎不同，它们都是先存储日志，再做逻辑处理。
在Redis的长期运行过程中，AOF的日志会越来越长。如果实例宕机重启，重放整个AOF日志会非常耗时，导致Redis长时间无法对外提供服务。所以我们需要精简AOF日志。
更多Redis相关技术文章，请访问Redis数据库，使用入门教程专栏学习！