🔥码云GVP开源项目 12k star Uniapp+ElementUI 功能强大 支持多语言、二开方便! 广告
# 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并不把这个票给我锁起来,而是等我需要付款[提交事务],才去再次确定是否还有票,如果有我就可以用,如果没有就提交失败