# redis-持久化-事务-锁 [TOC] ## 一、redis持久化 ### 1.概念 Redis提供了多种不同级别的持久化方式：RDB和AOF 1. RDB持久化： 指定的时间间隔内生成数据集的时间点快照（point-in-timesnapshot）。 2. AOF持久化： 记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。新命令会被追加到文件的末尾。Redis还会在AOF体积过大时在后台对AOF文件进行重写（rewrite），减小AOF文件的大小。 2. 同时持久化： Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下，当Redis重启时，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。 ### 2.RDB的优缺点 1. RDB的优点： 1）RDB是一个非常紧凑（compact）的文件，它保存了Redis在某个时间点上的数据集。这种文件非常适合用于进行备份。 2）RDB非常适用于灾难恢复（disasterrecovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中。 3）RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O操作。 4）RDB在恢复大数据集时的速度比AOF的恢复速度要快。 2. DB的缺点 1）由于每次保存都会有时间间隔，所以如果恢复数据可能丢失最近未保存的数据 2）每次保存RDB的时候，Redis都要fork()出一个子进程，并由子进程来进行持久化工作。在数据集比较庞大时，fork()可能会非常耗时和消耗CPU资源。 ### 3.AOF的优缺点 1. AOF的优点 1）使用AOF持久化会让Redis变得非常耐久：AOF的默认策略为每秒钟fsync一次，在这种配置下，Redis仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。 2）AOF文件是一个只进行追加操作的日志文件（appendonlylog），因此对AOF文件的写入不需要进行seek，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof工具也可以轻易地修复这种问题。 3）Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写：重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，用临时文件的方式，成功后才覆盖。 4）AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。 5）导出（export）AOF文件也非常简单：举个例子，如果你不小心执行了FLUSHALL命令，但只要AOF文件未被重写，那么只要停止服务器，移除AOF文件末尾的FLUSHALL命令，并重启Redis，就可以将数据集恢复到FLUSHALL执行之前的状态。 2. AOF的缺点 1）对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。 2）AOF文件恢复时间比RDB长 2）根据所使用的fsync策略，AOF的速度可能会慢于RDB。 ### 4.总结 1. redis 持久化方式有哪些？有什么区别？ rdb：基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能 aof：以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog 2. RDB和AOF怎么选 一般来说，如果想达到足以媲美关系型数据库的数据安全性，应该同时使用两种持久化功能。 如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。反之则使用AOF 可以采用mysql主从复制的思路，在主库上关闭持久化，用从库来进行持久化操作 ## 二、持久化配置 ### 1.RDB持久化 1) 基础配置 ```sh save 900 1 save 300 10 save 60 10000 ``` 配置分别表示：当达到以下定义的配置时间时，就将内存数据持久化到磁盘 900秒（15分钟）内有1个更改 300秒（5分钟）内有10个更改 60秒内有10000个更改 2) 高级配置 ```sh stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir ./xxx ``` 配置分别表示: 后台备份进程出错时,主进程停不停止写入? 主进程不停止容易造成数据不一致 导出的rdb文件是否压缩 如果rdb的大小很大的话建议这么做 导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致 导出来的rdb文件名 rdb的放置路径 ### 2.AOF持久化 1) 基础配置 ```sh appendonly yes/no appendfsync always| everysec| no ``` 配置分别表示： 是否打开aof日志功能 什么时候同步aof,[每1个命令|每秒|交给系统自动]写入到aof 2) 高级配置 ```sh no-appendfsync-on-rewrite yes/no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ``` 配置分别表示： 正在导出rdb快照的过程中,要不要停止同步aof aof文件大小比起上次重写时的大小,增长率100%时重写,缺点:业务开始的时候，会重复重写多次。 aof文件,至少超过64M时,重写 ## 三、RDB切换AOF \在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF,最好先手动备份dump.rdb文件,然后执行以下命令。 ```sh redis-cli> CONFIG SET appendonly yes redis-cli> CONFIG SET save "" ``` 修改后可以需要验证数据库的键的数量没有改变,写命令会被正确地追加到 AOF 文件的末尾 ## 四、事务和锁 ### 1.redis事务 redis中的事务跟关系型数据库中的事务是一个相似的概念，不同之处是关系型数据库每条语句都执行了,只是执行结果再未落盘,而redis中的事务是将多个操作命令记录下来,等提交时一起执行。 redis中开启一个事务是使用multi，exec提交事务，discard取消队列命令（非回滚操作）。 1) 事务命令 * DISCARD 取消事务，放弃执行事务块内的所有命令。 * EXEC 执行所有事务块内的命令。 * MULTI 标记一个事务块的开始。 * UNWATCH 取消 WATCH 命令对所有 key 的监视。 * WATCH key [key ...] 监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。 2) 命令举例 * 文字说明 ```sh multi command1 command2 command3 command4 ``` 4条语句作为一个组，并没有真正执行，而是被放入同一队列中。如果，这是执行discard，会直接丢弃队列中所有的命令，而不是做回滚。 ```sh exec ``` 当执行exec时，对列中所有操作，要么全成功要么全失败 * 实际操作 ```sh root@xxx ~]# 127.0.0.1:6379> set a b OK root@xxx ~]# 127.0.0.1:6379> MULTI OK root@xxx ~]# 127.0.0.1:6379> set a b QUEUED root@xxx ~]# 127.0.0.1:6379> set c d QUEUED root@xxx ~]# 127.0.0.1:6379> exec 1) OK 2) OK ``` 可以看到,执行了exec命令后,前两条命令才一起执行 ### 2.redis锁[乐观锁] redis支持乐观锁,也就是说,在最后提交时,才确定数据导致能不能执行 以买票来举例如下: 我正在买票,在我下单时,发现还有一张票,我现在下单[开始事务],redis并不把这个票给我锁起来,而是等我需要付款[提交事务],才去再次确定是否还有票,如果有我就可以用,如果没有就提交失败