mysql事务原理以及锁

一、Innodb事务原理

  1.什么是事务

    a.事务(Transaction)是数据库区别于文件系统的重要特性之一,事务会把数据库从一种一致性状态转换为另一种一致性状态。

    b.在数据库提交时,可以确保要么所有修改都已保存,要么所有修改都不保存。

  2.事务的特性:(ACID)

    a.原子性(Atomicity):事务中的全部操作在数据库中是不可分割的,要么全部完成,要么均不执行。

    b.一致性(Consistency):几个并行执行的事务,其执行结果必须与按某一顺序串行执行的结果相一致。

    c.隔离性(Isolation):事务的执行不受其他事务的干扰,事务执行的中间结果对其他事务必须是透明的。

    d.持久性(Durability):对于任意已提交事务,系统必须保证该事务对数据库的改变不被丢失,即使数据库出现故障.

   3.事务的分类:

    3.1扁平事务(Flat Transactions)

      a.扁平事务是事务类型中最简单但使用最频繁的事务。

      b.在扁平事务中,所有的操作都处于同一层次,由BEGIN/START TRANSACTION开始事务,由COMMIT/ROLLBACK结束,且都是原子的,要么都执行,要么都回滚

      c.扁平事务是应用程序成为原子操作的基本组成模块。

    扁平事务一般有四种不同的结果:

      1.事务成功完成

 事务成功完成

      2.应用程序要求停止事务。比如应用程序在捕获到异常时会回滚事务

 应用程序要求停止事务

      3.外界因素强制终止事务。如连接超时或连接断开

 外界因素强制终止事务

      4.带有保存节点的扁平事务

        a.带有保存节点的扁平事务允许事务在执行过程中回滚到较早的一个状态,而不是回滚所有的操作。

        b.保存点用来通知系统应该记住事务当前的状态,以便当之后发生错误时,事务能回到保存点当时的状态。

        c.对于扁平事务来说,在事务开始时隐式地设置了一个保存点,回滚时只能回滚到事务开始时的状态。

 带有保存节点的扁平事务

    3.2、链事务

      什么是链事务: 

        a.链事务(Chained Transaction)是指一个事务由多个子事务链式组成

        b.前一个子事务的提交操作和下一个子事务的开始操作合并成一个原子操作,这意味着下一个事务将看到上一个事务的结果,就好像在一个事务中进行的一样。

        c.在提交子事务时就可以释放不需要的数据对象,而不必等到整个事务完成后才释放。

      链事务工作示意图:

      链事务与扁平事务的区别:

        a.链事务中的回滚仅限于当前事务,相当于只能恢复到最近的一个保存节点

        b.带保存节点的扁平事务能回滚到任意正确的保存点

        c.带有保存节点的扁平事务中的保存点是易失的,当发生系统崩溃是,所有的保存点都将消失,这意味着当进行恢复时,事务需要从开始处重新执行。

     3.3、嵌套事务

      什么是嵌套事务?

        a.嵌套事务(Nested Transaction)是一个层次结构框架。

        b.由一个顶层事务(top-level transaction)控制着各个层次的事务。

        c.顶层事务之下嵌套的事务成为子事务(subtransaction),其控制着每一个局部的操作,子事务本身也可以是嵌套事务.

        d.嵌套事务的层次结构可以看成是一颗树.

      嵌套事务结构如下图所示:

  4.事务的隔离级别

     SQL标准定义的四个隔离级别:

      a.READ UNCOMMITTED: 未提交读,作用域为(global)全局 、(session)当前会话

 未提交读

      b.READ COMMITTED: 提交读

 提交读

      c.REPEATABLE READ: 可重复读

 可重复读

      d.SERIALIZABLE: 可串行读

 可串行读

     4.1、Read uncommitted 

      读取未提交内容。在该隔离级别下,所有事务都可以看到其它未提交事务的执行结果。

      a.事务2查询到的数据是事务1中修改但未提交的数据

      b.但因为事务1回滚了数据,所以事务2查询的数据是不正确的

      c.因此出现了脏读的问题

    4.2、Read committed

      1.读取提交内容。在该隔离级别下,一个事务从开始到提交之前对数据所做的改变对其它事务是不可见的,这样就解决在READ-UNCOMMITTED级别下的脏读问题。

      2.但如果一个事务在执行过程中,其它事务的提交对该事物中的数据发生改变,那么该事务中的一个查询语句在两次执行过程中会返回不一样的结果

 

      a.事务2执行update语句但未提交前,事务1的前两个select操作返回结果是相同的。

      b.但事务2执行commit操作后,事务1的第三个select操作就读取到事务2对数据的改变,导致与前两次select操作返回不同的数据

      c.因此出现了不可重复读的问题。

    4.3、Repeatable read

      1.可重复读。这是MySQL的默认事务隔离级别,能确保事务在并发读取数据时会看到同样的数据行,解决了READ-COMMITTED隔离级别下的不可重复读问题

        2.MySQL的InnoDB存储引擎通过多版本并发控制(Multi_Version Concurrency Control, MVCC)机制来解决该问题

      3.在该机制下,事务每开启一个实例,都会分配一个版本号给它,如果读取的数据行正在被其它事务执行DELETE或UPDATE操作(即该行上有排他锁),这时该事物的读取操作不会等待行上的锁释放,而是根据版本号去读取行的快照数据(记录在undo log中)

      4.这样,事务中的查询操作返回的都是同一版本下的数据,解决了不可重复读问题

      a.虽然该隔离级别下解决了不可重复读问题,但理论上会导致另一个问题:幻读(Phantom Read)

        b.正如上面所讲,一个事务在执行过程中,另一个事物对已有数据行的更改

      c.MVCC机制可保障该事物读取到的原有数据行的内容相同,但并不能阻止另一个事务插入新的数据行,这就会导致该事物中凭空多出数据行,像出现了幻读一样,这便是幻读问题

      1)事务2对id=1的行内容进行了修改并且执行了commit操作

      2)事务1中的第二个select操作在MVCC机制的作用下返回的仍是v=1的数据

      3)事务3执行了insert操作

      4) 事务1第三次执行select操作时便返回了id=2的数据行,与前两次的select操作返回的值不一样

    需要说明的是,REPEATABLE-READ隔离级别下的幻读问题是SQL标准定义下理论上会导致的问题,MySQL的InnoDB存储引擎在该隔离级别下,采用了Next-Key Locking锁机制避免了幻读问题。Next-Key Locking锁机制将在后面的锁章节中讲到。

     4.4 Serializable

      1.可串行化。这是事务的最高隔离级别

      2.通过强制事务排序,使之不可能相互冲突,就是在每个读的数据行加上共享锁来实现

      3.在该隔离级别下,可以解决前面出现的脏读、不可重复读和幻读问题

      4.但也会导致大量的超时和锁竞争现象,一般不推荐使用。

二、Mysql数据库中的锁  

  1、MyISAM和InnoDB支持的锁类型

      1. 相对其他数据库而言,MySQL的锁机制比较简单,其最显著的特点是不同的存储引擎支持不同的锁机制。

      2. MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking)。

      3. InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁。

  2、MySQL这3种锁的特性

    1)行级锁

        1. 行级锁分为共享锁和排它锁,行级锁是Mysql中锁定粒度最细的锁。

        2. InnoDB引擎支持行级锁和表级锁,只有在通过索引条件检索数据的时候,才使用行级锁,否就使用表级锁。

        3. 行级锁开销大,加锁慢,锁定粒度最小,发生锁冲突概率最低,并发度最高

        举例: 只根据主键进行查询,并且查询到数据,主键字段产生行锁。

 产生行锁

#### 行锁
'''
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的命令立即返回数据。

    2)表级锁

        1. 表级锁分为表共享锁和表独占锁。

        2. 表级锁开销小,加锁快,锁定粒度大、发生锁冲突最高,并发度最低

        举例:根据非主键不含索引(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;
'''

    3)页级锁

        1. 页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。

        2. 表级锁速度快,但冲突多,行级冲突少,但速度慢。

        3. 所以取了折衷的页级,一次锁定相邻的一组记录,BDB支持页级锁。

        4. 开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。

    总结:

        1. 表级锁更适合于以查询为主,只有少量按索引条件更新数据的应用,如Web应用;

        2. 而行级锁则更适合于有大量按索引条件并发更新少量不同数据,同时又有并发查询的应用,如一些在线事务处理(OLTP)系统。

  3、锁分类

      1. 按操作划分:DML锁,DDL锁

      2. 按锁的粒度划分:表级锁、行级锁、页级锁

      3. 按锁级别划分:共享锁、排他锁

      4. 按加锁方式划分:自动锁、显示锁

      5. 按使用方式划分:乐观锁、悲观锁

  4、乐观锁悲观锁作用

      1. 在并发访问情况下,很有可能出现不可重复读等等读现象。

      2. 为了更好的应对高并发,封锁、时间戳、乐观并发控制(乐观锁)、
          悲观并发控制(悲观锁)都是并发控制采用的主要技术方式。

  5、悲观锁

      1. 悲观锁的实现,往往依靠数据库提供的锁机制

      2. MySQL会对查询结果集中每行数据都添加排他锁,其他线程对该记录的更新与删除操作都会阻塞,排他锁包含行锁、表锁。

      3. 申请前提:没有线程对该结果集中的任何行数据使用排他锁或共享锁,否则申请会阻塞。

      适用场景:悲观锁适合写入频繁的场景。

      注:

        首先我们需要set autocommit=0,即不允许自动提交
        用法:select * from tablename where id = 1 for update;

  6、乐观锁

      1. 在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等,如果相等则进行更新。

      2. 反之程序重新获取库存量,再次进行比较,直到两个库存量的数值相等才进行数据更新。

  7、举例:对商品数量-1操作

    1)悲观锁实现方法

        1. 每次获取商品时,对该商品加排他锁。

        2. 也就是在用户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
'''

python使用悲观锁

SKU.objects.select_for_update().get(id=1)

    2)乐观锁实现方法

        1. 每次获取商品时,不对该商品加锁。

        2. 在更新数据的时候需要比较程序中的库存量与数据库中的库存量是否相等,如果相等则进行更新

        3. 反之程序重新获取库存量,再次进行比较,直到两个库存量的数值相等才进行数据更新。

乐观锁

#### 乐观锁实现加一操作代码
# 我们可以看到,只有当对数量-1操作时才会加锁,只有当程序中值和数据库中的值相等时才正真执行。
'''
//不加锁
select id,name,stock where id=1;
//业务处理
begin;
update shop set stock=stock-1 where id=1 and stock=stock;
commit;
'''

python使用乐观锁 

SKU.objects.filter(id=1, stock=7).update(stock=2)

  8、python适用乐观锁解决事物问题

      使用 django.db.transaction 模块解决MySQL 事物管理 问题   

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

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

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

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

使用transaction模块解决mysql事物问题

# 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)
'''

 transaction使用实例

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

  9、MySQL中 共享锁 和 排它锁 

    1)排它锁

        1. 排它锁又叫写锁,如果事务T对A加上排它锁,则其它事务都不能对A加任何类型的锁。获准排它锁的事务既能读数据,又能写数据。

        2. 用法 :  SELECT … FOR UPDATE

    2)共享锁(share lock)

        1. 共享锁又叫读锁,如果事务T对A加上共享锁,则其它事务只能对A再加共享锁,不能加其它锁。

        2. 获准共享锁的事务只能读数据,不能写数据。

        3. 用法: SELECT … LOCK IN SHARE MODE;

 

  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值