redis持久化机制

redis持久化

 

redis的数据存在内存中，所以存取性能好。但是存在内存中的数据存在一个问题，一旦机器重启，内存数据消失。为了解决这个问题，redis支持持久化。持久化就是为了解决内存数据丢失时恢复数据的，而不是为了将暂时不用的数据转移到硬盘。

 redis存储数据达到内存上限时，再也存不进去数据的，会报错。实际生产环境中，我们最好保证数据最大量不超过内存的上限的一半。这个理由后面会讲到。

缓存穿透：某个不存在的值被频繁请求，缓存不存在，请求数据库，数据库中也不存在，每次都去请求数据库。

缓存雪崩：所有的缓存都失效了。

持久化可以理解为就是把内存数据副本存在硬盘中，这样内存数据丢失时可以从硬盘中恢复。

redis支持两种方式的持久化，RDB（内存快照）和AOF（日志追加）。RDB也可理解为半持久化，也是redis默认的持久化方式。AOF的持久化更好，但是对性能有影响。实际生产中是两种方式并用。

VM虚拟内存已经不再推荐，严重影响性能

   1 ：RDB 内存快照

   RDB称为内存快照，将内存中的数据快照按照我们设定的配置周期性的写入硬盘。

  原理：

1. redis调用fork,现在有了子进程和父进程。
2. 父进程继续处理client请求，（不阻塞）子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。（如果在整个子进程将数据写入硬盘过程中，无任何写请求，那么父子进程共享 内存数据。一旦有写操作，会copy一份副本。如果copy了一份副本，那么将占用双倍的内存，这就是为什么生产环境中力求数据量不超过内存一半的原因）

       3. 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出（fork一个进程入内在也被复制了，即内存会是原来的两倍）。

save和bgsave命令也会触发RDB，进行持久化。save命令启用主进程进行持久化，期间会阻塞客户端请求，用得少。bgsave命令会启用子进程进行持久化，和上面的原理一样。

   RDB持久化会丢失上次备份到奔溃这段时间内的数据，用来做冷备份还是不错的。如果想获得更好的持久性，AOF更合适。但是AOF得性能要差一些

 

2 ：AOF 日志追加  默认不开启

AOF会把redis服务器的每一次写操作写入appendonly.aof文件中，这个文件存在硬盘中。如果内存失效，redis服务器会从这个文件中读取命令，进行恢复。操作系统本身的缓存机制使得appendonly.aof的追加不会立即写入硬盘，重启时也会丢失部分修改写操作。通过redis配置可以强制将缓存立即写入硬盘。

aof方式会使得.aof文件越来越大。通过配置，可以定期的对.aof文件进行重写。命令bgrewriteaof，可以对aof文件进行重写。

下面是重写.aof文件的原理，而不是日志追加的原理。日志追加就是往.aof文件末尾追加。

 1.  redis调用fork ，现在有父子两个进程
       2. 子进程根据fork时刻内存中的数据库快照，往临时文件中写入重建数据库状态的命令（也遵守写时复制）
       3. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
       4. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
       5. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

 

 

一般对redis做主从同步，主机不开启任何持久化策略，保证最好的性能。而在从机上进行持久化，持久化采用两种策略结合的方式