redis配置详解
- 一、redis.conf
- 二、持久化
- 1、RDB
- ① 触发机制
- ② 优缺点
- ③ 恢复rdb
- 2、AOF
- ① 优缺点
- ② 恢复aof
- 三、发布订阅
一、redis.conf
# -----NETWORK-----
# 设置绑定ip
bind 127.0.0.1 -::1
# 设置redis保护，只能通过绑定在本地回环地址上的网络接口进行访问
protected-mode yes
# 设置开启端口
port 6379
# -----GENERAL-----
# 设置为守护进程运行，默认是no
daemonize yes
# 日志级别
loglevel notice
# 日志文件存放
logfile ""
# 数据库数量
databases 16
# -----SNAPSHOTTING-----
# 持久化 RDB
# 3600s内有1个key发生变更，就将数据异步保存到磁盘
save 3600 1
# 300s内有100个key发生变更，就将数据异步保存到磁盘
save 300 100
# 60s内有10000个key发生变更，就将数据异步保存到磁盘
save 60 10000
# 持久化出错是否继续工作
stop-writes-on-bgsave-error yes
# 是否压缩持久化rdb文件
rdbcompression yes
# 保存rdb文件时进行错误校验
rdbchecksum yes
# rdb文件保存名称与目录
dbfilename dump.rdb
dir ./
# -----REPLICATION-----
# 主从复制
# -----SECURITY-----
# 安全
# 设置密码，默认没有密码
requirepass 1213456
# -----CLIENTS-----
# 设置客户端限制
# 设置连接客户端数量
maxclients 10000
# -----MEMORY MANAGEMENT-----
# 设置最大内存
maxmemory <bytes>
# 设置内存到达上限后的处理策略
maxmemory-policy noeviction
# -----APPEND ONLY MODE-----
# 持久化 AOF
# 开启，默认关闭，使用rdb
appendonly no
# aof文件保存名称与目录
appendfilename "appendonly.aof"
appenddirname "appendonlydir"
# 同步记录
# appendfsync always # 每次修改都会同步
appendfsync everysec # 每一秒执行一次同步，但是可能会丢失这一秒的数据
# appendfsync no # 不同步
二、持久化
redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，服务器因某些情况导致进程退出，则服务器中的数据库状态也会消失
1、RDB
在指定时间间隔内，将内存中的数据集快照(SNAPSHOTTING)写入磁盘保存在dump.rdb文件。redis会单独创建一个子进程来进行持久化，主进程不会进行任何IO操作
同时开启两种模式，redis重启时会优先载入AOF文件来恢复原始数据，因为通常情况下aof文件会比rdb文件保存的数据集完整
① 触发机制
1、save规则满足
2、执行flushall
3、退出redis
② 优缺点
优点：适合大规模数据恢复；对数据完整性要求不够高
缺点：需要一定的时间间隔进程操作，如果redis意外宕机，最后一次修改数据丢失；使用子线程恢复数据，会占用内存
③ 恢复rdb
只需要将rdb文件放在启动目录即可，redis启动时会自动检查dump.rdb数据并进行恢复操作
127.0.0.1:6379> config get dir
1) "dir"
2) "/root/redis-7.2.3"
2、AOF
类似于history，以日志的形式记录所有写操作命令保存在appendonly.aof文件，恢复时将命令重新执行一遍恢复数据；
① 优缺点
优点：
appendfsync always # 每次修改都会同步
appendfsync everysec # 每一秒执行一次同步，但是可能会丢失这一秒的数据
appendfsync no # 不同步
缺点：
存储appendonly.aof文件会比较大，恢复也会慢
② 恢复aof
跟rdb一样，将appendonly.aof文件放入启动目录，启动redis时即可恢复；如果文件被修改错位或其他问题，会导致redis启动失败，此时可以使用redis-check-aof修复，命令redis-check-aof --fix appendonly.aof
三、发布订阅
redis发布订阅是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接受消息；使用场景：1、实时聊天群2、实时消息系统3、订阅、关注系统，稍微复杂的一般使用mq
类似于微博博主（消息发布者），发布动态信息（频道），关注该up的账号（消息订阅者）可以收到动态信息通知
# 订阅
SUBSCRIBE channel [channel2 channel3 ...]
# 发送
PUBLISH channel message
客户端A订阅：
客户端B推送消息：
客户端A自动接受消息：
