Redis持久化以及Redis实现订阅发布

Redis持久化

面试和工作，持久化都是重点！

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能！

RDB（Redis DataBase）

什么是RDB：

在主从复制中，rdb就是备用了，从机上面几乎不使用！

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。Redis会单独创建( fork ) - -个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后- -次持久化后的数据可能丢失。我们默认的就是RDB , -般情况下不需要修改这个配置！

有时候在生产环境中我们会将这个文件进行备份！

rdb保存的文件是dump.rdb，都是在我们的配置文件中快照中进行配置的！

触发机制：

• save的规则满足的情况下，会自动触发rdb规则
• 执行flushall命令，也会触发我们的rdb规则
• 退出redis，也会产生rdb文件

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

如何恢复rdb文件：

• 只需要将rdb文件放在我们redis启动目录中就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据！
• 查看需要存在的位置

127.0.0.1:6379> config get dir
(1)"dir"
(2)"/usr/local/bin"		# 如果在这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据。

rdb文件的优点：

• 适合大规模的数据恢复！
• 如果你对数据完整性要求不高！

rdb文件的缺点：

• 需要一定的时间间隔进程操作！如果redis意外宕机了，这个最后一个修改数据就没有了。
• fork进程的时候，会占用一定的内容空间！

AOF（Append Only File）

将我们的所有命令记录下来，history，恢复的时候就把这个文件全部在执行一遍！

以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据,换言之, redis重启的话就根据日志文件的内容将写指令从前到后执行一-次以完成数据的恢复工作。

Aof保存的是appendonly.aof文件

append：

默认是不开启的，我们需要手动配置！我们只需要将appendOnly改为yes就开启了aof！

重启redis就可以生效了！

如果这个aof配制文件有错误，这时候redis是启动不起来的，我们需要修复这个aof文件

redis 给我们提供了一个工具redis-check-aof --fix

如果文件正常，重启就可以直接恢复了！

重写规则说明：

aof默认就是文件的无限追加，文件会越来越大！

如果一个文件大于64M，太大了，fork一个新的进程来将我们的文件重写！

AOF的优点：

appendonly	no	# 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof"		# 持久化的文件的名字

# appendfsync always	# 每次修改都会sync,消耗性能
appendfsync everysec	# 每秒执行一次sync,可能会丢失这1s的数据！
# appendfsync no 		# 不执行sync,这个时候操作系统自己同步数据，速度最快！

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

AOF的缺点：

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

AOF和RDB的扩展：

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以Redis协议追加保存每次写的操作到文件末尾, Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

3、只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化

4、同时开启两种持久化方式

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?作者建议不要,因为RDB更适合用于备份数据库( AOF在不断变化不好备份) , 快速重启,而且不会有AOF可能潜在的Bug ,留着作为-个万- -的手段。

5、性能建议

• 因为RDB文件只用作后备用途,建议只在Slave,上持久化RDB文件,而且只要15分钟备份-次就够了,只保留save 9001这条规则。
• 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的I0 ，二是AOF rewrite 的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到适当的数值。
• 如果不Enable AOF ，仅靠Master-Slave Repllcation实现高可用性也可以，能省掉一大笔I0 ，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时宕机，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构。

Redis实现订阅发布

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。微信，微博，关注系统！

Redis客户端可以订阅任意数量的频道。

订阅/发布消息图：

第一个：消息发送者，第二个：频道，第三个：消息订阅者。

下图展示了频道channel1，以及订阅这个频道的三个客户端–client1,client5和client1之间的关系：

当有新消息通过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端：

命令：

这些命令被广泛应用于构建即时通信应用，比如网络聊天室（chatroom）和实时广播，实时提醒等。

测试：

订阅端：

127.0.0.1:6379>	SUBSCRIBE yangjian				# 订阅一个频道
Reading messages...(press Ctrl-c to quit)
(1)"subscribe"
(2)"yangjian"
(3)(integer) 1
# 等待读取推送的信息
(1)"message"		# 消息
(2)"yangjian"		# 哪个频道的消息
(3)"hello,yangjian" # 消息的具体内容

(1)"message"
(2)"yangjian"
(3)"hello,redis"

发送端：

127.0.0.1:6379> PUBLISH yangjian "hello,yangjian"		# 发布者发布信息到频道
(integer) 1
127.0.0.1:6379> PUBLISH yangjian "hello,redis"			# 发布者发布消息到频道！
(integer) 1
127.0.0.1:6379>

原理：

Redis是使用C实现的,通过分析Redis源码里的pubsub.c文件.了解发布和订阅机制的底层实现,籍此加深对Redis的理解。Redis通过PUBLISH、SUBSCRIBE 和PSUBSCRIBE等命令实现发布和订阅功能。

通过SUBSCRIBE命令订阅某频道后, redis-server里维护了一个字典,字典的键就是一个个channel , 而字典的值则是-一个链表,链表中保存了所有订阅这个channel的客户端。SUBSCRIBE 命令的关键,就是将客户端添加到给定channel的订阅链表中。

通过PUBLISH命令向订阅者发送消息, redis-server会使用给定的频道作为键.在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表,遍历这个链表将消息发布给所有订阅者。

Pub/Sub从字面上理解就是发布( Publish )与订阅( Subscribe ) , 在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

使用场景：

1、实时消息系统！

2、实时聊天（频道当作聊天室，将信息返回给所有人即可！）

3、订阅，关注系统都是可以的！

稍微负载一点的场景我们就会使用中间件MQ（）