redis-03：持久化、发布订阅、事务

Redis是一个内存数据库，它的数据都保存在内存中，如果服务器宕机，那么数据则全部丢失。因此，Redis提供了完善的持久化机制，可以把内存中的数据持久化到磁盘上，方便我们进行备份数据和快速恢复数据。

 

Redis提供的数据持久化方式主要有2种：

  RDB：产生一个数据快照文件

  AOF：实时追加命令的日志文件

 

 

 

RDB持久化

RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。

RDB（Redis DataBase）是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb二进制文件。Redis重启会通过加载dump.rdb文件来恢复数据。

RDB保存的文件是dump.rdb文件 ,位置保存在Redis的启动目录。Redis每次同步数据到磁盘都会生成一个dump.rdb文件，新的dump.rdb会覆盖旧的dump.rdb文件。

 

RDB 有两种触发方式，分别是自动触发和手动触发。手动触发Redis进行RDB持久化的命令有两种：

1、save触发方式

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。具体流程如下：

2、bgsave触发方式

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

 

3.自动触发

自动触发是由配置文件来完成的。在 redis.conf 配置文件中的 SNAPSHOTTING 下，有如下配置

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。

比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave

#表示900 秒内如果至少有 1 个 key 的值变化，则保存save 900 1

 

基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

ps:执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的.

 

 

①、优势

（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。

（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

②、劣势

       RDB快照是一次全量备份，全量备份总是耗时的。

       RDB存储的是内存数据的二进制序列化形式，存储上非常紧凑。

       当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

 

Aof持久化

Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF 则是通过保存Redis服务器所执行的写命令来记录数据库状态。

redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

RDB 持久化方式就是将 hello myhash myset这三个键值对保存到 RDB文件中，

而 AOF 持久化则是将执行的 set,hmset,sadd 三个命令保存到 AOF 文件中。

 

如果想要开启 AOF 持久化方式，需要将 appendonly 修改为 yes。

在 redis.conf 配置文件的 APPEND ONLY MODE 下：

appendfilename ：aof文件名，默认是"appendonly.aof“

appendfsync：aof持久化策略的配置；

（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失

（3）不同no：从不同步

 

优点

         ①、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。

         ②、AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。

        ③、AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

 

缺点

　　①、对于具有相同数据的的 Redis，AOF 文件通常会比 RDB文件体积更大。

　　②、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。

　　③、RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在

 

AOF 和 RDB的选择

通常来说，应该同时使用两种持久化方案，以保证数据安全。

         如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化。

         如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可。

         如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启。

         如果只用AOF，优先使用everysec的配置选择，因为它在可靠性和性能之间取了一个平衡。

当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整。

 

RDB-AOF混合持久化

Redis4.0之后，又新增了RDB-AOF混合持久化方式。

具体配置为：aof-use-rdb-preamble  设置为yes表示开启，设置为no表示禁用。

当开启混合持久化时，主进程先fork出子进程将现有内存副本全量以RDB方式写入aof文件中，然后将缓冲区中的增量命令以AOF方式写入aof文件中，写入完成后通知主进程更新相关信息，并将新的含有 RDB和AOF两种格式的aof文件替换旧的aof文件。

简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。这种方式结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

 

Redis事务

事务本质：一组命令的集合

Redis事务操作过程

    开启事务（multi）

    命令入队

    执行事务（exec）

所以事务中的命令在加入时都没有被执行，直到提交时才会开始执行(Exec)一次性完成。

Redis的单条命令是保证原子性的，但是redis事务不能保证原子性

 

代码语法错误（编译时异常）所有的命令都不执行

代码逻辑错误 (运行时异常) 其他命令可以正常执行 所以不保证事务原子性

 

Redis发布订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。微信、 微博、关注系统！ Redis 客户端可以订阅任意数量的频道。

 订阅/发布消息图： 第一个：消息发送者， 第二个：频道 第三个：消息订阅者！

 

订阅频道

发布消息

PSUBSCRIBE pattern [pattern..] 订阅一个或多个符合给定模式的频道。

PUNSUBSCRIBE pattern [pattern..] 退订一个或多个符合给定模式的频道。

PUBSUB subcommand [argument[argument]] 查看订阅与发布系统状态。

PUBLISH channel message 向指定频道发布消息

SUBSCRIBE channel [channel..] 订阅给定的一个或多个频道。

UNSUBSCRIBE channel [channel..] 退订一个或多个频道

 

每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

客户端订阅，就被链接到对应频道的链表的尾部，退订则就是将客户端节点从链表中移除。

 

Redis乐观锁

锁一般是用于锁定一些公共的资源，防止由于高并发而出现“超库存”的情况（例如抢票、秒杀系统）

乐观锁：乐观锁认为无论什么时候都不会出现问题，所以不会上锁，只是在更新数据的时候，会去比对某个字段（版本号），查询在这期间是否有人操作过这个数据

悲观锁：悲观锁认为，无论什么时候都会出现问题，所以无论做什么操作都会上锁。上锁虽然保障了安全性，但是性能上会大打折扣

终端1

终端2

回到线程1，执行事务