redis.conf配置文件:
bind 127.0.0.1
#注释掉或者配置成bind 0.0.0.0 说明任意ip都可连接。区别:
设置成bind 0.0.0.0后保护模式(protected-mode yes)将失效
protected-mode
#启用的条件:1.没有使用bind 2.没有设置访问密码
demonize yes
#以后台方式运行
dbfilename dump.db
#持久化文件
dir ./
#dbfilename文件/aof文件存放的目录
#RDB会fork一个子进程进行数据的持久化操作,主进程不进行任何的io操作
save
#rdb持久化快照 如 save 900 10,则表示900秒内有10次变更就会更新rdb,save “” 可禁用rdb持久化。也可用save(主进程做,阻塞)/bgsave(复制的进程做,不阻塞)命令手动触发
#AOF会将操作指令记录到appendonly.aof文件(会将操作指令记录到文件)
appendonly no
#aof持久化 默认不开启。开启后会在dir指定的目下生成appendonly.aof文件
appendfsync no
#aof触发条件 no:等待操作系统进行操作(快,持久化没保证);always:数据发生变更时进行记录(慢,安全);everysec:每秒同步一次(默认/快,但可能会丢失一秒内的数据)
auto-aof-rewrite-percentage 100
#文件appendonly.aof达到该增长率时进行重写(设置新值后删掉旧的操作指令)
auto-aof-rewrite-min-size 64mb
#文件appendonly.aof达到该大小时对其进行重写(设置新值后删掉旧的操作指令)
RDB 持久化和 AOF 持久化
在过去, Redis 用户通常会因为 RDB 持久化和 AOF 持久化之间不同的优缺点而陷入两难的选择当中:
- RDB 持久化能够快速地储存和回复数据, 但是在服务器停机时却会丢失大量数据;
- AOF 持久化能够有效地提高数据的安全性, 但是在储存和恢复数据方面却要耗费大量的时间。
为了让用户能够同时拥有上述两种持久化的优点, Redis 4.0 推出了一个能够“鱼和熊掌兼得”的持久化方案 —— RDB-AOF 混合持久化: 这种持久化能够通过 AOF 重写操作创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件, 其中 RDB 数据位于 AOF 文件的开头, 它们储存了服务器开始执行重写操作时的数据库状态: 至于那些在重写操作执行之后执行的 Redis 命令, 则会继续以 AOF 格式追加到 AOF 文件的末尾, 也即是 RDB 数据之后。