就目前自己的理解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