redis持久化​

redis持久化​

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

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

RDB( Redis DataBase )​

什么是RDB​

在主从复制中，rdb就是备用了，从机上面。​

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时时将快照文件直接读到内存中。​

redis会单独创建（fork）一个子进程来进行持久化，会将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化的数据可能会丢失。我们默认的就是RDB，一般情况下不需要修改这个配置。​

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

1. save的规则满足的情况下，就会自动触发rdb规则​
2. 执行flushall命令，也会触发我们的rdb规则​
3. 退出redis，也会产生rdb文件​
4. 备份就自动生成一个dump.rdb​

如何恢复rdb文件​

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

127.0.0.1:6379> config get dir​

1) "dir"​

2) "/usr/local/bin"​

几乎就他自己默认的配置就够用了，但是我们还是需要去学习​

优点​

1. 适合大规模的数据恢复​
2. 对数据的完整性要求不高​

缺点​

1. 需要一定的时间间隔进程操作，如果redis意外宕机了，这个最后一次修改数据就没有了​
2. fork进程的时候，会占用一定的内存空间​

AOF（Append On File）​

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

是什么​

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

Aof保存的是appendonly.aof文件​

append​

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

重启，redis就可以生效了​

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

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

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

重写规则说明​

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

如果aof文件大于64m，太大了，fork一个新的进程来将我们的文件进行重写​

优点和缺点​

appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用​

appendfilename “appendonly.aof”持久化的文件的名字​

# appendfsync always # 每次修改都会sync（同步）。消耗性能​

appendfsync everysec # 每秒执行一次sync,可能会丢失这1s的数据​

# appendfsync no # 不执行sync，这个时候操作系统自己同步数据，速度最快​

优点：​

1. 每一次修改都会同步，文件的完整会更加好​
2. 每秒同步一次，可能会丢失一秒的数据​
3. 从不同步，效率是最高的​

缺点：​

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

扩展：​

1. RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储​
2. AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。​
3. 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化​
4. 同时开启2种持久化方式

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

5. 性能建议​
6. 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1 这条规则​
7. 如果开启了AOF，好处是在最恶劣情况下也只是丢失不超过2秒的数据，启动脚本比较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64m太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。​

redis发布订阅​

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接受消息​

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

订阅/发布消息图：​

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

下图展示了频道channel1，以及订阅这个频道的三个客户端—client2、client5和client1之间的关系​

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

命令​

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

测试​

订阅端：​

[root@server ~]# redis-cli -p 6379​

127.0.0.1:6379> subscribe ysj 订阅一个频道 ysj​

Reading messages... (press Ctrl-C to quit)​

1) "subscribe"​

2) "ysj"​

3) (integer) 1等待读取推送的消息​

1) "message"消息​

2) "ysj"哪个频道的消息​

3) "hello ysj"消息的具体内容​

1) "message"​

2) "ysj"​

3) "hello world"​

发送端：​

127.0.0.1:6379> publish ysj "hello ysj"发布者发布消息到频道​

(integer) 1​

127.0.0.1:6379> publish ysj "hello world" 发布者发布消息到频道​

(integer) 1​

127.0.0.1:6379>​

原理：​

Redis是使用C实现的，通过分析Redis源码里面的pubsub.c文件，了解发布和订阅机制的底层实现，加深对redis的理解。​

Redis通过PUBLISH、SUBSCRIBE和PSUBSCRIBE等命令实现发布和订阅功能。​

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

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

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

使用场景：​

1. 实时消息系统​
2. 实时聊天（频道当作聊天室，将信息回显给所有人即可）​
3. 订阅，关注系统都可以的​

稍微复杂的场景我们就会使用消息中间件MQ​