Redis教程(二):事务与持久化

Redis的事务

Redis的事务本质:一组命令的集合. 一个事务中所有的命令都会被序列化,在事务执行过程中,会按照顺序执行!
Redis单条命令保证原子性,但Redis的事务不包证原子性!

注意:-Redis事务没有隔离级别的概念-

事务执行步骤

• 开启事务(multi)

• 命令入队(...)

• 执行事务(exec) / 撤销事务(discard)

事务监控

悲观锁:无论什么操作都认为会存在问题,随时都会上锁

乐观锁:无论什么操作都不会认为会存在问题,随时都不上锁.更新数据时会判断一下,在此期间是否修改过数据,

        获取Version.更新时对比Version,没变则更新成功,否则失败.

    测试多线程修改值,使用watch可以当作redis的乐观锁的操作.unwatch取消乐观锁.

Redis的持久化

面试和工作,持久化都是重点!

RDB(Redis DataBase)

指定的时间间隔内将内存中的数据集快照 写入磁盘中,恢复时就将快照读取到内存中.

Redis会单独创建一个(fork)子进程来进行持久化,先将数据写入一个临时文件中,再用这个临时文件替换上场持久化好的文件.

整个过程主进程不会进行任何IO操作的,这就确保了极高的性能.

RDB缺点:最后一次持久化后的数据宕机可能丢失.

Redis默认持久化就是RDB</font>,一般情况下不需要修改这个配置!

RDB保存的文件是dump.rdb,默认在Redis环境下,在工作环境我们会将该文件进行备份.

配置文件中可以进行修改保存文件名

如何恢复RDB文件:
1.将需要恢复的RDB文件放置到redis启动的文件目录下就可以,redis启动时就会自动检查dump.rdb文件并恢复其中的数据.
2.查看需要存放的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "D:\\redis"  # 如果在这个目录下查找dump.rdb,启动就会自动恢复其中的数据.

RDB总结

RDB优点:
1.适合大规模的数据恢复!
2.对数据完整性要求不高!
RDB缺点:
1.需要一定时间间隔进行操作.最后一次持久化后的数据宕机可能丢失.
2.fork进程的时候,会占用一定的内容空间.

AOF(Append Only File)

AOF:将我们的所有命令都记录下来(history),恢复时就把history文件全部执行一次!
原理:以日志的形式记录每个操作,将Redis执行过的每个指令记录下来(读取操作不记录),只需增加文件,不许改写文件.Redis重启后根据日志文件进行全部执行以达到恢复内容.

AOF默认不开启.需要手动在config配置文件配置.

appendonly yes # 开启AOF

AOF保存的是appendonly.aof文件(在config配置文件配置)

appendfilename "appendonly.aof" # 保存为appendonly.aof文件

AOF持久化策略(在config配置文件配置)

appendfsync everysec # AOF每一秒写一次
no-appendfsync-on-rewrite no  # AOF不重写,保证数据安全性

AOF默认文件无限追加,文件会越来越大.
如果AOF文件存在错误,Redis则不能正常启动服务.
Redis给我们通过了redis-check-aof工具.可以对错误的AOF文件进行恢复.但被破坏的数据会被丢失.

redis-check-aof --fix appendonly.aof # 修复AOF文件

AOF总结

AOF优点:
1.每一步修改都会被同步,文件完整性更好!
2.默认每秒同步一次
3.从不同步,效率最高.

AOF缺点:
1.相对于数据文件来说,AOF远远大于RDB,修复速度比RDB慢.
2.AOF运行效率比RDB慢.所以Redis默认配置RDB持久化,而非AOF持久化.