用MySQL实现分布式锁,你听过吗?

用MySQL实现分布式锁,你听过吗?

作者:编程菌zfn 2021-10-09 11:34:59

数据库

MySQL

分布式 以前参加过一个库存系统,由于其业务复杂性,搞了很多个应用来支撑。这样的话一份库存数据就有可能同时有多个应用来修改库存数据。

概述

以前参加过一个库存系统,由于其业务复杂性,搞了很多个应用来支撑。这样的话一份库存数据就有可能同时有多个应用来修改库存数据。

比如说,有定时任务域xx.cron,和SystemA域和SystemB域这几个JAVA应用,可能同时修改同一份库存数据。如果不做协调的话,就会有脏数据出现。

对于跨JAVA进程的线程协调,可以借助外部环境,例如DB或者Redis。下文介绍一下如何使用DB来实现分布式锁。

[[427766]]

设计

本文设计的分布式锁的交互方式如下:

  • 根据业务字段生成transaction_id,并线程安全的创建锁资源
  • 根据transaction_id申请锁
  • 释放锁

动态创建锁资源

在使用synchronized关键字的时候,必须指定一个锁对象。 

  1. synchronized(obj) {  

进程内的线程可以基于obj来实现同步。obj在这里可以理解为一个锁对象。如果线程要进入synchronized代码块里,必须先持有obj对象上的锁。这种锁是JAVA里面的内置锁,创建的过程是线程安全的。那么借助DB,如何保证创建锁的过程是线程安全的呢?

可以利用DB中的UNIQUE KEY特性,一旦出现了重复的key,由于UNIQUE KEY的唯一性,会抛出异常的。在JAVA里面,是SQLIntegrityConstraintViolationException异常。 

  1. create table distributed_lock 
  2.  id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT COMMENT '自增主键'
  3.  transaction_id varchar(128) NOT NULL DEFAULT '' COMMENT '事务id'
  4.  last_update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NOT NULL COMMENT '最后更新时间'
  5.  create_time TIMESTAMP DEFAULT '0000-00-00 00:00:00' NOT NULL COMMENT '创建时间'
  6.  UNIQUE KEY `idx_transaction_id` (`transaction_id`) 

transaction_id是事务Id,比如说,可以用

仓库 + 条码 + 销售模式

来组装一个transaction_id,表示某仓库某销售模式下的某个条码资源。不同条码,当然就有不同的transaction_id。如果有两个应用,拿着相同的transaction_id来创建锁资源的时候,只能有一个应用创建成功。

一条distributed_lock记录插入成功了,就表示一份锁资源创建成功了。

DB连接池列表设计

在写操作频繁的业务系统中,通常会进行分库,以降低单数据库写入的压力,并提高写操作的吞吐量。如果使用了分库,那么业务数据自然也都分配到各个数据库上了。

在这种水平切分的多数据库上使用DB分布式锁,可以自定义一个DataSouce列表。并暴露一个getConnection(String transactionId)方法,按照transactionId找到对应的Connection。

实现代码如下: 

  1. package dlock; 
  2.  
  3. import com.alibaba.druid.pool.DruidDataSource; 
  4. import org.springframework.stereotype.Component; 
  5.  
  6. import javax.annotation.PostConstruct; 
  7. import java.io.FileInputStream; 
  8. import java.io.IOException; 
  9. import java.sql.Connection
  10. import java.util.ArrayList; 
  11. import java.util.List; 
  12. import java.util.Properties; 
  13.  
  14. @Component 
  15. public class DataSourcePool { 
  16.     private List<DruidDataSource> dlockDataSources = new ArrayList<>(); 
  17.  
  18.     @PostConstruct 
  19.     private void initDataSourceList() throws IOException { 
  20.         Properties properties = new Properties(); 
  21.         FileInputStream fis = new FileInputStream("db.properties"); 
  22.         properties.load(fis); 
  23.  
  24.         Integer lockNum = Integer.valueOf(properties.getProperty("DLOCK_NUM")); 
  25.         for (int i = 0; i < lockNum; i++) { 
  26.             String user = properties.getProperty("DLOCK_USER_" + i); 
  27.             String password = properties.getProperty("DLOCK_PASS_" + i); 
  28.             Integer initSize = Integer.valueOf(properties.getProperty("DLOCK_INIT_SIZE_" + i)); 
  29.             Integer maxSize = Integer.valueOf(properties.getProperty("DLOCK_MAX_SIZE_" + i)); 
  30.             String url = properties.getProperty("DLOCK_URL_" + i); 
  31.  
  32.             DruidDataSource dataSource = createDataSource(user,password,initSize,maxSize,url); 
  33.             dlockDataSources.add(dataSource); 
  34.         } 
  35.     } 
  36.  
  37.     private DruidDataSource createDataSource(String user, String passwordInteger initSize, Integer maxSize, String url) { 
  38.         DruidDataSource dataSource = new DruidDataSource(); 
  39.         dataSource.setDriverClassName("com.mysql.jdbc.Driver"); 
  40.         dataSource.setUsername(user); 
  41.         dataSource.setPassword(password); 
  42.         dataSource.setUrl(url); 
  43.         dataSource.setInitialSize(initSize); 
  44.         dataSource.setMaxActive(maxSize); 
  45.  
  46.         return dataSource; 
  47.     } 
  48.  
  49.     public Connection getConnection(String transactionId) throws Exception { 
  50.         if (dlockDataSources.size() <= 0) { 
  51.             return null
  52.         } 
  53.  
  54.         if (transactionId == null || "".equals(transactionId)) { 
  55.             throw new RuntimeException("transactionId是必须的"); 
  56.         } 
  57.  
  58.         int hascode = transactionId.hashCode(); 
  59.         if (hascode < 0) { 
  60.             hascode = - hascode; 
  61.         } 
  62.  
  63.         return dlockDataSources.get(hascode % dlockDataSources.size()).getConnection(); 
  64.     } 

首先编写一个initDataSourceList方法,并利用Spring的PostConstruct注解初始化一个DataSource 列表。相关的DB配置从db.properties读取。 

  1. DLOCK_NUM=2 
  2.  
  3. DLOCK_USER_0="user1" 
  4. DLOCK_PASS_0="pass1" 
  5. DLOCK_INIT_SIZE_0=2 
  6. DLOCK_MAX_SIZE_0=10 
  7. DLOCK_URL_0="jdbc:mysql://localhost:3306/test1" 
  8.  
  9. DLOCK_USER_1="user1" 
  10. DLOCK_PASS_1="pass1" 
  11. DLOCK_INIT_SIZE_1=2 
  12. DLOCK_MAX_SIZE_1=10 
  13. DLOCK_URL_1="jdbc:mysql://localhost:3306/test2" 

DataSource使用阿里的DruidDataSource。

接着最重要的一个实现getConnection(String transactionId)方法。实现原理很简单,获取transactionId的hashcode,并对DataSource的长度取模即可。

连接池列表设计好后,就可以实现往distributed_lock表插入数据了。 

  1. package dlock; 
  2.  
  3. import org.springframework.beans.factory.annotation.Autowired; 
  4. import org.springframework.stereotype.Component; 
  5.  
  6. import java.sql.*; 
  7.  
  8. @Component 
  9. public class DistributedLock { 
  10.  
  11.     @Autowired 
  12.     private DataSourcePool dataSourcePool; 
  13.  
  14.     /** 
  15.      * 根据transactionId创建锁资源 
  16.      */ 
  17.     public String createLock(String transactionId) throws Exception{ 
  18.         if (transactionId == null) { 
  19.             throw new RuntimeException("transactionId是必须的"); 
  20.         } 
  21.         Connection connection = null
  22.         Statement statement = null
  23.         try { 
  24.             connection = dataSourcePool.getConnection(transactionId); 
  25.             connection.setAutoCommit(false); 
  26.             statement = connection.createStatement(); 
  27.             statement.executeUpdate("INSERT INTO distributed_lock(transaction_id) VALUES ('" + transactionId + "')"); 
  28.             connection.commit(); 
  29.             return transactionId; 
  30.         } 
  31.         catch (SQLIntegrityConstraintViolationException icv) { 
  32.             //说明已经生成过了。 
  33.             if (connection != null) { 
  34.                 connection.rollback(); 
  35.             } 
  36.             return transactionId; 
  37.         } 
  38.         catch (Exception e) { 
  39.             if (connection != null) { 
  40.                 connection.rollback(); 
  41.             } 
  42.             throw  e; 
  43.         } 
  44.         finally { 
  45.             if (statement != null) { 
  46.                 statement.close(); 
  47.             } 
  48.  
  49.             if (connection != null) { 
  50.                 connection.close(); 
  51.             } 
  52.         } 
  53.     } 

根据transactionId锁住线程

接下来利用DB的select for update特性来锁住线程。当多个线程根据相同的transactionId并发同时操作select for update的时候,只有一个线程能成功,其他线程都block住,直到select for update成功的线程使用commit操作后,block住的所有线程的其中一个线程才能开始干活。

我们在上面的DistributedLock类中创建一个lock方法。 

  1. public boolean lock(String transactionId) throws Exception { 
  2.        Connection connection = null
  3.        PreparedStatement preparedStatement = null
  4.        ResultSet resultSet = null
  5.        try { 
  6.            connection = dataSourcePool.getConnection(transactionId); 
  7.            preparedStatement = connection.prepareStatement("SELECT * FROM distributed_lock WHERE transaction_id = ? FOR UPDATE "); 
  8.            preparedStatement.setString(1,transactionId); 
  9.            resultSet = preparedStatement.executeQuery(); 
  10.            if (!resultSet.next()) { 
  11.                connection.rollback(); 
  12.                return false
  13.            } 
  14.            return true
  15.        } catch (Exception e) { 
  16.            if (connection != null) { 
  17.                connection.rollback(); 
  18.            } 
  19.            throw  e; 
  20.        } 
  21.        finally { 
  22.            if (preparedStatement != null) { 
  23.                preparedStatement.close(); 
  24.            } 
  25.  
  26.            if (resultSet != null) { 
  27.                resultSet.close(); 
  28.            } 
  29.  
  30.            if (connection != null) { 
  31.                connection.close(); 
  32.            } 
  33.        } 
  34.    } 

实现解锁操作

当线程执行完任务后,必须手动的执行解锁操作,之前被锁住的线程才能继续干活。在我们上面的实现中,其实就是获取到当时select for update成功的线程对应的Connection,并实行commit操作即可。

那么如何获取到呢?我们可以利用ThreadLocal。首先在DistributedLock类中定义

  1. private ThreadLocal threadLocalConn = new ThreadLocal<>(); 

每次调用lock方法的时候,把Connection放置到ThreadLocal里面。我们修改lock方法。 

  1. public boolean lock(String transactionId) throws Exception { 
  2.        Connection connection = null
  3.        PreparedStatement preparedStatement = null
  4.        ResultSet resultSet = null
  5.        try { 
  6.            connection = dataSourcePool.getConnection(transactionId); 
  7.            threadLocalConn.set(connection); 
  8.            preparedStatement = connection.prepareStatement("SELECT * FROM distributed_lock WHERE transaction_id = ? FOR UPDATE "); 
  9.            preparedStatement.setString(1,transactionId); 
  10.            resultSet = preparedStatement.executeQuery(); 
  11.            if (!resultSet.next()) { 
  12.                connection.rollback(); 
  13.                threadLocalConn.remove(); 
  14.                return false
  15.            } 
  16.            return true
  17.        } catch (Exception e) { 
  18.            if (connection != null) { 
  19.                connection.rollback(); 
  20.                threadLocalConn.remove(); 
  21.            } 
  22.            throw  e; 
  23.        } 
  24.        finally { 
  25.            if (preparedStatement != null) { 
  26.                preparedStatement.close(); 
  27.            } 
  28.  
  29.            if (resultSet != null) { 
  30.                resultSet.close(); 
  31.            } 
  32.  
  33.            if (connection != null) { 
  34.                connection.close(); 
  35.            } 
  36.        } 
  37.    } 

这样子,当获取到Connection后,将其设置到ThreadLocal中,如果lock方法出现异常,则将其从ThreadLocal中移除掉。

有了这几步后,我们可以来实现解锁操作了。我们在DistributedLock添加一个unlock方法。 

  1. public void unlock() throws Exception { 
  2.        Connection connection = null
  3.        try { 
  4.            connection = threadLocalConn.get(); 
  5.            if (!connection.isClosed()) { 
  6.                connection.commit(); 
  7.                connection.close(); 
  8.                threadLocalConn.remove(); 
  9.            } 
  10.        } catch (Exception e) { 
  11.            if (connection != null) { 
  12.                connection.rollback(); 
  13.                connection.close(); 
  14.            } 
  15.            threadLocalConn.remove(); 
  16.            throw e; 
  17.        } 
  18.    } 

缺点

毕竟是利用DB来实现分布式锁,对DB还是造成一定的压力。当时考虑使用DB做分布式的一个重要原因是,我们的应用是后端应用,平时流量不大的,反而关键的是要保证库存数据的正确性。对于像前端库存系统,比如添加购物车占用库存等操作,最好别使用DB来实现分布式锁了。

进一步思考

如果想锁住多份数据该怎么实现?比如说,某个库存操作,既要修改物理库存,又要修改虚拟库存,想锁住物理库存的同时,又锁住虚拟库存。其实也不是很难,参考lock方法,写一个multiLock方法,提供多个transactionId的入参,for循环处理就可以了。这个后续有时间再补上。

 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/247387.html<

(0)
管理的头像管理
上一篇2025-04-27 02:32
下一篇 2025-04-27 02:34

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注