标签:
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做主从同步,主机不开启任何持久化策略,保证最好的性能。而在从机上进行持久化,持久化采用两种策略结合的方式
标签:
原文地址:http://www.cnblogs.com/taijun/p/4611155.html