Python项目中解决数据库表锁问题的乐观锁方案

文 | 極光

来源：Python 技术「ID: pythonall」

近期在开发过程中遇到一个棘手问题：由于业务设计存在缺陷，数据库表频繁出现不定期的锁定现象，进而引发服务器运行异常。经排查，根本原因是多线程同时尝试更新同一张表中的同一条记录，从而引发了冲突。本文将详细阐述如何避免此类问题。

问题描述

近期因公司业务需求，产品设计了一套新系统，预计将有大量内部及外部用户接入。接到需求后，研发团队加班加点，历时两个月终于完成系统上线。

系统初期用户量较少，运行平稳。但随着用户规模扩大，系统逐渐暴露出一些异常，部分业务信息在更新时频繁报错。通过查看日志发现，错误根源在于数据库记录被锁定，导致更新操作失败。

定位问题后，我们反复查阅日志并深入分析，最终锁定原因：该表的状态字段存在多个接口方法同时更新的情况，且并发操作频繁。即数据库中存在多个会话同时操作同一表中的同一行记录，从而触发了数据库的行锁机制，导致表记录被锁。

问题分析

既然定位到问题根源，该如何解决？首先需要了解两个核心概念：

悲观锁（Pessimistic Lock）：顾名思义，这种策略非常“悲观”，认为每次获取数据时，别人都可能修改它。因此，在修改数据前会先加锁，其他想修改该数据的操作必须等待直到获取锁为止。

乐观锁（Optimistic Lock）：与悲观锁相反，这种策略非常“乐观”，认为修改数据时别人不会同时修改，因此不加锁。但在提交更新时，会判断在此期间数据是否被他人更新过。乐观锁适用于读多写少的场景，能有效提高系统吞吐量。

通过上述两种方式均可解决问题，那么哪种更合适？我们来简单分析一下：

• 悲观锁通常通过 “select …… for update” 语句实现，即在更新前先对记录加锁，再执行更新。然而，这种方式开销较大，加锁过程耗时较多，不符合当前业务对性能的需求，因此直接排除。
• 乐观锁则轻量得多。其主要实现方式是在表中增加一个版本字段，例如 version。每次查询需更新的记录时，where 条件中需包含 version=?。当查询获取到 version 值后，若其他会话已更新该字段，version 值将发生变化，导致当前更新失败。此时需重新获取最新 version 值，再次执行 update 语句。

问题解决

经过上述分析，解决思路已清晰，接下来就是编码实现：

    /**
     * 乐观锁更新
     * @param id
     * @return
     */
    public boolean update(int id){
        int cnt = 0;
        while (cnt == 0) {
            USER user = query("SELECT * FROM table_user WHERE id = #{id}", id);
            cnt = update("UPDATE table_user SET version=version + 1, status = 2 WHERE id=#{id} AND version=#{version}", id, user.version());
            if(cnt > 0){
               // 返回更新成功
                return true;
            }
        }
        return false;
    }
 

总结

本文仅基于 MySQL 自身特性解决了该问题。实际上，还有其他方式可解决此类冲突，例如通过 Redis 或 MQ 消息队列等机制。若读者感兴趣，后续可进一步探讨。

更多关于Python线上问题排查与解决的资料，请关注本站其他相关文章！