基于MySQL分布式鎖實現(xiàn)原理及代碼

工欲善其事必先利其器，在基于MySQL實現(xiàn)分布式鎖之前，我們要先了解一點MySQL鎖自身的相關(guān)內(nèi)容

MySQL鎖

我們知道：鎖是計算機協(xié)調(diào)多個進程或者線程并發(fā)訪問同一資源的機制，而在數(shù)據(jù)庫中，除了傳統(tǒng)的機器資源的爭用之外，存儲下來的數(shù)據(jù)也屬于供用戶共享的資源，所以如何保證數(shù)據(jù)并發(fā)的一致性，有效性是每個數(shù)據(jù)庫必須解決的問題。

除此之外，鎖沖突也是影響數(shù)據(jù)庫并發(fā)性能的主要因素，所以鎖對于數(shù)據(jù)庫而言就顯得非常重要，也非常復(fù)雜。

而存儲引擎是MySQL中非常重要的底層組件，主要用來處理不同類型的SQL操作，其中包括創(chuàng)建，讀取，刪除和修改操作。在MySQL中提供了不同類型的存儲引擎，根據(jù)其不同的特性提供了不同的存儲機制，索引和鎖功能。

根據(jù)show engines;能夠列出MySQL下支持的存儲引擎

如果沒有特殊指定，那么在MySQL8.0中會設(shè)置InnoDB為默認的存儲引擎

在實際工作中，根據(jù)需求選擇最多的兩種存儲引擎分別為：

• InnoDB
• MyISAM

所以我們主要針對這兩種類型來介紹MySQL的鎖

InnoDB

InnoDB支持多粒度鎖定，可以支持行鎖，也可以支持表鎖。如果沒有升級鎖粒度，那么默認情況下是以行鎖來設(shè)計的。

關(guān)于行鎖和表鎖的介紹：

• 行鎖對指定數(shù)據(jù)進行加鎖，鎖定粒度最小，開銷大，加鎖慢，容易出現(xiàn)死鎖問題，出現(xiàn)鎖沖突的概率最小，并發(fā)性最高
• 表鎖對整個表進行加鎖，鎖定粒度大，開銷小，加鎖快，不會出現(xiàn)死鎖，出現(xiàn)鎖沖突的概率最大，并發(fā)性最低

這里沒法說明那種鎖最好，只有合適不合適

在行級鎖中，可以分為兩種類型

• 共享鎖
• 排他鎖

共享鎖

共享鎖又稱為讀鎖，允許其他事務(wù)讀取被鎖定的對象，也可以在其上獲取其他共享鎖，但不能寫入。

舉個例子：

• 事務(wù)T在數(shù)據(jù)A擁有共享鎖，那么當前事務(wù)T對數(shù)據(jù)A可以讀，但是不能修改。而且事務(wù)T2同樣可以對數(shù)據(jù)A擁有共享鎖，這樣相當于在數(shù)據(jù)A上分別存在不同事務(wù)的共享鎖
• 數(shù)據(jù)A擁有了事務(wù)T的共享鎖，那么就不能再擁有其他事務(wù)的排他鎖

下面是關(guān)于共享鎖的具體實現(xiàn)，關(guān)鍵代碼:select .. from table lock in share mode

 -- 創(chuàng)建實例表
 create table tb_lock(
     id bigint primary key auto_increment,
     t_name varchar(20)
 ) engine=InnoDB;

開啟兩個窗口來測試：

自動提交全部關(guān)閉，可以通過select @@autocommit;來查看

通過以上實驗，我們總結(jié):

• 共享鎖基于行鎖處理，不同事務(wù)可以在同一條數(shù)據(jù)上獲取共享鎖
• 如果多個事務(wù)在同一條數(shù)據(jù)上獲取共享鎖，當想要修改該條數(shù)據(jù)的時候，會出現(xiàn)阻塞狀態(tài)。直到其他事務(wù)將鎖釋放，該能夠繼續(xù)修改

修改，刪除，插入會默認對涉及到的數(shù)據(jù)加上排他鎖

• 單純的select操作不會有任何影響，select不會加任何鎖
• 執(zhí)行commit;自動釋放鎖

排它鎖

又叫寫鎖。只允許獲取鎖的事務(wù)對數(shù)據(jù)進行操作【更新，刪除】，其他事務(wù)對相同數(shù)據(jù)集只能進行讀取，不能有跟新或者刪除操作。而且也不能在相同數(shù)據(jù)集獲取到共享鎖。

沒錯，就是這么霸道

在MySQL中，想要基于排它鎖實現(xiàn)行級鎖，就需要對表中索引列加鎖，否則的話，排它鎖就屬于表級鎖

下面一一來展示，關(guān)鍵代碼：select .. from XX for update

首先是有索引列狀態(tài)

通過以上實驗，得到結(jié)論：

• 對索引列進行加鎖的鎖定級別為行級鎖，如上所示，當其他事務(wù)想要對相同的數(shù)據(jù)再次加鎖的時候，就會進行到阻塞狀態(tài)。并且如果等待時間過長，會出現(xiàn)如下異常：

 Lock wait timeout exceeded; try restarting transaction

• 對不同行數(shù)據(jù)再次加排它鎖，是沒有任何問題的。
• 對已經(jīng)上鎖的相同數(shù)據(jù)做修改和刪除操作不需要多說，因為InnoDB默認會對其加入排它鎖

下面是無索引列狀態(tài)

通過以上實驗，得到結(jié)論：

• 對非索引列其中一條數(shù)據(jù)加入了排它鎖后，在其他事務(wù)中對不同數(shù)據(jù)再次加入排它鎖，進入了阻塞狀態(tài)
• 說明當加鎖列屬于非索引時，InnoDB會對整個表進行上鎖，進入到表級鎖

接下來我們來看看MyISAM的方式

MyISAM

MyISAM屬于表級鎖，被用來防止任何其他事務(wù)訪問表的鎖。

其中表鎖又分為兩種形式

• 表共享讀鎖： READ
• 表獨占寫鎖： WRITE

這里我們要注意：表級鎖只能防止其他會話進行不適當?shù)淖x取或?qū)懭搿?/p>

• 持有WRITE 鎖的會話可以執(zhí)行表級操作，比如DELETE或者TRUNCATE
• 持有會話READ鎖，不能夠執(zhí)行DELETE或者TRUNCATE操作

表共享讀鎖

不管是READ還是WRITE，都是通過lock table 來獲取表鎖的，而READ鎖擁有如下特性：

• 持有鎖的會話可以讀取表，但是不能進行寫入操作
• 多個會話可以同時獲取READ表的鎖，而其他會話可以在不顯式獲取READ鎖的情況下讀取該表：也就是說直接通過select來操作

那么，接下來我們來看實際操作，關(guān)鍵代碼：lock tables table_name read

 create table tb_lock_isam(
     id bigint primary key auto_increment,
     t_name varchar(20)
 ) engine=MyISAM;

開啟兩個窗口來進行操作：

通過以上實戰(zhàn)，驗證以下結(jié)論：

• 在當前事務(wù)下，獲取到讀鎖，直接查詢鎖定表是沒有問題的，但是如果想要讀取其他表下的數(shù)據(jù)，那么就會出現(xiàn)以下異常：因為其他表并沒有LOCK在其中

 Table 'tb_lock' was not locked with LOCK TABLES

• 事務(wù)A獲取到讀鎖之后，在其他事務(wù)中是可以正常讀取的，并且也可以再次獲取讀鎖。
• 在讀鎖中如果想要進行插入操作是不會成功的，出現(xiàn)以下異常：

 Table 'tb_lock_isam' was locked with a READ lock and can't be updated

• 當前表獲取到讀鎖之后，在當前表沒有釋放讀鎖之前，再獲取寫鎖會一直進入到阻塞狀態(tài)。
• 可以通過非加鎖方式來讀取數(shù)據(jù)，但是要注意：一定是在不同的事務(wù)下

表獨占寫鎖

WRITE鎖的特性和排它鎖的特性非常相似，都特別霸道：

• 持有鎖的會話可以讀寫表
• 只有持有鎖的會話才能訪問該表。在釋放鎖之前，沒有其他會話可以訪問它
• 其他會話對表的鎖請求在WRITE持有鎖時被阻塞

還是通過具體實戰(zhàn)來進行演示效果，關(guān)鍵代碼：lock tables table_name write

通過以上實戰(zhàn)，驗證以下結(jié)論：

• 當事務(wù)獲取到當前表的WRITE鎖的時候，在當前事務(wù)下可以對獲取鎖的表進行任何操作，其他事務(wù)無法對表進行任意操作。
• 在不同事務(wù)下不會對其他表的操作有影響
• 在當前事務(wù)獲取到WRITE鎖之后，只能在當前事務(wù)下操作獲取鎖的表，無法操作其他表，否則會出現(xiàn)以下異常

  Table 'tb_index' was not locked with LOCK TABLES'

【注意】

MyISAM在執(zhí)行查詢語句之前，會自動給涉及的所有表加讀鎖，在執(zhí)行更新操作前，會自動給涉及的表加寫鎖，這個過程并不需要用戶干預(yù)，因此用戶一般不需要使用命令來顯式加鎖

分布式鎖實現(xiàn)

既然已經(jīng)了解到了MySQL鎖相關(guān)內(nèi)容，那么我們就來看看如何實現(xiàn)，首先我們需要創(chuàng)建一張數(shù)據(jù)表

當然，只需要初始化創(chuàng)建一次

 create table if not exists fud_distribute_lock(
     id bigint unsigned primary key auto_increment,
     biz varchar(50) comment '業(yè)務(wù)Key'
     unique(biz)
 ) engine=innodb;

在其中，biz是為了區(qū)分不同的業(yè)務(wù)，也可以理解為資源隔離，并且對biz設(shè)置唯一索引，也能夠防止其鎖級別變?yōu)楸砑夋i

既然for udpate就是加鎖成功，事務(wù)提交就自動釋放鎖，那么這個事情就非常好辦了：

 // 省略了構(gòu)造方法，需要傳入DataSource和biz
 ?
 private static final String SELECT_SQL = 
     "SELECT * FROM fud_distribute_lock WHERE `biz` = ? for update";
 private static final String INSERT_SQL = 
     "INSERT INTO fud_distribute_lock(`biz`) values(?)";
 ?
 // 從構(gòu)造方法中傳入
 private final DataSource source;
 private Connection connection;
 ?
 public void lock() {
     PreparedStatement psmt = null;
     ResultSet rs = null;
 ?
     try {
         // while(true); 
         for (; ; ) {
             connection = this.source.getConnection();
             // 關(guān)閉自動提交事務(wù)
             connection.setAutoCommit(false);
             
             psmt = connection.prepareStatement(SELECT_SQL);
             psmt.setString(1, biz);
             rs = psmt.executeQuery();
             if (rs.next()) {
                 return;
             }
             connection.commit();
             close(connection, psmt, rs);
             // 如果沒有相關(guān)查詢，需要插入
             Connection updConnection = this.source.getConnection();
             PreparedStatement insertStatement = null;
             try {
                 insertStatement = updConnection.prepareStatement(INSERT_SQL);
                 insertStatement.setString(1, biz);
                 if (insertStatement.executeUpdate() == 1) {
                     LOGGER.info("創(chuàng)建鎖記錄成功");
                 }
             } catch (Exception e) {
                 LOGGER.error("創(chuàng)建鎖記錄異常：{}", e.getMessage());
             } finally {
                 close(insertStatement, updConnection);
             }
         }
     } catch (Exception e) {
         LOGGER.error("lock異常信息：{}", e.getMessage());
         throw new BusException(e);
     } finally {
         close(psmt, rs);
     }
 }
 ?
 public void unlock() {
     try {
         // 事務(wù)提交之后自動解鎖
         connection.commit();
         close(connection);
     } catch (Exception e) {
         LOGGER.error("unlock異常信息：{}", e.getMessage());
         throw new BusException(e);
     }
 }
 ?
 public void close(AutoCloseable... closeables) {
     Arrays.stream(closeables).forEach(closeable -> {
         if (null != closeable) {
             try {
                 closeable.close();
             } catch (Exception e) {
                 LOGGER.error("close關(guān)閉異常：{}", e.getMessage());
             }
         }
     });
 }

難點：為什么需要for(;

如果一個請求是第一次進來的，比如biz=order，在這個表中是不會存儲order這條記錄，那么select ...for update就不會生效，所以就需要先將order插入到表記錄中，也就是執(zhí)行insert操作。

insert執(zhí)行成功之后，記錄select...for update，這樣獲取鎖才能生效

總結(jié)

基于MySQL的分布式鎖在實際開發(fā)過程中很少使用，但是我們還是要有一個思路在。那么本節(jié)針對MySQL的分布式鎖實現(xiàn)到這里就結(jié)束了，掌握了MySQL的基礎(chǔ)鎖，那么就會非常簡單了。

到此這篇關(guān)于MySQL實現(xiàn)分布式鎖的文章就介紹到這了,更多相關(guān)MySQL分布式鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論