目录

• 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存储文件，会消耗一定的cpu
  • rdbchecksum 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

二、持久化

什么是持久化

• 因为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字典中查找记录了订阅这个频道的所有客户端链表，遍历这个链表，将消息发布给订阅者。

场景

• 实时消息系统
• 实时聊天系统（频道当做聊天室）
• 订阅关注系统
• 复杂的场景就会使用消息中间件来做