乐观锁介绍:
watch指令在redis事物中提供了CAS的行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突,这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改,整个事物将会回滚,不执行任何动作,从而保证原子性操作,并且执行exec会得到null的回复。
乐观锁工作机制:
watch 命令会监视给定的每一个key,当exec时如果监视的任一个key自从调用watch后发生过变化,则整个事务会回滚,不执行任何动作。注意watch的key是对整个连接有效的,事务也一样。如果连接断开,监视和事务都会被自动清除。当然exec,discard,unwatch命令,及客户端连接关闭都会清除连接中的所有监视。还有,如果watch一个不稳定(有生命周期)的key并且此key自然过期,exec仍然会执行事务队列的指令。
客户端1 | 客户端2 | 说明 |
redis 127.0.0.1:6379> get age “10” redis 127.0.0.1:6379> get name “zhangsan” |
redis 127.0.0.1:6379> get age “10” redis 127.0.0.1:6379> get name “zhangsan” |
数据库中两客户端登录,及键初始值。 |
redis 127.0.0.1:6379> multi OK redis 127.0.0.1:6379> incr age QUEUED redis 127.0.0.1:6379> set name lisi QUEUED |
此时,客户端1开启事务,并提交队列命令: 1.想要将当前age自增+1运算; 2.将name值改为lisi |
|
redis 127.0.0.1:6379> incr age (integer) 11 |
此时,客户端2修改了age值 | |
redis 127.0.0.1:6379> exec 1) (integer) 12 2) OK redis 127.0.0.1:6379> get name |
此时,客户端1执行队列命令,发现运算之后age不是理想中的11,而是12原因是被其它客户插足抢先给修改了。name值也修改了。这样可能导致数据不一致性…
为了解决这个问题引入“乐观锁”的机制: |
|
客户端1-引入“乐观锁”机制 | 客户端2 | 说明 |
redis 127.0.0.1:6379> get age “10” redis 127.0.0.1:6379> get name “zhangsan” |
redis 127.0.0.1:6379> get age “10” redis 127.0.0.1:6379> get name “zhangsan” |
数据库中两客户端登录,及键初始值。 |
redis 127.0.0.1:6379> watch age name OK redis 127.0.0.1:6379> multi OK redis 127.0.0.1:6379> incr age QUEUED redis 127.0.0.1:6379> set name lisi QUEUED |
此时,客户端1用watch命令监视age和name,然后开启事务,并提交队列命令 | |
redis 127.0.0.1:6379> incr age (integer) 11 |
此时,客户端2修改了age值 | |
redis 127.0.0.1:6379> exec (nil) redis 127.0.0.1:6379> get age “11” redis 127.0.0.1:6379> get name “zhangsan” |
此时,客户端1执行队列命令,由watch监控发现此期间age的值已经被修改过,则让事整个务回滚,不做任何动作。
watch可以同时监控多个键,在监控期间只要有一个键被其它客户端改变,则整个事务回滚。 |
|
最新评论
命令: nload
真是个良心站点哇,大公无私,爱了爱了
还可以直接搞一张映射表,存 uid | time | source_index, 第一次直接查对应的 time 选出前100, 第二次直接用 CompleteFuture 去分别用 source_in
干得漂亮,多个朋友堵条路
2021.2.2版本的不适用吧
现在还可以用么
激活码有用,感谢分享
激活码的地址打不开了