Redis 持久化RDB和AOF以及Redis的发布订阅

Redis 持久化

Redis 是内存数据库，断电即失，所以要持久化。

RDB(Redis DataBase)

触发的机制

1. 配置文件中save的规则满足的情况下，会自动触发 rdb 规则
2. 执行 flushall 命令，自动触发
3. 退出 Redis，自动触发

备份就会自动生成一个 dump.rdb

恢复 rdb 文件

只要将 rdb 文件放在 Redis 启动目录就可以，redis 启动的时候会自动检查dump.rdb

tong@MacBook-Pro ~ % redis-cli -p 6379
127.0.0.1:6379> config get dir
1) "dir"
2) "/opt/homebrew/var/db/redis"   #如果在这个目录下存在 dump.rdb文件，启动就会自动恢复数据
127.0.0.1:6379> 

优点

• 适合大规模的数据恢复
• 对数据的完整性和一致性要求不高才适用

缺点

• 需要一定的时间间进行一次备份，如果 redis 意外宕机了，最后一次快照之后的数据就丢失了
• fork 进程的时候，会占用一定的内容空间

AOF(Append Only File)

把所有的命令（仅写操作）全部记录下来，恢复的时候全部执行一遍

配置文件中开启(默认不开启,手动改为 yes)

# 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种方式在许多应用中已经足够用了
appendonly no 
# appendfilename AOF 文件名称
appendfilename "appendonly.aof" 
# appendfsync aof持久化策略的配置：
#     no：不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#     always：每次写入都执行fsync，以保证数据同步到磁盘。
#     everysec：每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec 
# 重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性
No-appendfsync-on-rewrite 
# 设置重写的基准值
Auto-aof-rewrite-min-size 
# 设置重写的基准值
Auto-aof-rewrite-percentage

ps：如果appendonly.aof文件有错误，可以使用redis-check-aof进行修复（修复允许容错）

redis-check-aof --fix appendonly.aof

优点

• 每一次修改都同步，文件的管理性会更好
• 每秒同步一次，但可能会丢失一秒的数据
• 从不同步，效率最高

缺点

• 相对于数据文件来说，aof 远大于 rdb，修复的速度也比 rdb 慢
• aof 运行效率也要比 rdb 慢，所以我们 redis 默认配置直接就是 rdb 持久化

重写规则

默认aof 文件超过 64M 的时候会默认追加一个新的文件继续保存

总结

• RDB 持久化方式能够在指定的时间间隔内对数据进行快照存储。
• AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以 Redis 协议追加保存每次写的操作到文件末尾，Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大。
• 只做缓存，如果只希望数据在服务器运行的时候存在，你也可以不使用任何持久化。
• 同时开启两种持久化方式：
  • 在这种情况下，当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。
  • RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件，那要不要只使用AOF呢？作者建议不要，因为 RDB 更适合用于备份数据库（AOF 在不断变化不好备份），快速重启，而且不会有 AOF 可能潜在的 Bug，留着作为一个万一的手段。
• 性能建议：
  • 因为 RDB 文件只用作后备用途，建议只在 Slave（从节点） 上持久化 RDB 文件，而且只要 15 分钟备份一次就够了，只保留 save 900 1 这条规则。
  • 如果开启 AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只 load 自己的AOF文件就可以了，代价一是带来了持续的 IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少 AOF rewrite 的频率，AOF重写的基础大小默认值 64M 太小了，可以设到 5G 以上，默认超过原大小 100% 大小重写可以改到适当的数值。
  • 如果不开启 AOF ，仅靠 Master-Slave Repllcation（主从复制） 实现高可用性也可以，能省掉一大笔IO，也减少了 rewrite 时带来的系统波动。代价是如果 Master/Slave 同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB 文件，载入较新的那个（微博就是这种架构）。

Redis 发布和订阅

Redis 发布订阅（pub / sub）是一种消息通信模式。

常见就是聊天室，微信公众号订阅。作者发布文章，用户订阅公众号，发布后全部接收到文章

窗口 1，订阅频道：

127.0.0.1:6379> subscribe redisChatReading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

窗口 2，订阅频道：

127.0.0.1:6379> subscribe redisChatReading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

窗口 3，频道发布消息：

127.0.0.1:6379> publish redisChat "Hello,Redis"(integer) 2
127.0.0.1:6379> publish redisChat "Hello,World"(integer) 2

窗口 1 和窗口 2 都会收到发布的消息：

1) "message"
2) "redisChat"
3) "Hello,Redis"
1) "message"
2) "redisChat"
3) "Hello,World"