redis事务
事务是什么
可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞。
能干嘛?
一个队列中,一次性、顺序性、排他性的执行一系列命令。
常用命令
命令 | 描述 |
---|---|
DISCARD | 取消事务,放弃执行事务块内的所有命令。 |
EXEC | 执行所有事务块内的命令。 |
MULTI | 标记一个事务块的开始。 |
UNWATCH | 取消 WATCH 命令对所有 key 的监视。 |
WATCH key [key ...] | 监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。 |
正常执行
放弃事务
全体连坐
错误发生在exec之前,类似于编译器出错
冤头债主
错误发生在exec之后,类似于运行期出错
redis事务的3个阶段
开启:以multi开启事务
入队:将多个命令入队到事务中,接到这些命令不会立刻执行,而是放到等待执行的事务队列里面
执行:有exec命令触发事务
redis事务的3个特性
单独的隔离操作:事务中的所有命令都会序列化,按顺序的执行。事务在等待执行的时候,不会被其他客户端发送来的米命令请求打断
没有隔离级别的概念:队列中的所有命令没有提交exec之前都是不会被执行的。
不保证原子性:redis中如果一条命令执行失败,其后的命令仍然会被执行,没有回滚。
悲观锁/乐观锁/CAS(Check And Set)
- 悲观锁
- 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
- 乐观锁
- 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。
- 乐观锁策略:提交版本必须大于记录当前版本才能执行更新,否则报异常,说明在此期间有其他人的写操作修改了版本号。
CAS(属于乐观锁)
- Compare and Swap,即比较再交换。CAS(比较并交换)是CPU指令级的操作,只有一步原子操作,所以非常快
- JDK 5之前Java语言是靠synchronized关键字保证同步的,这是一种独占锁,也是悲观锁。
- jdk5增加了并发包java.util.concurrent.*,其下面的类使用CAS算法实现了区别于synchronouse同步锁的一种乐观锁。
对CAS的理解,CAS是一种无锁算法,CAS有3个操作数,内存值V,旧的预期值A,要修改的新值B。当且仅当预期值A和内存值V相同时,将内存值V修改为B,否则什么都不做。
public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }
场景举例:
假设t1,t2线程是同时更新同一变量56的值,因为t1和t2线程都同时去访问同一变量56,所以他们会把主内存的值完全拷贝一份到自己的工作内存空间,所以t1和t2线程的预期值都为56。
假设t1在与t2线程竞争中线程t1能去更新变量的值,而其他线程都失败。t1线程去更新变量值改为57,然后写到内存中。(失败的线程并不会被挂起,而是被告知这次竞争中失败,并可以再次发起尝试)。
此时对于t2来说,内存值变为了57,与预期值56不一致,就操作失败了(想改的值不再是原来的值)。
就是指当两者进行比较时,如果相等,则证明共享数据没有被修改,替换成新值,然后继续往下运行;如果不相等,说明共享数据已经被修改,放弃已经所做的操作,然后重新执行刚才的操作。
CAS的ABA问题
线程intT2获取到的变量值A,尽管期望和当前的内存实际值相同,但可能存在的问题是:内存地址V中的变量已经经历了A->B->A的改变。
解决方案:
JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。如果当前引用 == 预期引用,并且当前标志 == 预期标志,则以原子方式将该引用和该标志的值设置为给定的更新值。源码如下:
/** *expectedReference - 该引用的预期值 *newReference - 该引用的新值 *expectedStamp - 该标志的预期值 *newStamp - 该标志的新值 */ public boolean compareAndSet(V expectedReference, V newReference, int expectedStamp, int newStamp) { Pair<V> current = pair; return expectedReference == current.reference && expectedStamp == current.stamp && ((newReference == current.reference && newStamp == current.stamp) || casPair(current, Pair.of(newReference, newStamp))); }
Watch锁监控
watch指令,类似乐观锁
,如果在本事务执行之前,key的值已经被修改了,那么整个事务队列都不会被执行,同时返回一个Nullmulti-bulk应答以通知调用者事务执行失败。
注意:一旦执行了exec或者discard,之前加的所有监控锁都会被取消掉了。
例子:刷信用卡
初始化信用卡的可用余额和欠额:没执行watch,即没有加锁
我们执行watch锁,无加塞篡改的情况:
我们执行watch锁,有加塞篡改的情况,当watch的key被修改,后面的那个事务全部执行失败(意味着后面的事务必须拿到最新的300才可以执行)
unwatch