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

原文地址:https://www.cnblogs.com/shijieli/p/10926198.html

时间: 2024-10-07 11:24:48

Django - ORM - 事务, 乐观锁, 悲观锁的相关文章

[转]数据库并发控制 乐观锁,悲观锁

在数据库中,并发控制有乐观锁和悲观锁之间,什么时候用乐观锁比较好什么时候用悲观锁比较好? 实际生产环境里边,如果并发量不大,完全可以使用悲观锁定的方法,这种方法使用起来非常方便和简单.但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以就要选择乐观锁定的方法. 悲观锁假定其他用户企图访问或者改变你正在访问.更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁.悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长

最全Java锁详解:独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁

在Java并发场景中,会涉及到各种各样的锁如公平锁,乐观锁,悲观锁等等,这篇文章介绍各种锁的分类: 公平锁/非公平锁 可重入锁 独享锁/共享锁 乐观锁/悲观锁 分段锁 自旋锁 01.乐观锁 vs 悲观锁 乐观锁与悲观锁是一种广义上的概念,体现了看待线程同步的不同角度,在Java和数据库中都有此概念对应的实际应用. 1.乐观锁 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制. 乐观锁适用于多

【多线程】公平锁/非公平锁、乐观锁/悲观锁

公平锁/非公平锁(多线程执行顺序的维度) 概念理解 公平锁:加锁前先查看是否有排队等待的线程,有的话优先处理排在前面的线程,先来先得. 非公平所:线程加锁时直接尝试获取锁,获取不到就自动到队尾等待. 例子 ReentrantLock 同时支持两种锁 //创建一个非公平锁,默认是非公平锁 Lock nonFairLock= new ReentrantLock(); Lock nonFairLock= new ReentrantLock(false); //创建一个公平锁,构造传参true Lock

AtomicInteger如何保证线程安全以及乐观锁/悲观锁的概念

众所周知,JDK提供了AtomicInteger保证对数字的操作是线程安全的,线程安全我首先想到了synchronized和Lock,但是这种方式又有一个名字,叫做互斥锁,一次只能有一个持有锁的线程进入,再加上还有不同线程争夺锁这个机制,效率比较低,所以又称“悲观锁”. 但是相应的有了乐观锁的概念,他的思路就是,它不加锁去完成某项操作,如果因为冲突失败就重试,直到成功为止.这种说的比较抽象,我们直接拿AtomicInteger源码举例,因为AtomicInteger保证线程安全就是因为使用了乐观

并发控制:(二)乐观锁 悲观锁

悲观锁:(pessimistic locking):假定:发生冲突的概率比较高,实现:在对任意记录进行修改前,先尝试为该记录加上排他锁(exclusive locking).这样其他事务如果想操作该记录,需要等待锁的释放特点: 当并发量较大,频繁访问时,等待时间较长,并发访问性不好例如: java的synchronized,SqlServer页级锁,Oracle行级锁 乐观锁:(optimistic locking)假设:发生冲突的概率比较低实现:在提交对记录的更改时才将对象锁住,提交前需要检查

乐观锁+悲观锁

乐观锁: 乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制.悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性.但随之而来的就是数据库性能的大量开销,特别是对长事务而 言,这样的开销往往无法承受.而乐观锁机制在一定程度上解决了这个问题.乐观锁,大多是基于数据版本( Version )记录机制实现.何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实

MySQL 乐观锁 悲观锁 共享锁 排他锁

乐观锁 乐观锁是逻辑概念上的锁,不是数据库自带的,需要我们自己去实现.乐观锁是指操作数据库时(更新操作),想法很乐观,认为这次的操作不会导致冲突,在操作数据时,并不进行任何其他的特殊处理(也就是不加锁),而在进行更新后,再去判断是否有冲突了. 通常实现是这样的:在表中的数据进行操作时(更新),先给数据表加一个版本(version)字段,每操作一次,将那条记录的版本号加1.也就是先查询出那条记录,获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查

Mysql:行锁 表锁 乐观锁 悲观锁 读锁 写锁

锁是在执行多线程时用于强行限制资源访问的同步机制,即用于在并发控制中保证对互斥要求的满足.在DBMS中,可以按照锁的粒度把数据库锁分为行级锁(INNODB引擎).表级锁(MYISAM引擎)和页级锁(BDB引擎 ). 行锁 锁定整个行数据,开销大,加锁慢,会出现死锁.锁定粒度小,发生锁冲突的概率低,并发度高. 表锁 锁定整个表数据,开销小,加锁快,不会出现死锁.锁定粒度大,发生锁冲突概率高,并发度低. 悲观锁 每次取数据时都认为别人会修改,所以每次取数据的时候都会上锁,这样别人想拿这个数据就会被阻

Mysql锁机制--乐观锁 & 悲观锁

前言 mysql的并发操作时而引起的数据的不一致性(数据冲突): 丢失更新:两个用户(或以上)对同一个数据对象操作引起的数据丢失. 解决方案:1.悲观锁,假设丢失更新一定存在:sql后面加上for update:这是数据库的一种机制. 2.乐观锁,假设丢失更新不一定发生.update时候存在版本,更新时候按版本号进行更新. 第一部分 悲观锁 1 概念 悲观锁,正如其名,它指的是对数据被外界(包括当前系统的其它事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于