一、redis持久化

1.概念

Redis提供了多种不同级别的持久化方式:RDB和AOF

  1. RDB持久化:
    指定的时间间隔内生成数据集的时间点快照(point-in-timesnapshot)。
  2. AOF持久化:
    记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。新命令会被追加到文件的末尾。Redis还会在AOF体积过大时在后台对AOF文件进行重写(rewrite),减小AOF文件的大小。
  3. 同时持久化:
    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. 基础配置
1
2
3
save 900 1
save 300 10
save 60 10000

配置分别表示:当达到以下定义的配置时间时,就将内存数据持久化到磁盘
900秒(15分钟)内有1个更改
300秒(5分钟)内有10个更改
60秒内有10000个更改
2. 高级配置

1
2
3
4
5
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./xxx

配置分别表示:
后台备份进程出错时,主进程停不停止写入? 主进程不停止容易造成数据不一致
导出的rdb文件是否压缩 如果rdb的大小很大的话建议这么做
导入rbd恢复时数据时,要不要检验rdb的完整性 验证版本是不是一致
导出来的rdb文件名
rdb的放置路径

2.AOF持久化

  1. 基础配置
1
2
appendonly yes/no
appendfsync always| everysec| no

配置分别表示:
是否打开aof日志功能
什么时候同步aof,[每1个命令|每秒|交给系统自动]写入到aof
2. 高级配置

1
2
3
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文件,然后执行以下命令。

1
2
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. 命令举例
    • 文字说明
      multi
      command1
      command2
      command3
      command4
  3. 条语句作为一个组,并没有真正执行,而是被放入同一队列中。如果,这是执行discard,会直接丢弃队列中所有的命令,而不是做回滚。
    exec
    当执行exec时,对列中所有操作,要么全成功要么全失败
    实际操作
1
2
3
4
5
6
7
8
9
10
11
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并不把这个票给我锁起来,而是等我需要付款[提交事务],才去再次确定是否还有票,如果有我就可以用,如果没有就提交失败