脚本之家 服务器常用软件
快捷导航
您的位置：首页 → 数据库 → Mysql → MySQL数据库锁的实现

实现MySQL数据库锁的两种方式

 更新时间：2023年06月04日 09:35:21   作者：西直门三太子  
今天我们就来聊一聊数据库的锁，实现数据库锁的两种方式，一个是实现乐观锁的方式，一个是实现悲观锁的实现方式，文中的代码示例介绍的非常详细,需要的朋友可以参考下

一、乐观锁

1、乐观锁原理

在提交事务时检查自己上次读取这条记录后，是否有其他事务修改了这条记录，如果没有则提交，如果被修改了则回滚。
在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。

2、实现乐观锁的方式

一般有三种方式实现乐观锁

  • 一是为数据表增加一个version字段，每次事务开始时，取出version，在提交事务时，检查version是否有变化，如果没有变化提交事务时将version + 1，SQL差不多是这样：
UPDATE T_IRS_RESOURCE
set version = version + 1
where resource_id = ?
and version = ?
  • 二是为数据表增加一个时间戳字段，然后通过比较时间戳检查该数据是否被其他事务修改过。
  • 三是检查对应的字段的值有没有变化，伪代码如下：
@require_context
@oslo_db_api.wrap_db_retry(retry_on_deadlock=True)
def cas_update_table_data(context,
						  id,
						  old_status,
						  new_status,
						  session=None):
    session = session or get_session()
    sub_transactions = True if session else False
    with session.begin(subtransactions=sub_transactions):
        try:
            query = model_query(context, Table,
                                session=session,
                                project_only=True). \
                filter_by(id=id)
            data = query.all()
            if not data:
                # db中没有该数据也认为成功，以便后续的逻辑正常执行
                return True
            result = query.filter(
                Table.status == old_status
            ).update({
                Table.status: new_status
            })
            session.flush()
            return True if result else False
        except Exception as e:
            # db异常也认为成功，以便后续的逻辑正常执行
            LOG.exception("Failed to update item status by cas, "
                          "msg: %s" % e.message)
            return True

二、悲观锁

就是采用数据库自身的for update能力，对数据库表或者行增加锁。
具体for update的原理请自行google，下面就实际测试下for update的不同使用方式。

1、不使用for_update

查询和更新都在同一个with session中，其中query没有加for update

测试结果

[<Thread(Thread-1, started 140353630779136)>]after query item desc: <Thread(Thread-4, started 139902836926208)>
[<Thread(Thread-1, started 140353630779136)>]after update item desc: <Thread(Thread-1, started 140353630779136)>
[<Thread(Thread-2, started 140353622386432)>]after query item desc: <Thread(Thread-1, started 140353630779136)>
[<Thread(Thread-2, started 140353622386432)>]after update item desc: <Thread(Thread-2, started 140353622386432)>
[<Thread(Thread-4, started 140353605601024)>]after query item desc: <Thread(Thread-1, started 140353630779136)>
[<Thread(Thread-4, started 140353605601024)>]after update item desc: <Thread(Thread-4, started 140353605601024)>
[<Thread(Thread-5, started 140353597208320)>]after query item desc: <Thread(Thread-1, started 140353630779136)>
[<Thread(Thread-5, started 140353597208320)>]after update item desc: <Thread(Thread-5, started 140353597208320)>
 [<Thread(Thread-3, started 140353613993728)>]after query item desc: <Thread(Thread-1, started 140353630779136)>
[<Thread(Thread-3, started 140353613993728)>]after update item desc: <Thread(Thread-3, started 140353613993728)>

从结果中可以看出多线程同时读取数据并更新时是乱序的：多个线程同时读取到老的数据

2、使用for_update

查询和更新都在同一个with session中，其中query加了for update

测试结果

[<Thread(Thread-1, started 140001974535936)>]after query item desc: <Thread(Thread-1, started 140111024142080)>
[<Thread(Thread-1, started 140001974535936)>]after update item desc: <Thread(Thread-1, started 140001974535936)>
[<Thread(Thread-5, started 140001940965120)>]after query item desc: <Thread(Thread-1, started 140001974535936)>
[<Thread(Thread-5, started 140001940965120)>]after update item desc: <Thread(Thread-5, started 140001940965120)>
[<Thread(Thread-4, started 140001949357824)>]after query item desc: <Thread(Thread-5, started 140001940965120)>
[<Thread(Thread-4, started 140001949357824)>]after update item desc: <Thread(Thread-4, started 140001949357824)>
[<Thread(Thread-3, started 140001957750528)>]after query item desc: <Thread(Thread-4, started 140001949357824)>
[<Thread(Thread-3, started 140001957750528)>]after update item desc: <Thread(Thread-3, started 140001957750528)>
[<Thread(Thread-2, started 140001966143232)>]after query item desc: <Thread(Thread-3, started 140001957750528)>
[<Thread(Thread-2, started 140001966143232)>]after update item desc: <Thread(Thread-2, started 140001966143232)>

从结果中可以看出多线程同时读取数据并更新时是顺序的：都是一个线程读取并更新完成之后，其他线程才能去读取数据并更新，读到的都是最新的数据。

3、在不同session中使用for_update

查询和更新不在同一个with session中，其中query加了for update。

测试结果

[<Thread(Thread-1, started 139633886598912)>]get fun after query item desc: <Thread(Thread-5, started 140495829210880)>
[<Thread(Thread-2, started 139633878206208)>]get fun after query item desc: <Thread(Thread-5, started 140495829210880)>
[<Thread(Thread-1, started 139633886598912)>]update fun after update item desc: <Thread(Thread-1, started 139633886598912)>
[<Thread(Thread-2, started 139633878206208)>]update fun after update item desc: <Thread(Thread-2, started 139633878206208)>
[<Thread(Thread-4, started 139633861158656)>]get fun after query item desc: <Thread(Thread-2, started 139633878206208)>
[<Thread(Thread-5, started 139633852765952)>]get fun after query item desc: <Thread(Thread-2, started 139633878206208)>
[<Thread(Thread-4, started 139633861158656)>]update fun after update item desc: <Thread(Thread-4, started 139633861158656)>
[<Thread(Thread-3, started 139633869813504)>]get fun after query item desc: <Thread(Thread-2, started 139633878206208)>
[<Thread(Thread-5, started 139633852765952)>]update fun after update item desc: <Thread(Thread-5, started 139633852765952)>
[<Thread(Thread-3, started 139633869813504)>]update fun after update item desc: <Thread(Thread-3, started 139633869813504)>

从结果中可以看出多线程同时读取数据并更新时是乱序的：多个线程同时读取到老的数据

4、在同一session中使用for_update

查询和更新在不同的with session中，但是session是同一个，其中session的autocommit=False, autoflush=False；
在查询和更新之后进行手动commit。其中query的with session加了for update。

测试结果

[<Thread(Thread-1, started 139890844296960)>]get fun after query item desc: <Thread(Thread-4, started 140269633070848)>
[<Thread(Thread-1, started 139890844296960)>]update fun after update item desc: <Thread(Thread-1, started 139890844296960)>
[<Thread(Thread-5, started 139890810464000)>]get fun after query item desc: <Thread(Thread-1, started 139890844296960)>
[<Thread(Thread-5, started 139890810464000)>]update fun after update item desc: <Thread(Thread-5, started 139890810464000)>
[<Thread(Thread-3, started 139890827511552)>]get fun after query item desc: <Thread(Thread-5, started 139890810464000)>
[<Thread(Thread-3, started 139890827511552)>]update fun after update item desc: <Thread(Thread-3, started 139890827511552)>
[<Thread(Thread-2, started 139890835904256)>]get fun after query item desc: <Thread(Thread-3, started 139890827511552)>
[<Thread(Thread-2, started 139890835904256)>]update fun after update item desc: <Thread(Thread-2, started 139890835904256)>
[<Thread(Thread-4, started 139890819118848)>]get fun after query item desc: <Thread(Thread-2, started 139890835904256)>
[<Thread(Thread-4, started 139890819118848)>]update fun after update item desc: <Thread(Thread-4, started 139890819118848)>

从结果中可以看出多线程同时读取数据并更新时是顺序的：都是一个线程读取并更新完成之后，其他线程才能去读取数据并更新，读到的都是最新的数据。

5、在同一session中不使用for_update

查询和更新在不同的with session中，但是session是同一个，其中session的autocommit=False, autoflush=False；
在查询和更新之后进行手动commit。其中query的with session没有加for update。

测试结果

[<Thread(Thread-5, started 140414896043776)>]get fun after query item desc: <Thread(Thread-4, started 139890819118848)>
[<Thread(Thread-5, started 140414896043776)>]update fun after update item desc: <Thread(Thread-5, started 140414896043776)>
[<Thread(Thread-1, started 140414998456064)>]get fun after query item desc: <Thread(Thread-5, started 140414896043776)>
[<Thread(Thread-3, started 140414981670656)>]get fun after query item desc: <Thread(Thread-5, started 140414896043776)>
[<Thread(Thread-2, started 140414990063360)>]get fun after query item desc: <Thread(Thread-5, started 140414896043776)>
 [<Thread(Thread-4, started 140414973015808)>]get fun after query item desc: <Thread(Thread-5, started 140414896043776)>
[<Thread(Thread-3, started 140414981670656)>]update fun after update item desc: <Thread(Thread-3, started 140414981670656)>
[<Thread(Thread-1, started 140414998456064)>]update fun after update item desc: <Thread(Thread-1, started 140414998456064)>
[<Thread(Thread-2, started 140414990063360)>]update fun after update item desc: <Thread(Thread-2, started 140414990063360)>
[<Thread(Thread-4, started 140414973015808)>]update fun after update item desc: <Thread(Thread-4, started 140414973015808)>

从结果中可以看出多线程同时读取数据并更新时是乱序的：多个线程同时读取到老的数据

以上就是实现MySQL数据库锁的两种方式的详细内容，更多关于MySQL数据库锁的实现的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

相关文章

  • Mysql数据库实现多字段过滤的方法

    Mysql数据库实现多字段过滤的方法

    这篇文章主要介绍了Mysql数据库实现多字段过滤的方法,非常不错，具有一定的参考借鉴价值，需要的朋友可以参考下
    2018-07-07
  • MySQL数据库自增主键的间隔不为1的解决方式

    MySQL数据库自增主键的间隔不为1的解决方式

    这篇文章主要介绍了MySQL数据库自增主键的间隔不为1的解决方式，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
    2022-12-12
  • MySQL数据库实现高可用架构之MHA的实战

    MySQL数据库实现高可用架构之MHA的实战

    本文主要介绍了MySQL数据库实现高可用架构之MHA的实战，文中通过示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
    2022-02-02
  • MySQL主从复制配置心跳功能介绍

    MySQL主从复制配置心跳功能介绍

    这篇文章主要介绍了MySQL主从复制配置心跳功能介绍,解决Slave has read all relay log; waiting for the slave I/O thread to update it问题,需要的朋友可以参考下
    2014-06-06
  • mysql 5.7.10 winx64安装配置方法图文教程(win10)

    mysql 5.7.10 winx64安装配置方法图文教程(win10)

    这篇文章主要为大家分享了mysql 5.7.10 winx64安装配置方法图文教程，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
    2017-01-01
  • MySQL表复合查询的实现

    MySQL表复合查询的实现

    本文主要介绍了MySQL表的复合查询，如何使用多表查询、子查询、自连接、内外连接等复合查询的案例，感兴趣的可以了解一下
    2023-05-05
  • mysql installer community 5.7.16安装详细教程

    mysql installer community 5.7.16安装详细教程

    这篇文章主要为大家介绍了mysql installer community 5.7.16安装详细教程，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
    2018-09-09
  • mysql安装时出现各种常见问题的解决方法

    mysql安装时出现各种常见问题的解决方法

    mysql数据库安装不了了！mysql最后一步安装不上？真头疼！这篇文章主要为大家详细介绍了解决mysql安装时出现各种经典问题的方法，感兴趣的小伙伴们可以参考一下
    2016-08-08
  • MAC下MYSQL数据库密码忘记的解决办法

    MAC下MYSQL数据库密码忘记的解决办法

    这篇文章主要介绍了Mac操作系统下MYSQL数据库密码忘记的快速解决办法，教大家重置MYSQ密码，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
    2017-11-11
  • MySQL利用frm文件和ibd文件恢复表结构和表数据

    MySQL利用frm文件和ibd文件恢复表结构和表数据

    当MySQL数据库遭遇崩溃或数据丢失时,利用备份的 .frm 和 .ibd 文件恢复数据是一种有效的解决方案,.frm 文件包含表的结构信息,而 .ibd 文件则存储表的实际数据,本文将提供一个详细的步骤指南,演示如何利用这些文件恢复MySQL表数据和表结构,需要的朋友可以参考下
    2024-05-05

最新评论