Redis 操作

lpush l1 a b c d
list 底层是一个字符串链表，left和right都可以插入。

以lpush为例
如上的操作将 a b c d 以此插入list集合，在进行
lrange l1 0 -1 操作的时候
d c b a
在进行lpop操作的时候 lpop l1的时候弹出
d

如何触发 RDB快照
1:配置文件中默认的快照配置
参考 redis.conf
2:命令 save 或者是bgsave
save，执行快照操作，阻塞其他操作
bgsave，后台异步执行快照操作，可以通过lastsave命令获取最后一次成功执行快照的时间。

3:执行 flushall 命令，也会产生 dump.rdb文件，但里面是空的，无意义

如何恢复
redis可以自动的根据配置文件的路径加载dump.rdb文件。『可以通过配置文件查看该路径和文件名』
config get dir 该命令可以显示dump.rdb文件的加载路径。

优势：
1：适合大规模的数据恢复
2：对数据完整性和一致性要求不是特别高的情况
劣势：
1：在一定时间间隔做一次备份，如果redis以为down掉，可能丢失最后一次快照的修改
2：Fork的时候，内存中的数据被克隆一份，大致2倍的膨胀性需要考虑性能。
如何停止
动态的停止rdb快照执行的方法：
redis-cli config set save “”
将save设置为空串，可以停止rdb快照操作

总结：
内存中的数据对象 《——–》磁盘中的rdb文件
通过rdbsave和rdbload操作完成如上操作
rdb是一个非常紧凑的文件。
在保存rdb文件时，父进程唯一需要做的就是fork出一个子进程父进程不需要在做其他的io操作，所以rdb持久化的方式可以最大化redis的性能。
与aof相比，在恢复大数据集的时候，reb方式更加快捷。
数据丢失风险比较大
rdb需要经常fork子进程来保存数据集到硬盘，当数据集比较大的时候，fork的过程非常耗时间，可能导致redis在一些毫秒级不能响应客户请求。

AOF（Append Only File）
定义：
以日志的形式来记录每个写操作 ，将 Redis执行过的所有写指令记录下来 ( 读操作不记录 )，只许追加文件但不可以改写文件， redis 启动之初会读取该文件重新构建数据，换言之， redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

aof 保存的是appendonly.aof 文件
aof默认是关闭状态的，可以在配置文件配置如下信息:
appendonly yes，appendfilename “appendonly.aof”
aof的启动 修复和恢复
正常情况下，redis启动的时候会根据配置文件的信息加载相关的aof文件。
修复：Redis-check-aof –fix +aof文件，重启redis，加载。
【注意：在aof文件错误的情况下，由于redis需要先加载aof，故而若aof文件发生错误，redis服务是无法正常启动的】、

Rewrite
由于aof采用文件追加的方式，文件会越来越大，为了避免出现如此的情况，新增了重写机制，当aof文件的大小超过设定的阀值，redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
重写原理：
AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写 ( 也是先写临时文件最后再 rename) ，遍历新进程的内存中数据，每条记录有一条的 Set 语句。重写aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。
触发机制：
Redis会记录上次重写时的AOF大小，默认配置是当 AOF 文件大小是上次 rewrite后大小的一倍且文件大于 64M 时触发。
优势：
每秒同步：appendfsync everysec
每次修改同步：appendfsync always
不同步：appendfsync no
劣势：
相同数据集的数据而言 aof 文件要远大于 rdb文件，恢复速度慢于 rdb
Aof 运行效率要慢于 rdb,每秒同步策略效率较好，不同步效率和 rdb 相同。
总结：
客户端 —（命令请求）—-》服务器 —（网络协议格式的命令内容）—-》aof文件

aof文件是一个只进行追加的日志文件。
redis可以在aof文件体积变得过大的时候，自动在后台进行重写。
aof文件有序的保存了对数据库执行的所有写操作，这些写入操作以redis协议的格式保存，aof文件的内容也很容易被人读懂，对文件分析也很轻松。
对于相同的数据集来说，aof文件比rdb文件要大很多。
根据所有的fsync策略，aof的速度慢于rdb

总结 rdb 和 aof
性能建议：
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构。