共计 1333 个字符,预计需要花费 4 分钟才能阅读完成。
[info] 仅做了解一般不用,更多是通过 lua 来解决原子性问题。
Redis 支持简单的事务,所谓简单是因为其不支持回滚(回滚是用队列模仿的),与 mysql 有以下区别
type | mysql | redis |
---|---|---|
开启 | start transaction | muitl |
语句 | 普通 sql | 普通命令 |
失败 | rollback 回滚 | discard 取消 |
成功 | commit | exec |
rollback 与 discard 的区别:
如果已经成功执行了 2 条语句, 第 3 条语句出错
Rollback 后, 前 2 条的语句影响消失。
discard 只是取消队列,并非回滚。要用在 exec 前面;
在 mutil 后面的语句中, 语句出错可能有 2 种情况:
1: 语法就有问题,
这种,exec 时, 报错, 所有语句得不到执行
2: 语法本身没错, 但适用对象有问题. 比如 zadd 操作 list 对象
Exec 之后, 会执行正确的语句, 并跳过有不适当的语句.
(如果 zadd 操作 list 这种事怎么避免? 这一点, 由程序员负责)
Example
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379> decrby zz 100
QUEUED
127.0.0.1:6379> incrby xx 100
QUEUED
127.0.0.1:6379> exec
1) (integer) 900
2) (integer) 900
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby zz 100
QUEUED
127.0.0.1:6379> sadd zz haha #语法本身没有错, 那整个事务中的语句都会执行;
QUEUED
127.0.0.1:6379> exec
1) (integer) 800
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
悲观锁与乐观锁
场景如下:
我正在买票
Ticket -1 , money -100
而票只有 1 张, 如果在我 multi 之后, 和 exec 之前, 票被别人买了 — 即 ticket 变成 0 了.
我该如何观察这种情景, 并不再提交
- 悲观的想法: 世界充满危险, 肯定有人和我抢, 给 ticket 上锁, 只有我能操作. [悲观锁]
- 乐观的想法: 没有那么多人和我抢, 因此, 我只需要注意, 在下单之前看看有没有人更改 ticket 的值就可以了 [乐观锁]
Redis 的事务中, 启用的是乐观锁, 只负责监测 key 没有被改动. 具体的命令:watch 命令
watch key1 key2 ... keyN
作用: 监听 key1 key2..keyN 有没有变化, 如果有变, 则事务取消
unwatch
作用: 取消所有 watch 监听
redis 127.0.0.1:6379> watch ticket
OK
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> decr ticket
QUEUED
redis 127.0.0.1:6379> decrby money 100
QUEUED
redis 127.0.0.1:6379> exec #在 exec 之前该数据在其他 session 有改动就取消事务, 返回 nil
(nil)
redis 127.0.0.1:6379> get ticket
"0"
redis 127.0.0.1:6379> get money
"200"
正文完