3、事务与持久化

1、事务

2、持久化

1. RDB

2.AOF

3.Redis的主从架构

4、哨兵

5、Redis的集群

1、事务

Redis事务：一次失误操作，该成功的成功，该失败的失败。

先开启事务，执行一些列的命令，但是命令不会立即执行，会存放在一个

队列中，如果你执行事务，

这个队列中的所有命令都会执行，取消事务，所有命令全部作废。

redis事务的主要作用就是串联多个命令防止别的命令插队。

大致的形式如下：

begin();

try {

// 执行业务相关代码

command1();

command2();

....

commit();

} catch(Exception e) {

rollback();

}

Redis 在形式上看起来也差不多，MULTI、EXEC、DISCARD这三个指令构成

了 redis 事务处理的基础：

MULTI：用来组装一个事务，从输入Multi命令开始，输入的命令都会依次进

入命令队列中，但不会执行，直到输入Exec后，redis会将之前的命令依次执

行。

EXEC：用来执行一个事务

DISCARD：用来取消一个事务

事务操作案例1：

127.0.0.1:6379> set user_id 1 # 定义了一个user_id的key，value为1

OK

127.0.0.1:6379> get user_id

"1"

127.0.0.1:6379> MULTI # 标记事务开始

OK

127.0.0.1:6379> incr user_id # 多条命令按顺序入队，返回值为QUEUED，

表示这个命令加入队列了，还没有被执行。

QUEUED

127.0.0.1:6379> incr user_id # incr是自增的命令

QUEUED

127.0.0.1:6379> incr user_id

QUEUED

127.0.0.1:6379> exec # 执行事务过后返回的是事务块内所有命令的返回

值，按命令执行的先后顺序排列。

1) (integer) 2

2) (integer) 3

3) (integer) 4

127.0.0.1:6379> get user_id

"4"

上面的指令演示了一个完整的事务过程，所有的指令在 exec 之前不执行，

而是缓存在服务器的一个事务队列中，

服务器一旦收到 exec 指令，才开执行整个事务队列，执行完毕后一次性返

回所有指令的运行结果。

因为 Redis 的单线程特性，不用担心自己在执行队列的时候被其它指令打

搅，可以保证能得到的有顺序的执行。

案例二：取消事务，放弃执行事务块内的所有命令

127.0.0.1:6379> keys *

(empty list or set)

127.0.0.1:6379> MULTI

OK

127.0.0.1:6379> SET greeting "hello"

QUEUED

127.0.0.1:6379> set kaka aaa

QUEUED

127.0.0.1:6379> DISCARD

OK

127.0.0.1:6379> keys *

(empty list or set)

案例三：组队中某个命令出现了错误报告，执行时整个队列中所有的命令

都会被取消。

127.0.0.1:6379> flushdb

OK

127.0.0.1:6379> multi # 开启一个事务块

OK

127.0.0.1:6379> set name ready

QUEUED

127.0.0.1:6379> set age 30

QUEUED

127.0.0.1:6379> set1 age 60 # 命令有问题，导致加入队列失败

(error) ERR unknown command `set1`, with args beginning with: `age`,

`60`,

127.0.0.1:6379> exec # 执行exec的时候，事务中所有命令都被取消

(error) EXECABORT Transaction discarded because of previous errors.

127.0.0.1:6379> get name # 事务当中的命令也全都执行失败了

(nil)

127.0.0.1:6379> keys *

(empty list or set)

案例4：命令组队的过程中没有问题，执行中出现了错误会导致部分成功部

分失败。

127.0.0.1:6379> flushdb

127.0.0.1:6379> multi

127.0.0.1:6379> set books iamastring

QUEUED

127.0.0.1:6379> set poorman iamdesperate

QUEUED

127.0.0.1:6379> incr books

QUEUED

127.0.0.1:6379> exec

1) OK

2) OK

3) (error) ERR value is not an integer or out of range # incr是对数字类型的进行自增，而books存的是字母

127.0.0.1:6379> get books # 只有incr books 执行失败了，其他都执行成功了。

"iamastring"

127.0.0.1:6379> get poorman

"iamdesperate"

watch监听

WATCH：在执行multi之前，先执行watch key1 [key2 …]，可以监视一个或

者多个key，

若在事务的exec命令之前这些key对应的值被其他命令所改动了，那么

事务中所有命令都将被打断，

即事务所有操作将被取消执行。

unwatch：取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命

令之后，

EXEC 命令或 DISCARD 命令先被执行了的话，那么就不

需要再执行UNWATCH 了。

注意：Redis 禁止在 multi 和 exec 之间执行 watch 指令，而必须在 multi

之前做好盯住关键变量，否则会出错。

案例一：监视 key，且事务成功执行

127.0.0.1:6379> set lock aa # 新增了一个key/value

OK

127.0.0.1:6379> keys * # 数据库目前就只有lock一个key

1) "lock"

127.0.0.1:6379> watch lock lock_times # 开始监视key为lock或者

lock_times的值。lock_times在数据库不存在也是可以监视的

OK

127.0.0.1:6379> multi # 开启事务

OK

127.0.0.1:6379> SET lock "huangz"

QUEUED

127.0.0.1:6379> INCR lock_times # INCR是对一个key值进行自增，假如

key值没有在数据库当中会进行创建并赋值为1

QUEUED

127.0.0.1:6379> EXEC # 开始执行事务

1) OK

2) (integer) 1

127.0.0.1:6379> get lock

"huangz"

127.0.0.1:6379> get lock_times

"1"

案例二：监视 key，且事务被打断，这里需要准备两个客户端进行测试

案例三：watch监听key后只对当前客户端第一个事务有效，并不影响其他命令执行

127.0.0.1:6379> watch lock

OK

127.0.0.1:6379> set lock 'cccc'

OK

127.0.0.1:6379> get lock

"cccc"

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set lock bbb

QUEUED

127.0.0.1:6379> exec #exec 指令返回一个 null 回复时，事务执行是失败

的

(nil)

案例四：取消监听

127.0.0.1:6379> WATCH lock lock_times

OK

127.0.0.1:6379> UNWATCH

OK