标签：AOF 持久 配置文件 文件 redis Redis aof rdb
目录
- Redis配置文件
- Redis持久化
- RDB
- AOF
一、Redis配置文件
基本配置项
-
单位：大小写不敏感
-
包含：支持对个配置文件
-
网络
bind：可以绑定本地、远程的地址,表示支持连接的ip地址 -
保护模式
protected -
端口设置
port -
通用配置
- 后台进程
dameonize no是否开启、配置文件的pid文件pidfile（后台运行的进程文件） - 日志级别
loglevel（debug、verbose、notice默认、warning）以及输出日志的文件名logfile - 数据库数量
databases 16 - logo是否显示
always-show-logo yes
- 后台进程
-
快照：用于持久化到rdb 、aof文件
save 900 1： 至少有一个 key 修改，进行持久化操作stop-writes-on-bgsave-error yes：持久化出错是否继续工作rdbcompression yes：是否需要压缩rdb存储文件，会消耗一定的cpurdbchecksum yes： 报错rdb文件的时候，是否进行错误的检查校验dir ./: rdb的保存目录
-
主从复制
replication -
安全
security- 设置密码
requirepass xxx,也可以使用cli设置config set requirepass xxx,之后使用auth xxx登录
- 设置密码
-
客户端
client- 可以设置客户端最大连接数量限制
maxclients 10000 - 可以设置最大内存容量
maxmemory <bytes> - 可以设置内存上线的处理策略
maxmemory-policy noeviction
- 可以设置客户端最大连接数量限制
-
AOF配置
- 默认不开启AOF的
appendonly no，默认使用rdb持久化就够了 - 持久化文件
appendfilename "appendonly.aof" - 执行同步修改规则
appendfsync
- 默认不开启AOF的
二、持久化
什么是持久化
- 因为Redis是内存型数据库，断点易失信息，因此需要 在指定的时间间隔将内存中的数据集快照写入 磁盘，恢复的时候可以将快照文件读入到内存。
- 常见的两种持久化的方式是RDB、AOF，两种方式各有优点。
- 默认的方式是rdb方式，一般主从复制的时候，使用rdb备用
两种方式
- RDB持久化方式是在指定的时间间隔内对数据进行快照存储。
- AOF持久化方式是记录每次数据库操作的指令，当服务器重启的时候重新执行这些命令恢复原始数据，AOF的命令以Redis协议追加保存到每次写操作文件末尾，Redis还能对aof文件进行打开编辑。也支持AOF文件重写，防止AOF文件不那么大。
拓展
- 只做缓存的情况下，可以不用做持久化。
- 同时开启两种持久化方式
- 当redis重启时会优先载入aof文件来恢复原始数据，因为在通常情况下aof文件保存的数据要比rdb文件保存的数据更完整。
- rdb更适合备份数据库（aof在不断变化不好备份），快速重启没有aof可能会存在bug问题。
- 建议开启两种方式，但是会有一定的cpu消耗
性能建议
- 如果rdb文件只做后备用途，建议设置save xxx xxx 持久化文件，而且只要15分钟一次即可 只保留
save 900 1这条规则。 - 性能允许的情况下开启aof,aof带来IO，而且rewrite的过程产生新数据写到新文件造成的阻塞不可避免，只要磁盘允许应该减少rewrite的频率，建议设置5G以上
- 不使用aof使用主从复制配合rdb也可以高可用，避免IO、减少rewrite时候系统的波动，代价是Master、Slave同时倒掉，会丢失十几分钟的数据。
1.RDB(Redis DataBase)
原理
- Redis会单独创建（fork）一个子进程来持久化，先将数据放入一个临时文件，等待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
- 整个过程中，主进程不进行任何IO操作的。这就确保了极高的性能。
- 如果需要大规模数据恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效。
- RDB缺点是最后一次持久化的数据可能丢失。默认方式就是RDB，默认保存到
dump.rdb文件,可以在conf配置文件中配置。
举栗
- 配置规则 配置（当save规则满足的情况下，会自动触发rdb文件，当重启redis进程之后，数据会从dump.rdb自动恢复）
注意
- 默认flushdb、flushall之后会自动生成一个dump.rdb文件
- 退出redis，也会产生rdb文件
- 恢复rdb文件只需要将文件放到redis启动目录下即可
- 默认的配置够基本使用。
优点
- 适合大规模数据恢复
- 对数据完成性要求不高（默认在规则之外时间段出故障）
缺点
- 需要一定时间间隔操作，如果redis操作时候意外故障，当前的修改的数据就未成功备份
- 子进程fork的时候，会占用一定的内存空间。
2.AOF(Append Only File)
原理
- 将所有的命令记录下来，恢复的时候再把这个文件执行（类似数据库脚本）
- 以日志的形式记录每个操作（读操作不记录）
- 可以追加文件但不能改写文件，redis启动之初会读取该文件重新构建数据。
- redis重启就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
举栗 配置
- 默认
appendonly no，是不开启的,需要改为yes - 默认生成文件
appendfilename "appendonly.aof" - 持久化策略
appendfsync xxx(可选always、everysec（一般）、no)等 - 默认文件是否重写
no-appendfsync-on-rewrite no，默认aof是无限追加，当前aof文件过大时超过设置大小，可以开启新的文件 - 完成redis重启之后会生成
appendonly.aof文件
关于aof文件的修复工具redis-check-aof
- aof文件可以使用vim打开查看、编辑。错误的情况下redis会打开失败。
- 可以运行redis-check-aof修复被破坏的aof文件
redis-check-aof --fix xxx
优点
- 每次修改都同步（可设置每秒同步一次或者一直同步，从不同步效率是最高的），文件的完整性更好
缺点
- 相对数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
- aof运行的效率要比rdb慢(需要读写文件)
三、发布订阅
什么是发布订阅
- 一种消息通信模式，发送者pub发送消息，订阅者sub接收消息
- 常见的场景 微信公众号、微博的关注消息推送系统
- 发布者 推送的信息常常放到一个队列中（频道），推送给关注 订阅者
1.Redis中的命令
举栗
# 模拟订阅者
127.0.0.1:6379> psubscribe xiaosi # 订阅一个 xiaosi 频道
Reading messages... (press Ctrl-C to quit) # 只要不结束一直监听
1) "psubscribe"
2) "xiaosi"
3) (integer) 1
1) "pmessage" # 接收到发布者发布的信息
2) "xiaosi" # 频道
3) "xiaosi"
4) "hello" # 内容
# 模拟发布者
127.0.0.1:6379> publish xiaosi "hello" # 在xiaosi频道发送消息
(integer) 1
127.0.0.1:6379>
2.原理
原理
- Redis是c实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制底层的原理
- 通过publish 、subscribe、psubscribe等命令实现订阅发布功能
- 通过subscribe订阅某个频道后，redis-server里面维护一个字典，键就是频道channel,字典的值是一个链表，链表中保存了所有订阅这个channel的客户端，subscribe命令的关键就是将客户端添至链表
- 通过publish可以向订阅者发布信息，redis-server会使用给定的频道做主键，在他维护的channel字典中查找记录了订阅这个频道的所有客户端链表，遍历这个链表，将消息发布给订阅者。
场景
- 实时消息系统
- 实时聊天系统（频道当做聊天室）
- 订阅关注系统
- 复杂的场景就会使用消息中间件来做
标签：AOF,持久,配置文件,文件,redis,Redis,aof,rdb 来源： https://blog.csdn.net/qq_24654501/article/details/118423181
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。