Django - ORM - 事务, 乐观锁, 悲观锁

事务

概念

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': '创建成功'})