MySQL锁机制以及事务隔离

MySQL中的锁

  • MyISAM和InnoDB支持的锁类型
    1、相对其他数据库而言,MySQL的锁机制比较简单,而其中最显著的特点是不同的存储引擎支持不同的锁机制
    2、MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking)
    3、InnoDB存储引擎即支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁
  • MySQL这3中锁的特性
    • 行级锁
      • 行级锁分为共享锁和排它锁,行级锁是MySQL中锁定粒度最细的锁
      • InnoDB引擎支持行级锁和表级锁,只有在通过索引条件检索数据的时候,才使用行级锁,否就使用表级锁
      • 行级锁开销大,加锁慢,锁定粒度最小,发生锁冲突概率最低,并发度最高
        举例:只根据主键进行查询,并且查询到数据,主键字段缠上行锁
        #### 行锁
        '''
        client1中执行:
            select * from shop where id=1 for update;
        clenet2中执行:
            select * from shop where id=2 for update;   # 可以正常放回数据
            select * from shop where id=1 for update;   # 阻塞
        '''
        # 可以看到:id是主键,当在client1上查询id=1的数据时候,在client2上查询id=2的数据没问题
        # 但在client2上查询id=1的数据时阻塞,说明此时的锁时行锁。
        # 当client1执行commit时,clinet2查询的id=1的命令立即返回数据。
        
    • 表级锁
      • 表级锁分为表共享锁和表独占锁
      • 表级锁开销小,加锁快,锁定粒度大、发生锁冲突最高,并发度最低
      • 举例:根据非主键不含索引(name)进行查询,并且查询到数据,name字段产生表锁
        复制代码
        #### 表锁
        # 可以看到,client1通过非索引的name字段查询到prod11的数据后,在client2查prod**的数据会阻塞,产生表锁。
        '''
        client1中执行:
            select * from shop where name="prod11" for update;
        clenet2中执行:
            select * from shop where name="prod**" for update;
        '''
        
    • 页级锁
    • 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁
    • 表级锁速度快,但冲突多,行级冲突少,但速度慢
    • 所以去了折中的页级,一次锁定相邻的一组记录,BDB支持页级锁
    • 开销和加锁时间介于表锁与杭锁之间;会出现死锁,锁定粒度介于表锁和杭锁之间,并发度一般

总结

  • 表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如Web应用
  • 行级锁更适合于有大量按索引条件并发更新少量不同数据,同时又有并发查询的应用,如一些在线事务处理(OLTP)系统

锁分类

  • 按操作划分:DML锁、DDL锁
  • 暗锁的粒度划分:表级锁、行级锁、页级锁
  • 按锁级别划分:共享锁、排它锁
  • 按加锁方式划分:自动锁、显示锁
  • 按使用方式划分:乐观锁、悲观锁

乐观锁和悲观锁作用

  • 在并发锁访问情况下,很有可能出现不可重复读等等读现象
  • 为了更好的应对高并发,封锁、时间戳、乐观并发控制(乐观锁);悲观并发控制(悲观锁)都是并发控制采用的主要技术方式

悲观锁

  • 悲观锁的实现,往往依靠数据库提供的锁机制
  • MySQL会对查询结果集中每行数据都添加排它锁,其他线程对该记录的更新与删除操作都会阻塞,排它锁包含行锁、表锁
  • 申请前提:没有线程对该结果集中的任何行数据使用排它锁或共享锁,否则申请会阻塞
  • 适用于的场景有
    • 悲观锁适合写入频繁的场景
    • 注意:首先我们需要set autocommit=0,即不允许自动提交
    • 用法:select * from tablename where id = 1 for update。

乐观锁

  • 在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等,如果相等则进行更新。
  • 反之程序重新获取库存量,再次进行比较,直到两个库存量的数值相等才进行数据更新。
  • 举例:对商品数量-1操作
    • 悲观锁实现方法
      • 每次获取商品时,对该商品加排它锁
      • 也就是在用户A获取id=1的商品信息时对该行记录加锁,期间其他用户阻塞等待访问该记录
        #### 悲观锁实现加一操作代码
        # 我们可以看到,首先通过begin开启一个事物,在获得shop信息和修改数据的整个过程中都对数据加锁,保证了数据的一致性。
        '''
        begin;
        select id,name,stock as old_stock from shop  where id=1 for update;
        update shop set stock=stock-1 where id=1 and stock=old_stock;
        commit
        '''
        
    • 悲观锁实现方法
      • 每次获取商品时,不对该商品加锁
      • 在更新数据的时候需要比较程序中的存储量与数据库中的库村量是否相等,如果相等则进行更新
      • 反之程序重新获取库存量,再次进行比较,知道两个库存量的数值相等在进行数据更新
        #### 乐观锁实现加一操作代码
        # 我们可以看到,只有当对数量-1操作时才会加锁,只有当程序中值和数据库中的值相等时才正真执行。
        '''
        //不加锁
        select id,name,stock where id=1;
        //业务处理
        begin;
        update shop set stock=stock-1 where id=1 and stock=stock;
        commit;
        '''
        
    • Python使用乐观锁解决事务问题
      • 使用django.db.transaction模块解决MySQL事务管理问题

      • 在事务当前启动celery异步任务,无法获取为提交的改动

      • 在使用transaction当中,Model.save()都不做commit

      • 因此如果在transaction当中设置异步任务,使用get()查询数据库,将看不到对象在事务当中的改变

      • 这也是实现“可重复读”的事务隔离级别,即同一个事务里面面的多次查询都应该保持结果不变

        # with语句用法
        
        from django.db import transaction
        
        def viewfunc(request):
            # 这部分代码不在事务中,会被Django自动提交
            ...
        
            with transaction.atomic():
                # 这部分代码会在事务中执行
                ...
        '''
        from django.db import transaction
        
        # 创建保存点
        save_id = transaction.savepoint()  
        
        # 回滚到保存点
        transaction.savepoint_rollback(save_id)
        
        # 提交从保存点到当前状态的所有数据库事务操作
        transaction.savepoint_commit(save_id)
        '''
                
        
        from django.db import transaction
        
        def create(self, validated_data):
                """
                保存订单
                """
                # 获取当前下单用户
                user = self.context['request'].user
        
                # 组织订单编号 20170903153611+user.id
                # timezone.now() -> datetime
                order_id = timezone.now().strftime('%Y%m%d%H%M%S') + ('%09d' % user.id)
        
                address = validated_data['address']
                pay_method = validated_data['pay_method']
        
                # 生成订单
                with transaction.atomic():
                    # 创建一个保存点
                    save_id = transaction.savepoint()
        
                    try:
                         # 创建订单信息
                        order = OrderInfo.objects.create(
                            order_id=order_id,
                            user=user,
                            address=address,
                            total_count=0,
                            total_amount=Decimal(0),
                            freight=Decimal(10),
                            pay_method=pay_method,
                            status=OrderInfo.ORDER_STATUS_ENUM['UNSEND'] if pay_method == OrderInfo.PAY_METHODS_ENUM['CASH'] else OrderInfo.ORDER_STATUS_ENUM['UNPAID']
                        )
                        # 获取购物车信息
                        redis_conn = get_redis_connection("cart")
                        redis_cart = redis_conn.hgetall("cart_%s" % user.id)
                        cart_selected = redis_conn.smembers('cart_selected_%s' % user.id)
        
                        # 将bytes类型转换为int类型
                        cart = {}
                        for sku_id in cart_selected:
                            cart[int(sku_id)] = int(redis_cart[sku_id])
        
                        # 一次查询出所有商品数据
                        skus = SKU.objects.filter(id__in=cart.keys())
        
                        # 处理订单商品
                        for sku in skus:
                            sku_count = cart[sku.id]
        
                            # 判断库存
                            origin_stock = sku.stock  # 原始库存
                            origin_sales = sku.sales  # 原始销量
        
                            if sku_count > origin_stock:
                                transaction.savepoint_rollback(save_id)
                                raise serializers.ValidationError('商品库存不足')
        
                            # 用于演示并发下单
                            # import time
                            # time.sleep(5)
        
                            # 减少库存
                            new_stock = origin_stock - sku_count
                            new_sales = origin_sales + sku_count
        
                            sku.stock = new_stock
                            sku.sales = new_sales
                            sku.save()
        
                            # 累计商品的SPU 销量信息
                            sku.goods.sales += sku_count
                            sku.goods.save()
        
                            # 累计订单基本信息的数据
                            order.total_count += sku_count  # 累计总金额
                            order.total_amount += (sku.price * sku_count)  # 累计总额
        
                            # 保存订单商品
                            OrderGoods.objects.create(
                                order=order,
                                sku=sku,
                                count=sku_count,
                                price=sku.price,
                            )
        
                        # 更新订单的金额数量信息
                        order.total_amount += order.freight
                        order.save()
        
                    except ValidationError:
                        raise
                    except Exception as e:
                        logger.error(e)
                        transaction.savepoint_rollback(save_id)
                        raise
        
                    # 提交事务
                    transaction.savepoint_commit(save_id)
        
                    # 更新redis中保存的购物车数据
                    pl = redis_conn.pipeline()
                    pl.hdel('cart_%s' % user.id, *cart_selected)
                    pl.srem('cart_selected_%s' % user.id, *cart_selected)
                    pl.execute()
                    return order
        
        transaction使用举例
        
      • 注:MySQL默认数据库引擎是MyISAM默认不支持事务,所以先使用乐观锁需要先修改数据库引擎
        		+ mysql> show variables like '%storage_engine%';  # 查看数据默认引擎
        mysql> select table_name,`engine` from information_schema.tables where table_schema = 'weibo';  # 查看"weibo"这个数据库所有表默认引擎
        mysql> select CONCAT('alter table ',table_name,' engine=InnoDB;') FROM information_schema.tables WHERE table_schema="weibo" AND ENGINE="MyISAM";   # 生成修改表引擎的语法
        alter table auth_group engine=InnoDB;                 
        alter table auth_group_permissions engine=InnoDB;     
        alter table auth_permission engine=InnoDB;            
        alter table authtoken_token engine=InnoDB;            
        alter table django_admin_log engine=InnoDB;           
        alter table django_content_type engine=InnoDB;        
        alter table django_migrations engine=InnoDB;          
        alter table django_session engine=InnoDB;             
        alter table users_socialuser engine=InnoDB;           
        alter table users_user engine=InnoDB;                 
        alter table users_user_groups engine=InnoDB;          
        alter table users_user_user_permissions engine=InnoDB;
        

MySQL中共享锁和排它锁

1)、排它锁
  • 排它锁又叫写锁,如果事务T对A加上排它锁,则其它事务都不能对A加任何类型的锁。获准排它锁的事务既能读数据,又能写数据。
  • 用法 : SELECT … FOR UPDATE
2)、共享锁(share lock)
  • 共享锁又叫读锁,如果事务T对A加上共享锁,则其它事务只能对A再加共享锁,不能加其它锁。
  • 获准共享锁的事务只能读数据,不能写数据。
  • 用法: SELECT … LOCK IN SHARE MODE;

MySQL中的事务

1、InnoDB事务原理

  • 事务(Transaction)是数据库区别于文件系统的重要特性之一,事务会把数据库从一种一致性状态转换为另一种一致性状态。
  • 在数据库提交时,可以确保要么所有修改都已保存,要么所有修改都不保存。

2、事务的(ACID)特征

  • 1.原子性(Atomicity):整个事物的所有操作要么全部提交成功,要么全部失败回滚(不会出现部分执行的情况)。
  • 2.一致性(Consistency):几个并行执行的事务,其执行结果必须与按某一顺序串行执行的结果相一致。
  • 3.隔离性(Isolation):事务的执行不受其他事务的干扰,事务执行的中间结果对其他事务必须是透明的。
  • 4.持久性(Durability): 一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障

3、事务分类

  • 扁平事务
    • 扁平事务(Flat Transactions)是事务类型中最简单但是使用最频繁的事务
    • 在扁平事务中,所有的操作都处于同一层次,由BEGIN/START TRANSACTION开始事务;由COMMIT/ROLLBACK结束且都是原子的,要么都执行,要么都回滚。
  • 链事务
    • 链事务(Chained Transaction)是指一个事务由多个子事务链式组成。
    • 前一个子事务的提交操作和下一个子事务的开始操作合并成一个原子操作
    • 这样,在提交子事务时就可以释放不需要的数据对象,而不必等到整个事务完成后才释放。
    • 链事务中的回滚仅限于当前事务,相当于只能恢复到最近的一个保存节点,而带保存节点的扁平事务能回滚到任意正确的保存点。
  • 嵌套事务
    • 嵌套事务(Nested Transaction)是一个层次结构框架,由一个顶层事务(top-level transaction)控制着各个层次的事务。
    • 顶层事务之下嵌套的事务成为子事务(subtransaction),其控制着每一个局部的操作,子事务本身也可以是嵌套事务。
    • 因此,嵌套事务的层次结构可以看成是一颗树。
  • 分布式事务
  • 分布式事务(Distributed Transactions)通常是一个在分布式环境下运行的扁平事务,因此需要根据数据所在位置访问网络中不同节点的数据库资源。
  • 例如一个银行用户从招商银行的账户向工商银行的账户转账1000元,这里需要用到分布式事务,因为不能仅调用某一家银行的数据库就完成任务
  • 事务隔离级别
    • 未提交读: 脏读(READ UNCOMMITTED)
      • 事务2查询到的数据是事务1中修改但未提交的数据,但因为事务1回滚了数据
      • 所以事务2查询的数据是不正确的,因此出现了脏读的问题。
    • 提交隔离事务
    • 提交读: 不可重复读(READ COMMITTED)
      • **注意:**一个事务从开始到提交之前对数据所做的改变对其它事务是不可见的,这样就解决在READ-UNCOMMITTED级别下的脏读问题。
      • 事务2执行update语句但未提交前,事务1的前两个select操作返回结果是相同的。
      • 但事务2执行commit操作后,事务1的第三个select操作就读取到事务2对数据的改变。
      • 导致与前两次select操作返回不同的数据,因此出现了不可重复读的问题。
    • 可重复读: 幻读(REPEATABLE READ):这是MySQL的默认事务隔离级别
      • 事务每开启一个实例,都会分配一个版本号给它,如果读取的数据行正在被其它事务执行DELETE或UPDATE操作(即该行上有排他锁)
      • 这时该事物的读取操作不会等待行上的锁释放,而是根据版本号去读取行的快照数据(记录在undo log中)
      • 这样,事务中的查询操作返回的都是同一版本下的数据,解决了不可重复读问题。
      • 虽然该隔离级别下解决了不可重复读问题,但理论上会导致另一个问题:幻读(Phantom Read)
      • 一个事务在执行过程中,另一个事物对已有数据行的更改,MVCC机制可保障该事物读取到的原有数据行的内容相同
      • 但并不能阻止另一个事务插入新的数据行,这就会导致该事物中凭空多出数据行,像出现了幻读一样,这便是幻读问题。
    • 可串行读(SERIALIZABLE)
      • 这是事务的最高隔离级别,通过强制事务排序,使之不可能相互冲突,就是在每个读的数据行加上共享锁来实现。
      • 在该隔离级别下,可以解决前面出现的脏读、不可重复读和幻读问题,但也会导致大量的超时和锁竞争现象,一般不推荐使用。
        祝各位看官老爷万福金安
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值