Redis学习笔记（三）redis配置文件 & 持久化

redis.conf详解

单位

配置文件units单位对大小写不敏感

可聚合多个配置文件为一个配置

网络

bind 127.0.0.1 #绑定ip
protected-mode yes #保护模式
port 6379 #端口设置

通用GENERAL

daemonize yes #以守护线程方式运行，默认为no，需手动开启
pidfile /var/run/redis_6379.pid #如若以后台方式运行，我们需要指定一个pid文件
loglevel notice #日志级别
logfile "" #日志的文件位置名
databases:16 #数据库默认数量16
always-show-logo yes #是否总是显示logo

快照

• 持久化：在规定时间内，执行多少次操作后会持久化到.rdb,.aof文件
  redis是一个基于内存的数据库，如果不持久化，这些数据断点就会丢失

save 900 1 #900秒内（15分钟），有超过1个key被修改则保存
save 300 10 #300秒内（5分钟），有超过300个key被修改则保存
save 60 10000 #60秒内（1分钟），有超过10000个key被修改则保存

stop-writes-on-bgsave-error yes #持久化过程出现错误，是否还需继续工作
rdbcompression yes #是否压缩rdb文件(持久化文件)，此操作会消耗一定cpu资源
rdbchecksum yes #保存rdb文件的时候，检查校验

dir ./ #rdb文件保存的目录

REPLICATION(主从复制)

replicaof <masterip> <masterport> # replicaof <主机地址> <主机ip>
masterauth <master-password> # 如果主机有密码，则写密码

SECURITY(安全)

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass #获取redis登录密码，默认为空
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "1234" #设置redis登录密码
OK
127.0.0.1:6379> ping
(error) NOAUTH Authentication required. #命令无权限
127.0.0.1:6379> config get requirepass
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 1234 #验证登录密码，成功后才可操作
OK
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "1234"
127.0.0.1:6379>

LIMITS限制

maxclients 10000 #客户端最大连接数10000
maxmemory <bytes> #最大内存容量

maxmemory-policy noeviction #内存到达上限后的处理策略

策略：

1. noeviction：直接返回错误，不淘汰任何已经存在的redis键
2. allkeys-lru：所有的键使用lru算法进行淘汰
3. volatile-lru：有过期时间的使用lru算法进行淘汰
4. allkeys-random：随机删除redis键
5. volatile-random：随机删除有过期时间的redis键
6. volatile-ttl：删除快过期的redis键
7. volatile-lfu：根据lfu算法从有过期时间的键删除
8. allkeys-lfu：根据lfu算法从所有键删除

aof配置：APPEND ONLY MODE

appendonly no #默认不开启aof模式，默认rdb
appendfilename "appendonly.aof" #持久化的文件名称
# appendfsync always #美修改一次便会sync
appendfsync everysec #每秒执行一次sync，但有可能丢失这1s的数据
# appendfsync no #不执行sqnc，操作系统自己同步，速度最快

Redis持久化

Redis是内存数据库，若是不将内存中的数据库状态保存在磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会丢失。所以Redis

RDB（Redis DataBase）

什么是RDB

RDB是一种快照存储持久化方式：在指定时间间隔内将内存中的数据集快照写入磁盘，恢复时将快照文件直接读入内存。

原理

Resis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中，等到持久化进程结束，再用这个临时文件替换上次持久化好的文件。
在这整个过程中，主进程无需进行任何IO操作。这确保了redis极高的性能，若需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加高效。
RDB的缺点是最后一次持久化后的数据可能丢失。
Redis默认配置是RDB，一般情况下不要修改此配置

触发机制

rdb保存文件名是dump.rdb,是在配置文件中的快照中进行配置

# The filename where to dump the DB
dbfilename dump.rdb

更改保存策略：

1. save的规则满足的情况下，触发rdb规则
2. 执行flushall命令，也会触发rdb规则
3. 退出redis，也会产生rdb文件

恢复RDB文件

1. 将rdb文件放在redis启动目录中，redis启动时便会自动检查恢复edb文件

127.0.0.1:6379> config get dir #查看存放位置
1) "dir"
2) "D:\\SofeworeSpace\\Sofewore\\Enviroment\\Redis-x64-3.2.100"  #如此目录存在dump.rdb文件，启动就会自动恢复其中的数据

RDB优缺点

优点：

• 大规模的数据恢复
• 若是对数据的完整性要求不高

缺点：

• 需要一定时间间隔进行操作（可自行在配置文件中修改），如果redis宕机，那么最后一次修改的数据便没有了

在生产环境，一般会将rdb文件备份，防止丢失

• fork进程的时候，会占用一定的内存空间

AOF（Append Only File）

什么是AOF

AOF是Redis持久化策略的选择之一

文件名：appendonly.aof

原理

以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来（读操作不记录），只需追加文件单不可改写文件。
redis启动之初会读取该文件重新构建数据，换而言之，redis重启的话就会根据日志文件的内容将写指令从开始到最后都执行一次以完成数据的恢复

配置

appendonly yes # 默认不开启
appendfilename "appendonly.aof" #aof文件名
# appendfsync always # 每次修改都会sync，消耗性能
appendfsync everysec # 每秒执行有刺sync
# appendfsync no  # 从不sync，操作系统自己同步数据，效率最快
aof-load-truncated yes #指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题(突然断电，写了一半)，这种情况下，yes会log并继续，而no会直接恢复失败.

重写
作用：使AOF文件提交不至于过大

由于重写AOF文件时，会对Redis的性能带来一定的影响，因此也不能随便的进行自动重写，Redis提供两个配置用于自动进行AOF重写的指标，只有这两个指标同时满足的时候才会发生重写：

no-appendfsync-on-rewrite no  #是否重写
auto-aof-rewrite-percentage 100  #指的是当文件的内存达到原先内存的两倍
auto-aof-rewrite-min-size 64mb  #指的是文件重写的最小内存大小

恢复AOF文件

注意：如果AOF文件遭到破环，比如在日志中增添额外的语句，会导致redis无法连接，需要先修复AOF文件

redis提供了修复aof文件的工具：redis-check-aof --fix appendonly.aof

修复完成若文件正常则可重启连接redis

AOF优缺点

优点：

• 每一次修改都同步，文件完整性更好
• 选择每秒同步一次，只丢一秒的数据
• 选择从不同步的话，效率最高

缺点：

• 相对于数据文件来说，aof远大于rdb，修复速度也比rdb慢
• aof运行速率较于rdb慢，所以默认使用rdb

扩展

1. RDB持久化方式能够在指定时间间隔内对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写的操作，当服务器重启时重新执行这些写的命令恢复原始数据。AOF命令以Redis协议追加保存每次写的操作至文件末尾，Redis还能对AOF文件进行后台重写，是AOF文件体积不至于过大。
3. 只做缓存，如果只希望数据在服务器运行的时候存在，那么可以不做任何持久化
4. 同时开启两种持久化方式：
   • Redis重启时优先载入AOF文件恢复原始数据，因为通常情况下AOF文件保存的数据集要比RDB文件保存的完整
   • RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件

   建议不要看到这就只使用AOF
   因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会出现AOF文件中可能潜在的Bug。

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