Redis 入门基础（三）

书接上文：Redis 入门基础（二）

六、事务

1. Redis 事务的本质

本质是一组命令的集合。

一个事务中的所有命令都会被序列化，在执行的过程中会按照顺序执行。

命令在事务中是不会被直接执行的，只有当发起执行命令的时候才会执行。

Redis 事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

2. Redis 事务的阶段

• 开始事务 MULTI
• 命令入队 （COMMAND）
• 执行事务 EXEC

3. Redis 事务命令

• 执行事务

  ------------------------------------
  # MULTI
  开启事务
  
  # EXEC
  执行事务
  
  QUEUED:入队
  ------------------------------------
  127.0.0.1:6379 > MULTI
  OK
  127.0.0.1:6379(TX)> set k1 v1    //命令入队
  QUEUED
  127.0.0.1:6379(TX)> set k2 v2
  QUEUED
  127.0.0.1:6379(TX)> get k2
  QUEUED
  127.0.0.1:6379(TX)> set k3 v3
  QUEUED
  127.0.0.1:6379(TX)> EXEC
  1) OK
  2) OK
  3) "v2"
  4) OK
  

• 放弃事务

  ------------------------------------
  # DISCARD
  取消事务，放弃执行事务块内的所有命令
  ------------------------------------
  127.0.0.1:6379 > MULTI
  OK
  127.0.0.1:6379(TX)> set k4 v4
  QUEUED
  127.0.0.1:6379(TX)> set k5 v5
  QUEUED
  127.0.0.1:6379(TX)> DISCARD
  OK
  

七、Redis 持久化

1. RDB（Redis DataBase）

RDB 简介

RDB 即快照模式，它是 Redis 默认的数据持久化方式，它会将数据库的快照保存在 dump.rdb 这个二进制文件中。RDB的配置信息放在redis.conf中的SNAPSHOTTING部分

RDB 模式的优点

1. 因为Redis的数据时存在内存中的，当服务器宕机时，Redis中存储的数据就会丢失。这个时候就需要内存快照来恢复Redis中的数据。
2. RDB是一个非常紧凑的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
3. 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
4. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 触发机制

• 执行FLUSHALL命令会触发rdb规则
• 退出Redis时，也会产生RDB文件
• 满足save规则，也会保存快照

RDB持久化的实现

• 手动触发

  通过SAVE命令或者BGSAVE命令，将内存数据保存到磁盘文件中

  SAVE命令：

  • 前台执行数据保存操作，
  • 但会阻塞 Redis 服务器进程，直到 dump.rdb 文件创建完毕为止

  BGSAVE 命令：

  • 后台执行数据保存操作，可用性较高
  • Redis 服务器会 fork() 一个子进程来进行持久化操作，父进程则继续处理客户端请求，不会阻塞Redis服务器进程

  LASTSAVE 命令：查看 BGSAVE 命令是否执行成功

  127.0.0.1:6379 > save
  OK
  
  127.0.0.1:6379 > BGSAVE
  Background saving started
  
  127.0.0.1:6379 > LASTSAVE
  (integer) 1669258768
  

• 自动触发

  通过配置redis.conf文件中SNAPSHOTTING部分，实现在指定的时间内，数据发生了多少次变化时，自动执行BGSAVE 命令，自动将内存数据保存到磁盘文件中

  ################################ SNAPSHOTTING  ################################
  # Save the DB to disk.
  #
  # save <seconds> <changes> [<seconds> <changes> ...]
  #
  # 如果经过了给定的秒数，并且超过了给定的对数据库的写入操作数，
  # Redis将保存数据库
  #
  # 可以使用单个空字符串参数完全禁用快照
  # 例如：
  # save ""
  #
  # 除非另有规定，否则默认情况下Redis将按照一下规则保存数据库：
  #   * After 3600 seconds (an hour) if at least 1 change was performed
  #   * After 300 seconds (5 minutes) if at least 100 changes were performed
  #   * After 60 seconds if at least 10000 changes were performed
  #
  # save 3600 1 300 100 60 10000
  
  # 在900秒内执行一次操作就保存
  save 900 1
  # 在60秒内执行10000次操作就保存
  save 60 10000
  

用RDB文件恢复数据

将dump.rdb文件放在Redis的启动目录

Redis启动时会自动检查dump.rdb并恢复其中的数据

RDB 模式的缺点

1. 在一定间隔时间做一次备份，如果redis意外宕机，就会丢失最后一次快照后的所有修改(数据有丢失)
2. fork进程的时候，内存中的数据被克隆了一份，频繁执行内存过高(影响性能)
3. RDB文件使用特定二进制格式保存，老版本Redis服务无法兼容新版RDB格式

2. AOF（Append Only File）

AOF 简介

AOF 是以日志的形式来记录每个写操作，每当 Redis接受到修改数据的命令时，就会把命令追加到 AOF 文件里（不记录读操作），Redis在启动时会读取该文件重新构建数据。

AOF 默认不开启，需要手动配置

AOF 的配置信息放在redis.conf中的APPEND ONLY MODE部分

AOF 模式的优点

• 相比其RDB模式更为可靠，一般不会造成数据的丢失
• 写入 AOF 文件中的所有命令都是以 Redis 的命令请求协议格式保存的，可以直接打开 AOF 文件查看内容

AOF 文件（Redis7.0）

• 基本文件，表示文件创建时的完整的数据，可以是 rdb 或 aof 内容格式

  appendonly.aof.1.base.rdb

• 增量文件，记录前一个文件之后的新增命令

  appendonly.aof.1.incr.aof，appendonly.aof.2.incr.aof

• 清单文件，追踪文件的创建和使用顺序

  appendonly.aof.manifest

AOF 持久化的实现

• 写入机制

  Redis 在收到客户端修改命令后，先进行相应的校验，再将该命令存追加到aof文件中，也就是先存到磁盘中，然后服务器再执行命令。当服务器宕机，只需将.aof文件中的命令再执行一次即可恢复到宕机前的状态。

  Redis 为了提升写入效率，它不会将内容直接写入到磁盘中，而是将其放到一个内存缓存区（buffer）中，等到缓存区被填满时才真正将缓存区中的内容写入到磁盘里。

• 重写机制

  由于AOF记录写过程，文件会越来越大。重写机制可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的信息一样，但体积更小。

  AOF可以使用 bgrewirteaof命令执行重写操作（由于AOF记录写过程，文件会越来越大）

• 文件修复

  重启 Redis 之后就会进行 AOF 文件的载入，如果AOF文件异常会影响Redis的运行。可以使用Redis提供的redis-check-aof 工具修复

  # redis-check-aof --fix
  

• 策略配置

  配置信息放在redis.conf中的APPEND ONLY MODE部分

  ############################## APPEND ONLY MODE ###############################
  # 默认不开启，为no
  # 启用AOF模式需要改为yes
  appendonly yes
  
  # AOF 文件名
  appendfilename "appendonly.aof"
  
  # 持久化策略
  # no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
  # always 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
  # everysec 表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。
  appendfsync everysec
  
  # 在aof重写或者写入rdb文件的时候，会执行大量IO，
  # 此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，
  # 如果对延迟要求很高的应用可以设置为yes，否则设置为no，这样对持久化特性来说这是更安全的选择。 
  # 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。
  no-appendfsync-on-rewrite no
  
  # Redis AOF重写策略
  # 触发重写所需要的 aof 文件体积百分比，
  # 只有当 aof 文件的增量大于 100% 时才进行重写，也就是大一倍。
  # 比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。
  # 如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能
  auto-aof-rewrite-percentage 100
  
  # 表示触发AOF重写的最小文件体积,大于或等于64MB自动触发
  auto-aof-rewrite-min-size 64mb
  

3. RDB和AOF对比

	RDB	AOF
持久化方式	定时对内存做快照	记录每一次执行的命令
数据完整性	备份有时间间隔，会导致数据不完整	相对完整，依据策略而定
文件大小	文件体积相对小	文件体积相对大
恢复速度	较快（直接恢复数据）	较慢（命令转化为数据）
资源占用	高，占用大量CPU和内存资源	低，占用磁盘IO；重写时占用CPU和内存资源
使用场景	可以忍受数据丢失，最求更快的速度	对数据安全要求高

RDB文件一般只放在从机上面，做后备用途

八、Redis 发布订阅

参考教程：Redis发布订阅

1. Redis发布订阅是什么

Redis 发布订阅 (pub/sub) 是一种消息通信模式：

发送者 (pub) 发送消息，订阅者 (sub) 接收消息

2. 发布订阅实例

• SUBSCRIBE订阅给定的一个或多个频道的信息。

  # 订阅消息客户端
  127.0.0.1:6379 > SUBSCRIBE redis-channel
  Reading messages... (press Ctrl-C to quit)
  1) "subscribe"
  2) "redis-channel"
  3) (integer) 1
  1) "message"
  2) "redis-channel"
  

• PUBLISH 将信息发送到指定的频道

  # 发送消息客户端
  127.0.0.1:6379 > PUBLISH redis-channel hello
  (integer) 1
  

  # 订阅消息客户端
  127.0.0.1:6379 > SUBSCRIBE redis-channel
  Reading messages... (press Ctrl-C to quit)
  1) "subscribe"
  2) "redis-channel"
  3) (integer) 1
  1) "message"
  2) "redis-channel"
  3) "hello"              // 接收到了来自发送消息客户端的信息
  

• UNSUBSCRIBE退定指定的频道

  127.0.0.1:6379 > UNSUBSCRIBE redis-channel
  1) "unsubscribe"
  2) "redis-channel"
  3) (integer) 0
  

• PUNSUBSCRIBE退订所有给定模式的频道

  redis 127.0.0.1:6379 > PUNSUBSCRIBE mychannel 
  1) "punsubscribe"
  2) "a"
  3) (integer) 1
  

• PUBSUB查看订阅与发布系统状态

  redis 127.0.0.1:6379 > PUBSUB CHANNELS
  (empty list or set)
  

3. 使用场景

• 订阅、关注系统
• 实时聊天、实时消息系统