就目前自己的理解redis和memcache的区别就是redis可以数据持久化，支持的数据类型有5种

所以就数据持久化这块可以好好了解一下

我们安装的redis的2.6版本，安装之后默认就已经开启了rdb

数据持久化分rdb和aof

快照:(snapshotting)它将某一时刻的的所以数据写入硬盘

只追加文件:(append-only file) 他会在执行写命令时，将会把写命令复制到磁盘里面

快照（rdb）：

save 900 1     #900秒时间，至少有一条数据更新，则保存到数据文件中

save 300 10    #300秒时间，至少有10条数据更新，则保存到数据文件中

save 60 10000  #60秒时间，至少有10000条数据更新，则保存到数据文件中

rdbcompression yes  #指定存储至本地数据库时是否压缩数据，默认是yes，redis采用LZF压缩，如果为了节省CPU时间 #可以关闭该选项，但会导致数据库文件扁的巨大

dbfilename dump.rdb #指定rdb保存到本地数据库文件名

stop-writes-on-bgsave-error yes  #当硬盘因为权限等原因无法写入时，停止写入

rdbchecksum yes    #对rdb文件进行校验

创建快照的方式有以下4种：

1，客户端执行BESAVE，服务端会fork一个子进程来负责将快照写入硬盘，父进程继续处理写请求

2，客户端执行save，服务端会在创建快照完毕之前不在响应其他的命令，一般没有足够的内存去执行BESAVE的情况下才会去执行save，一般没有用这个

3，当redis服务端接受了一个shutdown的时候，或收到一个标准TERM信号（kill）的时候,会执行一个SAVE，会阻塞所以客户端请求，然后执行完save之后关闭服务

4，当作redis主从的时候（请看我的另一篇博客redis主从同步)

个人感觉如果对数据的保存有特别高的要求，就不要用rdb可以用aof

只追加文件(aof):

#appendonly no   #是否在每次更新操作后进行日志记录，是否开启启用aof。

# appendfsync always       # always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全，最好不要用这个会很损害硬盘的） 

#appendfsync everysec       # everysec：表示每秒同步一次（折衷，默认值）

#appendfsync no             # no：表示等操作系统进行数据缓存同步到磁盘（快）\

#

#auto-aof-rewrite-percentage 100

#auto-aof-rewrite-min-size 64mb

当aof体积大于64mb的时候，并且aof文件的体积比上次重写之后的体积大于至少一倍（100%）的时候，redis执行bgrewriteaof

no-appendfsync-on-rewrite   no#如下面的解释

bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。

现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。

因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no

本文出自 “王小酸” 博客，转载请与作者联系！

redis的数据持久化