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操作实现。

如果发现数据被改了. 就进行事务回滚取消之前的操作

运用场景

加锁和解锁都是需要消耗CPU资源的，所以在订单 并发少 的情况使用乐观锁会是一个更好的选择

乐观锁适用于读多写少的应用场景，这样可以提高并发粒度

实例

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