redis事务和锁机制、持久化操作RDB/AOF

一、Redis事务介绍

Redis事务是一个单独的隔离操作 ：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。

二、Multi、Exec、discard命令

从输入Multi 命令开始,输入的命令都会依次进入命令队列中,但不会执行,直到输入Exec后, Redis会将之前的命令队列中的命令依次执行。组队的过程中可以通过discard来放弃组队。

discard取消组队如下图：

如果在multi组队过程中，发生提示错误，在执行exec提交时会发生错如下图：

如果在multi组队过程中，发生了非提示错误，并不会立马报错，而是在exec提交时才会报错，而且其他命令会正常执行。

三、事务冲突问题

当多个请求同时操作一个数据时会发生数据错误，为了防止这种错误，我们可以进行加锁操作。

1. 乐观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这样的缺点是效率低

2. 悲观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

3. watch key [key]

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

4. unwatch

取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

四、Redis事务三大特性

1. 单独的隔离操作

　事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

2. 没有隔离级别的概念

　队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。

3. 不保证原子性

　事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

五、持久化操作

Redis 提供了2个不同形式的持久化方式：RDB(Redis DataBase)、AOF(Append Of File)

1. RDB

　（1）什么是RDB

　在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

　（2）RDB如何进行备份　

　Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

　（3）RDB备份  

　先通过config get dir  查询rdb文件的目录

　将*.rdb的文件拷贝到别的地方

　rdb的恢复

　　关闭Redis

　　先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb

　　启动Redis, 备份数据会直接加载

　（4）RDB的优势

　适合大规模的数据恢复

　对数据完整性和一致性要求不高更适合使用

　节省磁盘空间

　恢复速度快

　（5）RDB的缺点

　Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

　虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

　在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

2. AOF

　（1）什么是AOF  

　以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

　（2）AOF的持久化过程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

　（3）AOF的优势

　备份机制更稳健，丢失数据概率更低。

　可读的日志文本，通过操作AOF稳健，可以处理误操作。

　（4）AOF的劣势

　比起RDB占用更多的磁盘空间。

　恢复备份速度要慢。

　每次读写都同步的话，有一定的性能压力。

　存在个别Bug，造成恢复不能。

3. AOF和RDB选择

　官方推荐两个都启用。

　如果对数据不敏感，可以选单独用RDB。

　不建议单独用 AOF，因为可能会出现Bug。

　如果只是做纯内存缓存，可以都不用。