事务
概念
Transaction
事务:一个最小的不可再分的工作单元;通常一个事务对应一个完整的业务(例如银行账户转账业务,该业务就是一个最小的工作单元)
一个完整的业务需要批量的DML(insert、update、delete)语句共同联合完成
事务只和DML语句 ( 数据库操作语句 ) 有关,或者说DML语句才有事务。这个和业务逻辑有关,业务逻辑不同,DML语句的个数不同
特性
▧ 原子性(A) 事务是最小单位,不可再分
▧ 一致性(C) 事务要求所有的DML语句操作的时候,必须保证同时成功或者同时失败
▧ 隔离性(I) 事务A和事务B之间具有隔离性
▧ 持久性(D) 是事务的保证,事务终结的标志(内存的数据持久到硬盘文件中)
行为
▧ 开启事务 Start Transaction
▧ 事务结束 End Transaction
▧ 提交事务 Commit Transaction
▧ 回滚事务 Rollback Transaction
标志
开启标志
任何一条DML语句(insert、update、delete)执行,标志事务的开启
结束标志
▧ 提交 成功的结束,将所有的DML语句操作历史记录和底层硬盘数据来一次同步
▧ 回滚 失败的结束,将所有的DML语句操作历史记录全部清空
代码库
Django 自带的代码库
from django.db import transaction
使用
方式一, 直接使用将一段操作设置为事务
with transaction.atomic(): ...
方式二, 装饰器方式
@transaction.atomic def foo(): ....
悲观锁
概念
总是假设最坏的情况,每次取数据时都认为其他线程会修改,所以都会加锁(读锁、写锁、行锁等)
当其他线程想要访问数据时,都需要阻塞挂起。可以依靠数据库实现,如行锁、读锁和写锁等,都是在操作之前加锁
保证同一时刻只有一个线程能操作数据,其他线程则会被 block
运用场景
▧ 无脏读 上锁数据保证一致, 因此无脏读, 对脏读不允许的环境悲观锁可以胜任
▧ 无并行 悲观锁对事务成功性可以保证, 但是会对数据加锁导致无法实现数据的并行处理.
▧ 事务成功率高 上锁保证一次成功, 因此在对数据处理的成功率要求较高的时候更适合悲观锁.
▧ 开销大 悲观锁的上锁解锁是有开销的, 如果超大的并发量这个开销就不容小视, 因此不适合在高并发环境中使用悲观锁
▧ 一次性完成 如果乐观锁多次尝试的代价比较大,也建议使用悲观锁, 悲观锁保证一次成功
实例
from django.shortcuts import render from django.http import HttpResponse from django.views.generic import View from django.db import transaction from 应用名.models import 模型类名 # 类视图 (并发,悲观锁) class MyView(View): @transaction.atomic def post(self, request): # select * from 表名 where id=1 for update; # for update 就表示锁,只有获取到锁才会执行查询,否则阻塞等待。 obj = 模型类名.objects.select_for_update().get(id=1) # 等事务提交后,会自动释放锁。 return HttpResponse('ok')
乐观锁
概念
总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此不会上锁
但是在更新时会判断其他线程在这之前有没有对数据进行修改,一般会使用版本号机制或CAS操作实现。
如果发现数据被改了. 就进行事务回滚取消之前的操作
运用场景
▧ 脏读 乐观锁不涉及到上锁的处理, 因此在数据并行需求的时候是更适合乐观锁,当然会产生脏读, 不过用回滚取消掉了.
▧ 高并发 相比起悲观锁的开销, 乐观锁也是比悲观锁更适合于高并发场景
▧ 事务成功率低 乐观锁不能保证每次事务的成功, 是使用回滚方式来保证数据一致性, 因此会导致事务成功率很低.
▧ 读多写少 乐观锁适用于读多写少的应用场景,这样可以提高并发粒度
▧ 开销小 可能会导致很多次的回滚都不能拿到正确的处理回应, 因此如果对成功性要求低,而且每次开销小比较适合乐观锁
实例
from django.shortcuts import render from django.http import JsonResponse from django.views.generic import View from django.db import transaction from 应用名.models import GoodsSKU # 类视图 (并发,乐观锁) class MyView(View): @transaction.atomic def post(self, request): '''订单创建''' count = 3 # 订购3件商品 # 设置事务保存点 s1 = transaction.savepoint() # 乐观锁,最多尝试5次 for i in range(5): # 查询商品的信息(库存) try: sku = GoodsSKU.objects.get(id=1) except: # 商品不存在 transaction.savepoint_rollback(s1) return JsonResponse({'res': 1, 'errmsg': '商品不存在'}) # 判断商品的库存 if count > sku.stock: transaction.savepoint_rollback(s1) return JsonResponse({'res': 2, 'errmsg': '商品库存不足'}) # 更新商品的库存和销量 orgin_stock = sku.stock # 原库存 (数据库隔离级别必须是Read Committed;如果是Repeatable Read,那么多次尝试读取的原库存都是一样的,读不到其他线程提交更新后的数据。) new_stock = orgin_stock - count # 更新后的库存 new_sales = sku.sales + count # 更新后的销量 # update 商品表 set stock=new_stock, sales=new_sales where id=1 and stock = orgin_stock # 通过where子句中的条件判断库存是否进行了修改。(并发,乐观锁) # 返回受影响的行数 res = GoodsSKU.objects.filter(id=1, stock=orgin_stock).update(stock=new_stock, sales=new_sales) if res == 0: # 如果修改失败 if i == 4: # 如果尝试5次都失败 transaction.savepoint_rollback(s1) return JsonResponse({'res': 3, 'errmsg': '下单失败'}) continue # 再次尝试 # 否则更新成功 # 跳出尝试循环 break # 提交事务 transaction.savepoint_commit(s1) # 返回应答 return JsonResponse({'res': 4, 'message': '创建成功'})