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