redis

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

1 Redis是一个纯内存数据库，通常是一个简单的存取操作， 线程占用大量时间。 时间主要集中在IO上，因此读取速度很快。
2. 谈到IO，Redis使用非阻塞IO，IO多路复用，使用单个线程轮询描述符，将数据库的开、关、读、写都转换成了事件，从而减少了线程切换上下文的切换和竞争。
3. Redis使用单线程模型来确保每个操作的原子性，并且还减少了线程上下文切换和竞争。
4. 此外，数据结构也有很大帮助。 Redis在整个过程中都使用哈希(hash)结构，该结构易于读取。还有一些特殊的数据结构，对数据存储进行了优化，例如压缩表以及压缩和存储短数据。 比如，跳表，使用有序数据结构来加快读取速度。
5.还有一点，Redis使用其自己的事件分离器，这是相对有效的。 它在内部使用非阻塞执行方法，并且具有较大的吞吐量。

---

提示：以下是本篇文章正文内容，下面案例可供参考

Redis操作

redis下载配置

第一步:安装gcc :
		yum install gcc
第二步：编译并安装
		cd redis-5.0.5
		make MALLOC=libc
第三步： 安装
		将redis-5.0.5/src目录下二进制文件安装到指定的目录中
		cd src
		make install PREFIX=/usr/local/redis
第四步: 配置环境变量
		vi /etc/profile: 编辑配置文件
		export REDIS_HOME=/usr/local/redis
		export PATH=$PATH:$REDIS_HOME/bin
		source /etc/profile 刷新使配置文件生效
第五步：修改配置文件
		默认的配置文件是/opt/install/redis-5.0.5/redis.conf
3.1 设置后台启动
将 daemonize no 改成 daemonize yes
3.2 下面一行必须改成 bind 0.0.0.0 或注释，否则只能在本机访问
bind 127.0.0.1
3.3 把protected yes 该为：protected no
3.4 并拷贝到/usr/local/redis/bin目录中一份

常用redis安装指令

redis-benchmark: 性能测试工具，可以在自己本子运行，看看自己本子性能如何
redis-check-aof： 修复有问题的AOF文件
redis-check-dump：修复有问题的dump.rdb文件
redis-sentinel： Redis集群中会使用，哨兵模式
redis-server： redis服务器启动命令
redis-cli： redis客户端启动命令

redis的启动

指定配置文件启动Redis
redis-server /usr/local/redis/bin/redis.conf

启动客户端： redis-cli -h IP地址 -p 端口号
	提示：1.不指定 -h -p的情况下,默认连接客户端所在机子的redis服务器
		 2.参数作用：
		 	-h： 指定访问的redis服务器的ip地址
		 	-p： 指定访问的redis服务器的port端口
		 	-a: 指定登录密码
			 --raw: 解决中文乱码问题
		 3.redis默认使用的端口号为: 3306
关闭客户端：
quit|exit:都是退出客户端
shutdown: 在客户端关闭服务器端.

Redis的常用类型指令使用

• key类型的使用

• expire key seconds     设置key的生存时间(时间到期后会自动删除)
  ttl key				   查看key剩余的生存时间  (正数为剩余时间, -1为 永不过期,-2表示不存在)
  persist  key		   清楚生存时间
  pexpire  key milliseconds    生存时间设置单位为: 毫秒
  ==========================================================================
  keys *				查看当前库中所有key
  exists key			判断某个key是否存在
  type key			查看key的类型
  del key				删除指定key
  ==========================================================================
  select			命令切换数据库
  dbsize			查看当前数据库的key数量
  flushdb			清空当前库
  flushall		清空所有库
  move newkey		将某库的key移动到别的库
  

• String类型的使用(字符串类型是redis中最为基础的数据存储类型, 在redis中是二进制安全的,可以接受任何格式的数据)

• set key value     	赋值命令
  get key				取值命令(不存在返回 nil)
  mset key1 value1 key2 value2...			赋多个值命令
  getset key value	取值并赋值(相当于修改)
  del key				删除
  incr key			自增长数值
  incrby key nun		自增长指定num步长
  decr key			递减数值
  decrby key nun		递减指定num步长
  append key value	拼凑字符串
  

  setbit key num1 num2  设置当前key，第num1位，为num2（此处是进行字节操作，一个字节有8位，即0-7）
  例：setbit sunday 10000000 0
  bitcount key num1 num2 计算key，第num1个字节，到第num2个字节，出现过多少个1
  bitpos
  bitop or/and key1 key2 key3...  对key2,key3...进行位运算,结果赋值给key1
  
  使用场景：
  1、进行用户的登录统计
  setbit 用户id 第几天 1 （1表示登录）
  之后使用bitcount进行统计
  2、统计近期的活跃用户
  setbit 日期1 第几号用户 1
  setbit 日期2 第几号用户 1
  setop or 结果 日期1 日期2
  之后使用bitcount统计
  

• Hash类型的使用(适用于 存储对象, 表中的数据)

• hset key field value		赋值(key:value)
  hmset key field1 value1 field2 value2  多个赋值
  hget key field				取值
  hmget key field1 field2		多个取值
  hgetall key					获取所有字段和值
  hkeys key					获取所有的字段
  hvals key					获取所有的值
  hdel  key field				删除指定字段和值
  hincrby key field num		增加指定数值
  hexists key field			判断是否存在
  hlen key					获取字段的数量
  

• List类型的使用(队列先进先出,栈后进先出的数据结构=>粉丝列表,关注的人,汇总日志(排序),空间的说说等)

• lpush key value		向列表左边增加元素(头部)
  rpush key value		想列表右边增加元素(尾部)
  lrange key start stop 查看列表(lrange key 0 -1 查看所有)
  lpop key			列表左边弹出一个元素
  rpop key			列表右边弹出一个元素
  llen key			获取列表中的元素个数
  

• set 类型的使用(签到去重,打卡去重,点赞去重,抽奖随机弹出)

• sadd key value			增加元素(多个)
  srem key value			删除集合中的指定元素
  smembers key			获取集合中的所有元素
  sismember key value		判断是否存在
  sdiff key1 key2			集合差集运算(key1的独有)
  sinter key1 key2		集合交集运算(共有部分)
  sunion key1 key2		集合并集运算(包含k1 k2)
  scard key				取得集合成员数量
  srandmember key			随机返回一个set中的一个成员
  

• zset类型的使用(商品销售排行榜,游戏排行榜,热点搜索)

• zadd key score1 member1 score2 member2		向有序集合中加入一个元素和该元素的数值(如果已经存在会进行覆盖)
  zscore key	member 			获取元素的数值
  zrem key member				移除元素(可多个移除)
  zset key					获取集合元素个数
  zrange key start stop		按顺序获取元素(小到大)
  zrevrange key start stop	按照顺序获取元素(大到小)
  

• 非常用类型包含

• Geospatial ==>> 推算地理位置 
  HyperLogLogs ==>>   用于做基数统计算法
  Bitmaps		==>>    面向比特位的操作
  

Redis事务（可以开启事务，但是不具备ACID以及回滚）

Redis 的作者在事务功能的文档中解释说，不支持事务回滚是因为这种复杂的功能和 Redis 追求的简单高效的设计主旨不符合，并且他认为，Redis 事务的执行时，错误通常都是编程错误造成的，这种
错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为 Redis开发事务回滚功能。

悲观锁,乐观锁

• 悲观锁

 每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
 
 导致性能比较低

• 乐观锁

 每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。
 乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的。

在执行multi 之前, 先执行watch key1  key2.... 可以监听多个key,如果在事务执行之前,这个key 被其他命令所改动,那么事务将被打断.

Redis事务三特性
单独的隔离操作
没有隔离级别的概念
不保证原子性

Redis的使用场景

不适用的场景:
1. 取代通过键查询, 而是通过值来查询
2.需要存储数据之间的关系( 无法进行关联数据 )
3.事务的支持

适用的场景:
1. 存储用户信息, 比如会话/参数/购物车等.    一般都和id挂钩
2. 对数据高并发的读写
3. 对数据高可扩展性的

缓存/分布式session存储/分布式数据库id/计数器/限流(incr,当某人访问过几次之后就不让访问了)

Redis 最佳应用场景：适用于数据变化快【高频修改】且数据库大小可遇见（适合内存容量）的应用程序。
Memcache 最佳应用场景:适于存储的数据结构简单(仅k/v)，提升性能;做缓存，提高性能（适合读多写少）
MongoDB:解决海量数据访问效率问题,特点：面向文档，适合修改少，读取多的场景，支持丰富的查询语言。

事务之秒杀案例

秒杀分析:
1.redis服务器没有库存: 只有到秒杀一刻,秒杀商品才进入到redis服务器,所以用户提前秒杀不成功
2.如果有库存的情况下:
	2.1 秒杀不成功:
			该客户已经秒杀过一件该商品了,不能再次参与
			已经秒杀玩了,没有库存了
	2.2 如果秒杀成功
			将库存商品减一,然后将秒杀成功的用户id保存到一个集合中

在redis服务端我们只需要保存商品的库存和秒杀成功的用户id
保存商品库存： key: sk:prodid:stock value:剩余个数
保存用户id ： key: sk:prodid:user value:set集合【里面是成功用户的id值,去重】

利用乐观锁淘汰用户,解决超卖问题

//增加乐观锁
jedis.watch(qtkey);
//3.判断库存
String qtkeystr = jedis.get(qtkey);
if(qtkeystr==null || "".equals(qtkeystr.trim())) {
    System.out.println("未初始化库存");
    jedis.close();
    return false ;
}
int qt = Integer.parseInt(qtkeystr);
if(qt<=0) {
    System.err.println("已经秒光");
    jedis.close();
    return false;
}
//增加事务
Transaction multi = jedis.multi();
//4.减少库存
//jedis.decr(qtkey);
multi.decr(qtkey);
//5.加人
//jedis.sadd(usrkey, uid);
multi.sadd(usrkey, uid);
//执行事务
List<Object> list = multi.exec();
//判断事务提交是否失败
if(list==null || list.size()==0) {
    System.out.println("秒杀失败");
    jedis.close();
    return false;
}
System.err.println("秒杀成功");
jedis.close();


但是会存在库存问题

补充

提示：这里对文章进行补充：

Redis持久化机制

• RDB持久化
  • 在指定的时间间隔内将内存中的数据集生成快照保存在磁盘中,相当于快照功能,它恢复时是将快照文件直接读到内存里.
  • 在redis.conf 中配置文件名称,默认为dump.rdb
  • 存放位置 : 默认放在redis启动时命令行所在的目录下
  • 手动触发 : 分别对应3个命令save , bgsave 和shutdown
    • save : 阻塞当前redis服务器,直到rdb过程完成为止. ( 线上环境不建议使用 )
    • bgsave : redis 进程执行fork 操作创建子进程 , rdb 持久化过程由子进程负责. 基本上redis内部所有的rdb操作都是采用bgsave命令.redis会在后台异步进行快照操作,快照同时还可以响应客户端请求.
    • shudown : 会将内存中的数据持久化到磁盘上, 也会生成rdb文件

补充:  fork 作用:
1. 复制一个与当前进程一样的进程.  新进程的所有数据与原进程一致.但是是一个全新的进程, 并作为原进程的子进程.
2. 在linux程序中, fork一样的进程, 但是子进程在此后会被exec系统调用.处于效率考虑,linux引入了"写时复制技术".
3.一般情况父进程和子进程会共用一段物理内存, 只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程.

• 自动触发

• save m n: 表示m秒内数据集存在n次修改时,自动触发bgsave
  案例：
  save 900 1: 表示900 秒内如果至少有 1 个 key 的值变化,则保存
  save 300 10: 表示300 秒内如果至少有 10 个 key 的值变化,则保存
  save 60 10000: 表示60 秒内如果至少有 10000 个 key 的值变化,则保存
  

• 其他常用配置项

• 1. stop-writes-on-bgsave-error    当 Redis 无法写入磁盘的话，直接关掉 Redis 的写操作。推荐 yes.
  2. rdbcompression     对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用 LZF 算法进行压缩。如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能。推荐 yes
  3. rdbchecksum    默认值是 yes。在存储快照后，我们还可以让 redis 使用 CRC64 算法来进行数据校验，但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
  

rdb 备份及数据恢复

1.备份: 将*.rdb的文件拷贝到别的地方【可以写定时脚本】
2.rdb的数据恢复
		 关闭Redis
		 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
 		 启动Redis, 备份数据会直接加载

AOF持久化

以日志的形式来记录每个写操作(增量保存), 将Redis 执行过的所有写指令记录下来( 读操作不记录 ), 只许追加文件但不可以改写文件, redis 启动之初就会读取该文件重新构建数据.

默认情况下, 是不开启的, 是需要进行手动开启.
appendonly  yes   配置开启aof
appendfilename  "appendonly.aof"		文件名为: appendonly.aof


重写aof文件的操作, 并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,类似于快照.

触发机制，何时重写
Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis 要满足一定条件才会进行重写。

备份及数据恢复

正常恢复
 	修改默认的 appendonly no，改为 yes
	 将有数据的 aof 文件复制一份保存到对应目录(查看目录：config get dir)
	 恢复：重启 redis 然后重新加载
异常恢复
 	修改默认的 appendonly no，改为 yes
 	如遇到 AOF 文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行修复
 	恢复：重启 redis，然后重新加载

AOF与RDB对比

1. 优先级: RDB 文件和AOF 文件同时存在的情况下, AOF优先级要高一些
2. 备份: RDB快照是一次全量备份,AOF 增量备份, 并且有重写机制

实际使用

1.选择的话, 两者加一起才更好, 这也是官方推荐的使用方式.
2. 因为两个持久化机制特点和自己的需求,但是通常都是集合使用
		如果对数据不敏感,可以单选RDB
		不建议单独用AOF, 因为可能会出现Bug
		如果只是做纯内存缓存,可以都不用
3.因为rdb文件只用做后备用途,建议只有slave持久化RDB文件.而且只要15分钟备份一次就够了

主从复制

Master 以写为主			Slave以读为主
读写分离, 性能扩展
容灾快速恢复

daemonize yes
pidfile /var/run/redis6379.pid
port 6379
dbfilename dump6379.conf
appendonly no
logfile ""
protected-mode no

======================================
include /usr/local/redis/bin/redis6379.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb

=======================================
include /usr/local/redis/bin/redis6379.conf
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb

主从复制有两种形式，一种是一主二仆，一种是薪火相传
开启服务后进行相关配置如下:

一主二仆(配从不配主)
进入从结点后输入  ==>>   slaveof 192.168.43.129 6379


薪火相传
上一个slave可以是下一个slave的Master.该slave作为链条中下一个的master,可以有效减轻master的写压力,去中心化降低风险.     风险是一旦中间某个slave宕机,后面的slave都没法备份
在6381结点输入  ==>>  slaveof 192.168.43.129 6380

哨兵模式

反客为主的自动版,实现主从自动切换,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

在以一主二仆的模式下进行操作.
在redis的bin目录下新建sentinel.conf 文件
sentinel monitor mymaster 127.0.0.1 6379 1
mymaster 为监控对象其的服务器名称,    1为至少有多少个哨兵同意迁移的数量

启动哨兵模式   指令==>  redis-sentinel /usr/local/redis/bin/sentinel.conf

故障恢复  ( 新主登基==>>  群仆俯首  ==> 旧主俯首  )
1. 从服务器中挑选一个主服务器,选择条件依次为:选择优先级靠前的, 选择偏移量最大的,选择runid最小的服务器
2.挑选出新的主服务之后sentinel向原主服务的从服务发送slaveof新主服务的命令,复制新master
3.当已经下线的主服务器上线时,sentinel会向其发送slaveof命令,让他成为新主的从

集群

准备6个redis服务运行的目录
cd /usr/local/redis/
mkdir redis-cluster
cd redis-cluster
mkdir 7291 7292 7293 7294 7295 7296
复制 redis 配置文件到 7291 目录
cp /usr/local/redis/bin/redis.conf /usr/local/redis/redis-cluster/7291
修改 7291 的 redis.conf 配置文件
cd /usr/local/redis/redis-cluster/7291
>redis.conf
vim redis.conf

port 7291
daemonize yes
protected-mode no
dir /usr/local/redis/redis-cluster/7291/
cluster-enabled yes #打开集群模式
cluster-config-file nodes-7291.conf #设定集群节点配置文件名(集群信息会写到该文件中)
cluster-node-timeout 5000 #设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换
appendonly yes
pidfile /var/run/redis_7291.pid

把 7291 下的 redis.conf 复制到其他 5 个目录
cd /usr/local/redis/redis-cluster/7291/
cp redis.conf ../7292
cp redis.conf ../7293
cp redis.conf ../7294
cp redis.conf ../7295
cp redis.conf ../7296
批量替换内容
cd /usr/local/redis/redis-cluster/
sed -i 's/7291/7292/g' 7292/redis.conf
sed -i 's/7291/7293/g' 7293/redis.conf
sed -i 's/7291/7294/g' 7294/redis.conf
sed -i 's/7291/7295/g' 7295/redis.conf
sed -i 's/7291/7296/g' 7296/redis.conf

启动 6 个 Redis 节点
将启动的 6 个 redis 服务组成集群
redis-cli --cluster create 192.168.43.129:7291 192.168.43.129:7292 192.168.43.129:7293 192.168.43.129:7294 192.168.43.129:7295 192.168.43.129:7296 --cluster-replicas 1

故障恢复

1. 如果主节点下线？从节点能否自动升为主节点
redis-cli -p 7293 shutdown:关闭某个指定的redis服务
redis-cli -c -p 7291
cluster nodes: 此时会发现端口号为7293的redis对应的从服务器已经自动转为master主服务器了。
2. 主节点恢复后，主从关系会如何? 变为从节点
redis-server /usr/local/redis/redis-cluster/7293/redis.conf
redis-cli -c -p 7293
cluster nodes
3. 如果所有某一段插槽的主从节点都当掉，redis服务是否还能继续?不能继续了。

1. 一般情况下，一个集群最少有3个master节点
2. Redis集群的slot插槽有16384个
3. 在redis-cli进行查询、录入数据时，要使用集群的方式登录(-c),否则查询的数据如果不在对应服
务器的插槽时,会有redis报错问题。
4. 不在一个slot 下的键值，是不能使用mget、mset等多键操作的
5. 可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去，一个slot槽中
的数据一定是在一个组中的。

Redis集群的不足

多键操作时不被支持的
多键的Redis事务是不被支持的.Lua脚本不被支持.
由于集群方案出现比较晚,很多公司已经采用了其他的集群方案,而代理或者哭护短分片的方案想要迁移至redis  cluster ,  需要整体迁移而不是逐步过渡, 复杂度较大.

Redis的内存淘汰机制

过期时间：	
	定期删除：默认每100ms 随机抽取设置了过期时间的key，如果过期就删除。（避免每次全部扫描，降低性能）
	惰性删除：随机删除key未能抽取判断，当系统进行扫描时，进行删除。
6中淘汰策略：
	volatile-lru：从已设置过期时间的数据中挑选最近最少使用的数据淘汰
	volatile-ttl：从已设置过期时间的数据中挑选将要过期的数据淘汰
	volatile-random：从已设置过期时间的数据中任意选择数据淘汰
	allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）.
	allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
	no-enviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。

一、常见面试题？

1.redis 五种数据类型 的使用场景？如何实现的？

String（值类型）：限制登录次数（incr，设置过期时间）
List：队列（pop方法）
Set：去重、交集、并集、差集
sort Set：排行榜（zrevrange）内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率
Hash：存储对象信息（第一个key为userId）

2.redis利用aof重写问题？ 如何同时使用aof和dump 持久化？

aof超过阈值时，会开启自动压缩，只保留可以恢复数据的最小指令集。
当aof文件越来越的时候，会fork出一个新的线程，遍历线程内所有的信息，写入到新的aof文件。

3.redis实现分布式锁？

1、利用redis中的setnx。插入成功，表示当前没有线程操作，可以进行加锁。如果插入失败，表示已经有线程在进行操作，进行等待，再次调用当前方法。
2、利用redisson的getlock，trylock。如果获取锁成功，表示当前没有线程操作可以进行加锁。如果失败，表示已经有线程在进行操作，进行等待，再次调用当前方法。

4.redis死锁如何解决？

1、设置过期时间。并且时间要大于处理业务的时间。
2、将当前时间戳存入redis中，在删除锁之前做一个判断，验证当前的锁是不是自己的锁。

5.redis为什么是单线程？

redis是基于内存操作的，不存在cpu的瓶颈，所以使用单线程。
但是6.0后也是修改成了多线程。默认是不开启多线程的。同时官方建议4最起码4核才开启多线程

5.redis的持久化策略？

AOF

保存的是所有的写操作。
优点：数据完整的备份
缺点：占用大量的内存
保存机制：当aof文件的大小达到一定的阈值， 会开启压缩功能，压缩成最小可恢复数据的指令集。同时fork一个新的线程，读取当前线程的所有数据，写入新的aof文件中。

rdb

类似于快照功能。
优点：占用内存小，读取速度快
缺点：如果redis宕机，会丢失最近的一批数据。
适合存储不敏感的数据。

持久化操作

RDB持久化 :
		在redis.conf 中配置文件名称,默认为dump.rdb
		存放位置 :  默认放在redis启动时命令行所在的目录下
		手动触发 : 分别对应3个命令save  ,  bgsave   和shutdown
			① save :  阻塞当前redis服务器,直到rdb过程完成为止.  ( 线上环境不建议使用  )
			② bgsave : redis 进程执行fork 操作创建子进程 , rdb 持久化过程由子进程负责.    基本上redis内部所有的rdb操作都是采用bgsave命令.redis会在后台异步进行快照操作,快照同时还可以响应客户端请求.
			③ shudown : 会将内存中的数据持久化到磁盘上, 也会生成rdb文件
		自动触发：
			save m n: 表示m秒内数据集存在n次修改时,自动触发bgsave
		其他配置：
			stop-writes-on-bgsave-error    当 Redis 无法写入磁盘的话，直接关掉 Redis 的写操作。推荐 yes.
			rdbcompression     对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用 LZF 算法进行压缩。如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能。推荐 yes
			rdbchecksum    默认值是 yes。在存储快照后，我们还可以让 redis 使用 CRC64 算法来进行数据校验，但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
		恢复操作：
		 	关闭Redis
			把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
 		 	启动Redis, 备份数据会直接加载
 AOF持久化：
 		默认情况下, 是不开启的, 是需要进行手动开启.
 		appendonly  yes   配置开启aof
 		appendfilename  "appendonly.aof"		文件名为: appendonly.aof
 		触发机制，何时重写：Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis 要满足一定条件才会进行重写。
 		恢复操作：
 			正常恢复
 				 修改默认的 appendonly no，改为 yes
				 将有数据的 aof 文件复制一份保存到对应目录(查看目录：config get dir)
				 恢复：重启 redis 然后重新加载
			异常恢复
 			 	 修改默认的 appendonly no，改为 yes
 			 	 如遇到 AOF 文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof 进行修复
 			 	 恢复：重启 redis，然后重新加载
优先级: RDB 文件和AOF 文件同时存在的情况下, AOF优先级要高一些
		选择的话, 两者加一起才更好, 这也是官方推荐的使用方式.
	    因为两个持久化机制特点和自己的需求,但是通常都是集合使用
		如果对数据不敏感,可以单选RDB
		不建议单独用AOF, 因为可能会出现Bug
		如果只是做纯内存缓存,可以都不用
        因为rdb文件只用做后备用途,建议只有slave持久化RDB文件.而且只要15分钟备份一次就够了