### 一、Redis持久化 **持久化：**利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。 **持久化的原因：**防止数据的意外丢失，确保数据的安全性。 **持久化过程：**将当前数据状态进行保存。 - ①快照形式(RDB)，存数据结果，存储格式简单，关注点在数据； - ②日志形式(AOF)，存储操作过程，存储格式复杂，关注点在数据的操作过程。 在运行情况下， Redis 以数据结构的形式将数据维持在内存中， 为了让这些数据在 Redis 重启之后仍然可用， Redis 分别提供了 RDB 和 AOF 两种[持久化](http://en.wikipedia.org/wiki/Persistence_(computer_science))模式。 #### 1、RDB RDB 功能最核心的是 `rdbSave` 和 `rdbLoad` 两个函数， 前者用于生成 RDB 文件到磁盘， 而后者则用于将 RDB 文件中的数据重新载入到内存中。 ##### 1.1、RDB启动方式——save命令 - 命令： ```shell save ``` - 作用：手动执行save命令，可以将数据保存在指定文件夹（该文件夹目录在redis的配置文件中通过dir参数指定）下的dump.rdb（默认文件名为dump）文件中。 - save命令相关配置（均在redis的配置文件中设置） - **dbfilename dump.rdb** 说明：设置本地数据库文件名，默认值为dump.rdb 经验：通常设置为dump-端口号.rdb - **dir** 说明：设置存储.rdb文件的路径 经验：通常设置成存储空间较大的目录中，目录名称为data - **rdbcompression yes** 说明：设置存储值本地数据库时是否压缩数据，默认为yes，采用LZF压缩 经验：通常默认为开启状态，如果设置为no，可以节省CUP运行时间，但是会式存储的文件变大（巨大） - **rdbchecksum yes** 说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程中均进行 经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存在一定的数据损坏风险。 - save指令工作原理 save指令的执行过程是同步的，该令会阻塞当前 Redis 服务器，执行 save 指令期间，Redis 不能处理其他命令，直到 RDB 过程完成为止。因此当有多个save任务发生并且每一save都需要较长时间时，有可能会造成Redis服务器长时间阻塞。**线上环境不建议使用save。** ##### 1.2、RDB启动方式——bgsave命令 - 命令： ```shell bgsave ``` - 作用： bgsave作用同save一样，都是用于保存数据的。 - bgsave命令相关配置 bgsave除了有与save相同的配置外还有一个： - **stop-writes-on-bgsave-erroryes** 说明：后台存储过程中如果出现错误现象，是够停止保存操作。 经验：通常默认为开启状态。 - bgsave指令工作原理 bgsave命令是针对save阻塞问题做的优化。**Redis内部所有涉及到RDB操作都采用bgsave的方式,save命令可以放弃使用**。 bgsave的工作流程如下，其中步骤4只能在当前Redis服务的日志文件中查看。  ##### 1.3、RDB启动方式——save配置 RDB的save配置启动方式，其底层默认使用的bgsave指令。 - 配置 ```shell save second changes ``` - 作用：满足限定时间范围second内key的变化数量达到指定数量changes时进行持久化。 - 参数说明：second——监控时间范围；changes：监控key的变化量 - 位置：在Redis服务的配置文件中进行配置 - 示例 ```shell save 900 1 #900秒内，只要变化一个就持久化一个 save 300 10 #300秒内，有10个变化就持久化一次 save 60 10000 #60秒内，有10000个变化就持久化一次 ``` - save配置工作原理  **注意：**save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的；save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系；save配置启动后执行的是bgsave操作 ##### 1.4、RDB启动方式对比 | 方式 | save指令 | bgsave指令/save配置 | | :------------: | :------: | :-----------------: | | 读写 | 同步 | 异步 | | 阻塞客户端指令 | 是 | 否 | | 额外内存消耗 | 否 | 是 | | 启动新进程 | 否 | 是 | ##### 1.5、RDB优缺点 - **优点：** - RDB是一个紧凑压缩的二进制文件,存储效率较高； - RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景RDB恢复数据的速度要比AOF快很多； - 应用:服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。 - **缺点：** - RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据； - bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能； - Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象。 #### 2、AOF 对于RDB来说，其存储数据量较大，效率较低；它是基于快照思想设计的，每次读写都是全部数据，当数据量巨大时,效率非常低；在大数据量下的IO性能较低；它基于fork创建子进程，内存产生额外消耗；同时宕机带来的数据丢失风险。AOF的作用就是减少这些弊端带来问题。 ##### 2.1、AOF的概念 - AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为：**RDB记录数据，而AOF记录数据产生的过程**。 - AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。 ##### 2.2、AOF原理 每当一次写入命令执行后，都会将该命令刷新至AOF缓存区，之后将这些命令同步到AOF文件中。  ##### 2.3、AOF写数据的三中策略 - **always**：每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。 - **everysec**：每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置，但是在系统突然宕机的情况下会丢失1秒的数据。 - **no**：由操作系统控制每次同步到AOF文件的周期，整体过程不可控。 ##### 2.4、AOF配置 - 开启AOF ```shell appendonly yes|no ``` 说明：是否开启AOF持久化功能，默认为不开启状态。yes：开启，no：不开启。 - 选择AOF写数据策略 ```shell appendfsync always|everysec|no ``` 说明：选择AOF的写数据策略。 - 自定义AOF文件名 ```shell appendfilename filename ``` 说明：AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof - AOF文件存储路径 ```shell dir path ``` 说明：AOF持久化文件保存路径，与RDB持久化文件保持一致即可 ##### 2.5、AOF重写 - 概念: 随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。  - AOF重写的作用： - 降低磁盘占用量，提高磁盘利用率 - 提高持久化效率，降低持久化写时间，提高lO性能 - 降低数据恢复用时，提高数据恢复效率 - AOF重写规则 - 进程内已超时的数据不再写入文件 - 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。如：del key1、hdel key2、srem key3、set key3 111、set key4 222等 - 对同一数据的多条命令合并为一条命令。如lpush list1 a、lpush list1 b、lpush list1 c可以转化为:lpush list1 a b c。 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素。 - AOF重写方式 - 手动重写（执行命令） ```shell bgrewriteaof ``` 手动重写方式在需要重写的位置手动输入上述命令，其原理如下  - 自动重写（配置项 ） 自动重写触发条件设置 ```shell auto-aof-rewrite-min-size size #aof触发时缓冲区最小大小size，单位为m auto-aof-rewrite-percentage percentage #aof触发时缓冲区超过aof_base_size的百分比最小值percentage，单位为% ``` 自动重写比对参数（运行指令info Persistence获取具体信息） ```shell ①aof_current_size ②aof_base_size ``` 自动重写触发条件判断规则： ```shell ①aof_current_size > auto-aof-rewrite-min-size ②(aof_current_size - aof_base_size)/aof_base_size => auto-aof-rewrite-percentage ``` - AOF工作流程 always和everysec工作流程  重写流程工作流程：  #### 3、AOF与RDB对比 | 持久化方式 | RDB | AOF | | :----------: | :----------------: | :----------------: | | 占用存储空间 | 小（数据级：压缩） | 大（指令级：重写） | | 存储速度 | 慢 | 快 | | 回复速度 | 快 | 慢 | | 数据安全性 | 会丢失数据 | 依据策略决定 | | 资源消耗 | 高/重量级 | 低/轻量级 | | 启动优先级 | 低 | 高 | **如何选择：** - 对数据非常敏感，建议使用默认的AOF持久化方案 - AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。 - 注意:由于AOF文件存储体积较大，且恢复速度较慢。 - 数据呈现阶段有效性，建议使用RDB持久化方案 - 数据可以良好的做到阶段内无丢失(该阶段是开发者或运维人员手工维护的)，且恢复速度较快，阶段点数据恢复通常采用RDB方案。 - 注意:利用RDB实现紧凑的数据持久化会使Redis降的很低。 - 综合比对 - RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊。 - 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF。 - 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB。 - 灾难恢复选用RDB。 - 双保险策略，同时开启RDB和AOF，重启后，Redis优先使用AOF来恢复数据，降低丢失数据的量。 ### 二、Redis事务 #### 1、概念 Redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列)。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。 Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证： - 批量操作在发送 EXEC 命令前被放入队列缓存。 - 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。 - 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。 一个事务从开始到执行会经历以下三个阶段： - 开始事务。 - 命令入队。 - 执行事务。 #### 2、事务的基本操作 - 开启事务 ```shell multi ``` 说明：设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务队列`queue`中。 - 执行事务 ```shell exec ``` 说明：设定事务结束的位置，同时执行事务。与`multi`成对出现，成对使用 。 - 取消事务 ```shell discard ``` 说明：终止当前事务的定义，发生在`multi`之后，`exec`之前。 加入事务的命令暂时进入到任务队列中，并没有被立即执行，只有执行exec命令之后才开始执行；若发现事务定义错误时，可以使用`discard`命令取消事务。 一下试一次事务的执行示例 ```shell 127.0.0.1:6380> multi OK 127.0.0.1:6380> set tel 123 QUEUED 127.0.0.1:6380> get tel QUEUED 127.0.0.1:6380> set tel 345 QUEUED 127.0.0.1:6380> get tel QUEUED 127.0.0.1:6380> exec 1) OK 2) "123" 3) OK 4) "345" 127.0.0.1:6380> ``` #### 3、事务的执行流程  #### 4、事务的注意事项 - 定义事务的过程中，命令格式输入错误 - 语法错误：指命令书写格式有误 - 处理结果错误：如果定义的事务中所包含的命令存在语法错误，整体事务中的所有命令均不能执行，包括那些语法正常的命令。 - 事务定义过程中，命令执行出现错误 - 运行错误：指命令格式正确，但是无法正确执行。例如对list执行incr操作。 - 处理结果错误：能够正确运行的命令会被执行，运行错误的命令不会被执行。 已执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。 #### 5、监视锁 - 对key添加监视锁，在执行exec前如果key发生了变化，终止事务执行 ```shell watch key [key2 ...] ``` - 取消多所有key的监事锁 ```shell unwatch ``` 当`watch`监控的key在一个事务中被改变时，整个事务的说有指令都不会被执行。`watch`指令必须在`multi`指令之前执行。 #### 6、分布式锁 - 使用setnx设置一个公共锁 ```shell setnx lock-key value ``` 利用setnx指令的返回值特征，有值则返回设置失败，无值则返回设置成功。 - 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作； - 对于返回设置失败的，不具有控制权，排队或等待； 操作完毕通过`del`操作释放锁。 - 使用expire为锁key添加时间限制，到时不释放锁，放弃锁 ```shell expire lock-key second pexpire lock-key milliseconds ``` 该种方式可以解决死锁问题。 由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。 - 例如:持有锁的操作最长执行时间127ms，最短执行时间7ms. - 测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时 - 锁时间设定推荐:最大耗时*120%+平均网络延迟*110% - 如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可