• Django


    事务

    概念

    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': '创建成功'})
  • 相关阅读:
    node.js 基础篇
    node.js 开发环境搭建
    Velocity VelocityEngine 支持多种loader 乱码问题
    tomcat集群及session共享
    上海支付宝终面后等了两周,没能收到offer却来了杭州淘宝的电话面试
    支付宝hr终面,忐忑的等待结果
    mysql 数据范围总结
    rsync同步文件(多台机器同步代码...)
    linux基础命令
    路飞学城项目之前后端交互,跨域问题
  • 原文地址:https://www.cnblogs.com/shijieli/p/10926198.html
Copyright © 2020-2023  润新知