Redis：事务（transaction）

什么是事务？

事务：是指一系列操作步骤，要么完全地执行，要么完全地不执行。
Redis 中的事务（transaction）是一组命令的集合，至少是两个或两个以上的命令，redis 事务保证这些命令被执行时中间不会被任何其他操作打断。

示例：微博中，A 用户关注了 B 用户，那么 A 的关注人列表里面就会有 B 用户，B 的粉丝列表里面就会有 A 用户。

这个关注与被关注的过程是由一系列操作步骤构成：

1. A 用户添加到 B 的粉丝列表里面；
2. B 用户添加到 A 的关注列表里面；

这两个步骤必须全部执行成功，整个逻辑才是正确的，否则就会产生数据的错误，比如A用户的关注列表有B用户，但B的粉丝列表里没有A用户；

redis事务控制

正常情况：

1. MULTI：用MULTI命令告诉Redis，接下来要执行的命令你先不要执行，而是把它们暂时存起来 【开启事务】
2. SADD "user1" 2：第一条命令进入等待队列【命令入队】
3. SADD "user2" 1：第二条命令进入等待队列【命令入队】
4. EXEC：告知redis执行前面发送的两条命令【提交事务】

异常情况：

1. MULTI：正常命令
2. SET key value：正常命令
3. SET key：命令语法错误
4. EXEC：无法执行事务，那么第一条正确的命令也不会执行，所以key的值不会设置成功

例外情况：

1. MULTI：正常命令
2. SET key v1：正常命令
3. INCR key：此命令错误，字符串不能自增
4. EXEC：
   1. 事务依然提交了，key的值被设置为v1，自增操作执行失败，但整个事务没有回滚
   2. 可以放弃事务：discard

放弃情况：

1. MULTI：开启事务
2. SET age 25：命令入队
3. SET age 30：命令入队
4. DISCARD：放弃事务，则命令队列不会被执行

redis事务复杂情况实现

悲观锁

悲观锁（Pessimistic Lock）：每次去拿数据的时候都认为别人会修改该数据，所以每次在拿数据的时候都会先上锁，这样别人想拿这个数据就会 block 阻塞直到它拿到锁。

• 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，让别人无法操作该数据。

乐观锁

乐观锁（Optimistic Lock）：每次去取数据的时候都认为别人不会修改该数据，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这条数据，一般使用版本号机制（类比于MySQL的“MVCC”）进行判断。

• 乐观锁适用于多读的应用类型，这样可以提高吞吐量。
• 乐观锁大多数情况是基于数据版本号（version）的机制实现的：为数据增加一个版本标识。

  在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个“version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加 1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据，不予更新。

乐观锁实现举例：

文件:乐观锁实现举例.png

watch 机制实现乐观锁

监视一个（或多个）key ，如果在事务exec执行之前这个（或这些）key 被其他命令所改动，那么事务将被打断。

示例：

1. set k1 1：设置 k1 值为 1；
2. watch k1：监视 k1；（开始监视 k1，则其他客户端或事务不能修改 k1 的值）
3. set k1 2：设置 k1 值为 2；
4. multi：开始事务；
5. set k1 3：修改 k1 值为 3；
6. exec：提交事务；

如上，k1 的值仍然是 2，而不会被修改为 3，因为在事务开启之前 k1 的值被修改了；