【1】持久化
如果不做持久化，用replication去保证可用性，另外最后可以通过引用从数据库同步最新数据。
因此注释掉所有的持久化策略，添加一条带空字符串参数的save指令，也能移除之前所有配置的save指令。
【1.1】RDB持久化
RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程。有手动触发和自动触发
（1）手动触发（save和bgsave）
save：阻塞当前redis，知道RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞。线上不建议使用。
bgsave：redis进程执行fork操作创建子线程，由子线程完成持久化，阻塞时间很短（微妙级）。
是save的优化，在执行redis-cli shutdown 关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;
（2）RDB文件
#参数 config set dir /usr/local #设置rdb文件保存路径
#备份
bgsave #将 dump.rdb 文件保存到 dir 参数目录下
#恢复
将 dump.rdb 放到 redis安装目录与 redis.conf同级目录，重启redis即可
#优点：
1.压缩后的二进制文件适用于备份、全量恢复，用于灾难恢复
2.加载RDB恢复数据远快于AOF方式
#缺点
1.无法做到实时持久化，每次都有创建子进程，频繁操作成本过高
2.保存后的二进制文件，存在老版本不兼容新版本rdb文件的问题
（3）RDB相关配置参数
#RDB文件参数 save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes #后台存储错误停止写 rdbcompression yes #在进行镜像备份时，是否压缩。压缩需要更多CPU，不压缩需要更多磁盘空间 rdbchecksum yes #一个CRC64的校验被放在了文件末尾，当存储或者加载rdb文件时会有10%性能问题，为了性能可以关闭这个配置 dbfilename dump.rdb #快照的文件名 dir /var/local #快照的存放目录
（4）关闭rdb
《1》把持久化策略关闭即可
#save 900 1
#save 300 10
#save 60 10000
总结：
（1）当开启RDB持久化时，在满足save条件、手动save、正常关闭的时候都会被持久化。异常关闭终止的时候数据会丢失。
（2） 当关闭持久化时，只有在手动save/bgsave的时候数据会被持久化，正常关闭与异常关闭数据均丢失。
【1.2】AOF持久化
（1）基本原理流程
参数：redis.conf 配置
appendonly yes #开启AOF
appendfilename "appendonly.aof" #文件名，appendonly.aof是默认文件名
AOF持久化流程：
命令写入（append），文件同步（sync），文件重写（rewrite），重新加载（load）
详细流程说明：
《1》所有的写入命令（set hset 等）会append追到到aof_buf 缓存区中
《2》AOF缓存区向硬盘做sync 同步
《3》随着 AOF文件越来越大，需要定期rewrite重写，进行压缩
《4》当redis服务重启，可load加载aof文件进行恢复
（2）AOF配置参数详解：
appendonly yes #启用aof持久化
#appendfsync always #每收到命令就立即强制写入磁盘，效率最慢，但是保证完全的持久化，不推荐使用
appendfsync everysec #默认为该值，每秒强制写入磁盘一次，性能和持久化的折中选择，推荐使用
#appendfsync no #完全依赖os，性能最好，持久化每保证（操作系统自身按情况同步）
no-appendfsync-on-rewrite yes #正在导出rdb快照的过程中，是否停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大写比起上次重写时的大小，增长率100%时，重写
auto-aof-rewrite-min-size 64mb #aof文件，至少超过64M时，才会有重写操作
（3）如何从AOF恢复？
《1》设置appendonly yes;
《2》将 appendonly.aof 放到 dir 参数指定的目录；
《3》启动redis，redis会自动加载 appendonly.aof 文件
（4）redis重启恢复加载AOF与RDB顺序及流程
《1》当AOF和RDB文件同时存在时，优先加载AOF
《2》如果关闭了AOF，加载RDB文件
《3》加载AOF/RDB成功，redis启动成功
《4》AOF/RDB存在错误，redis启动失败并打印错误信息
总结：
redis重启载入数据的时候，读取aof的文件要优先于rdb文件，所以尽量一开始使用redis的时候就开启aof选项，不要在中途开启，容易导致数据出问题。
如果非要中途开启，那么先修改配置文件开启aof参数，然后再执行bgrewriteaof，再重启redis 服务，这样就会把之前的记录重写一份到 aof文件中，不会导致数据丢失了。
【1.3】备份恢复
备份很简单，只需要把RDB，AOF的文件复制备份起来就好了。
相同版本的备份文件可以任意使用，不同版本的可能会有问题（没有实践过）。
步骤：备份文件-》停止-》拷贝回来恢复
【2】慢查询
与mysql一样，当执行时间超过阀值，会将执行时间耗时的命令记录
redis命令什么周期，发送、排队、执行、返回
慢查询只统计第3个执行步骤的时间
预设阀值：两种方式，默认为10毫秒
【2.1】阀值设置
（1）动态设置
6379:>config set slowlog-log-slower-than 10000
#这里的10000 是微秒 = 10毫秒
使用config set 完成后，若想将配置永久保存到redis.conf，要执行config rewrite
（2）redis.conf修改
找到 slowlog-log-slower-than 10000，修改保存即可
注意，slowlog-log-slower-than # 0记录所有命令，-1命令都不记录
config set slowlog-max-len 128 #最大日志长度，最多128条命令
【2.2】基本命令
（1）获取队列里慢查询的命令
slowlog get
（2）获取慢查询列表当前的长度
showlog len
（3）对慢查询列表清理（重置）
slowlog reset
【3】安全设置
【3.1】基本解决办法与思路
（1）设置密码
（2）修改默认端口
（3）监听内网IP
（4）设定专用账户
（5）修改configure命令
【3.2】实际配置redis.conf
（1）设置密码
requirepass 123456
#如果设置了，登录时要用 redis-cli -a 123456
（2）修改默认端口
port 16000
（3）监听内网IP
bind 192.168.135.173 192.168.135.174 192.168.135.175 #可以多个IP。用空格隔开，最好不要用127.0.0.1
（4）设置专用账户
就是使用专用账户来安装使用redis，相关操作参考：Redis（1.1）linux下安装redis
（5）修改configure命令
#将config命令改名
rename-command CONFIG "FGCONFIG"
#禁用掉config命令
rename-command CONFIG ""
【4】redis集群迁移
【step 1】：开发中断程序，登录各个主节点查看key信息
INFO # Keyspace db0:keys=573153,expires=23977,avg_ttl=6721214720 # Keyspace db0:keys=574792,expires=24263,avg_ttl=6741152890 # Keyspace db0:keys=574647,expires=24500,avg_ttl=6733187087
【step 2】：在各个主节点进行AOF的写入
[root@YC-ss1 ~]# redis-cli -h ****** -p 7014 -a ******* 10.144.128.242:7014> BGREWRITEAOF Background append only file rewriting started
【step 3】：将各个主节点的AOF文件拷贝到新的redis集群的主节点，新的redis必须关系AOF而且关闭所有集群
scp appendonly.aof root@host_ip:/tmp/
用这个AOF文件覆盖新的redis集群主节点的AOF文件
【step 4】：依次提起新redis集群的主节点。启动完毕，启动从节点
redis-server /home/redis/redis7013/redis7013.conf
【step5】：重启新的redis集群，打开新的集群的AOF
重启修改其配置文件即可，停的时候先停从节点，启动的时候先启动主节点
【step 6】：迁移完毕
【5】基本优化
(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件；(Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照;AOF文件过大会影响Master重启的恢复速度)
(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...；
这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。