Redis 持久化和发布订阅

Redis 持久化

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

RDB(Redis DataBase)

触发的机制

配置文件中save的规则满足的情况下，会自动触发 rdb 规则
执行 flushall 命令，自动触发
退出 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"