mysql更新鎖實現代碼,mysql加鎖過程詳解

本文目錄一覽：

• 1、MySQL – for update 行鎖 表鎖
• 2、Java如何實現對Mysql資料庫的行鎖
• 3、用 MySQL 實現分散式鎖，你聽過嗎？

MySQL – for update 行鎖 表鎖

for update 的作用是在查詢的時候為行加上排它鎖，當一個事務的操作未完成時候，其他事務可以讀取但是不能寫入或更新。

它的典型使用場景是 高並發並且對於數據的準確性有很高要求 ，比如金錢、庫存等，一般這種操作都是很長一串並且開啟事務的，假如現在要對庫存進行操作，在剛開始讀的時候是1，然後馬上另外一個進程將庫存更新為0了，但事務還沒結束，會一直用1進行後續的邏輯，就會有問題，所以需要用for upate 加鎖防止出錯。

行鎖的具體實現演算法有三種：record lock、gap lock以及next-key lock。

只在可重複讀或以上隔離級別下的特定操作才會取得 gap lock 或 next-key lock，在 Select、Update 和 Delete 時，除了基於唯一索引的查詢之外，其它索引查詢時都會獲取 gap lock 或 next-key lock，即鎖住其掃描的範圍。主鍵索引也屬於唯一索引，所以主鍵索引是不會使用 gap lock 或 next-key lock

for update 僅適用於InnoDB，並且必須開啟事務，在begin與commit之間才生效。

select 語句默認不獲取任何鎖，所以是可以讀被其它事務持有排它鎖的數據的！

InnoDB 既實現了行鎖，也實現了表鎖。

當有明確指定的主鍵/索引時候，是行級鎖，否則是表級鎖

假設表 user，存在有id跟name欄位，id是主鍵，有5條數據。

明確指定主鍵，並且有此記錄，行級鎖

無主鍵/索引，表級鎖

主鍵/索引不明確，表級鎖

明確指定主鍵/索引，若查無此記錄，無鎖

參考博文：

Java如何實現對Mysql資料庫的行鎖

下面通過一個例子來說明

場景如下：

用戶賬戶有餘額，當發生交易時，需要實時更新餘額。這裡如果發生並發問題，那麼會造成用戶餘額和實際交易的不一致，這對公司和客戶來說都是很危險的。

那麼如何避免：

網上查了下，有以下兩種方法：

1、使用悲觀鎖

當需要變更餘額時，通過代碼在事務中對當前需要更新的記錄設置for update行鎖，然後開始正常的查詢和更新操作

這樣，其他的事務只能等待該事務完成後方可操作

當然要特別注意，如果使用了Spring的事務註解，需要配置一下：

!– (事務管理)transaction manager, use JtaTransactionManager for global tx —

bean id=”transactionManager”

class=”org.springframework.jdbc.datasource.DataSourceTransactionManager”

property name=”dataSource” ref=”dataSource” /

/bean

!– 使用annotation定義事務 —

tx:annotation-driven transaction-manager=”transactionManager” /

在指定代碼處添加事務註解

@Transactional

@Override

public boolean increaseBalanceByLock(Long userId, BigDecimal amount)

throws ValidateException {

long time = System.currentTimeMillis();

//獲取對記錄的鎖定

UserBalance balance = userBalanceDao.getLock(userId);

LOGGER.info(“[lock] start. time: {}”, time);

if (null == balance) {

throw new ValidateException(

ValidateErrorCode.ERRORCODE_BALANCE_NOTEXIST,

“user balance is not exist”);

}

boolean result = userBalanceDao.increaseBalanceByLock(balance, amount);

long timeEnd = System.currentTimeMillis();

LOGGER.info(“[lock] end. time: {}”, timeEnd);

return result;

}

MyBatis中的鎖定方式，實際測試該方法確實可以有效控制，不過在大並發量的情況下，可能會有性能問題吧

select id=”getLock” resultMap=”BaseResultMap” parameterType=”java.lang.Long”

![CDATA[

select * from user_balance where id=#{id,jdbcType=BIGINT} for update;

]]

/select

2、使用樂觀鎖

這個方法也同樣可以解決場景中描述的問題（我認為比較適合併不頻繁的操作）：

設計表的時候增加一個version（版本控制欄位），每次需要更新餘額的時候，先獲取對象，update的時候根據version和id為條件去更新，如果更新回來的數量為0，說明version已經變更

需要重複一次更新操作，如下：sql腳本

update user_balance set Balance = #{balance,jdbcType=DECIMAL},Version = Version+1 where Id = #{id,jdbcType=BIGINT} and Version = #{version,jdbcType=BIGINT}

這是一種不使用資料庫鎖的方法，解決方式也很巧妙。當然，在大量並發的情況下，一次扣款需要重複多次的操作才能成功，還是有不足之處的。不知道還有沒有更好的方法。

用 MySQL 實現分散式鎖，你聽過嗎？

以前參加過一個庫存系統，由於其業務複雜性，搞了很多個應用來支撐。這樣的話一份庫存數據就有可能同時有多個應用來修改庫存數據。

比如說，有定時任務域xx.cron，和SystemA域和SystemB域這幾個JAVA應用，可能同時修改同一份庫存數據。如果不做協調的話，就會有臟數據出現。

對於跨JAVA進程的線程協調，可以藉助外部環境，例如DB或者Redis。下文介紹一下如何使用DB來實現分散式鎖。

本文設計的分散式鎖的交互方式如下：

在使用synchronized關鍵字的時候，必須指定一個鎖對象。

進程內的線程可以基於obj來實現同步。obj在這裡可以理解為一個鎖對象。如果線程要進入synchronized代碼塊里，必須先持有obj對象上的鎖。這種鎖是JAVA裡面的內置鎖，創建的過程是線程安全的。那麼藉助DB，如何保證創建鎖的過程是線程安全的呢？

可以利用DB中的UNIQUE KEY特性，一旦出現了重複的key，由於UNIQUE KEY的唯一性，會拋出異常的。在JAVA裡面，是 SQLIntegrityConstraintViolationException 異常。

transaction_id是事務Id，比如說，可以用

來組裝一個transaction_id，表示某倉庫某銷售模式下的某個條碼資源。不同條碼，當然就有不同的transaction_id。如果有兩個應用，拿著相同的transaction_id來創建鎖資源的時候，只能有一個應用創建成功。

在寫操作頻繁的業務系統中，通常會進行分庫，以降低單資料庫寫入的壓力，並提高寫操作的吞吐量。如果使用了分庫，那麼業務數據自然也都分配到各個資料庫上了。

在這種水平切分的多資料庫上使用DB分散式鎖，可以自定義一個DataSouce列表。並暴露一個 getConnection(String transactionId) 方法，按照transactionId找到對應的Connection。

實現代碼如下：

首先編寫一個initDataSourceList方法，並利用Spring的PostConstruct註解初始化一個DataSource 列表。相關的DB配置從db.properties讀取。

DataSource使用阿里的DruidDataSource。

接著最重要的一個實現getConnection(String transactionId)方法。實現原理很簡單，獲取transactionId的hashcode，並對DataSource的長度取模即可。

連接池列表設計好後，就可以實現往distributed_lock表插入數據了。

接下來利用DB的 select for update 特性來鎖住線程。當多個線程根據相同的transactionId並發同時操作 select for update 的時候，只有一個線程能成功，其他線程都block住，直到 select for update 成功的線程使用commit操作後，block住的所有線程的其中一個線程才能開始幹活。

我們在上面的DistributedLock類中創建一個lock方法。

當線程執行完任務後，必須手動的執行解鎖操作，之前被鎖住的線程才能繼續幹活。在我們上面的實現中，其實就是獲取到當時 select for update 成功的線程對應的Connection，並實行commit操作即可。

那麼如何獲取到呢？我們可以利用ThreadLocal。首先在DistributedLock類中定義

每次調用lock方法的時候，把Connection放置到ThreadLocal裡面。我們修改lock方法。

這樣子，當獲取到Connection後，將其設置到ThreadLocal中，如果lock方法出現異常，則將其從ThreadLocal中移除掉。

有了這幾步後，我們可以來實現解鎖操作了。我們在DistributedLock添加一個unlock方法。

畢竟是利用DB來實現分散式鎖，對DB還是造成一定的壓力。當時考慮使用DB做分散式的一個重要原因是，我們的應用是後端應用，平時流量不大的，反而關鍵的是要保證庫存數據的正確性。對於像前端庫存系統，比如添加購物車佔用庫存等操作，最好別使用DB來實現分散式鎖了。

如果想鎖住多份數據該怎麼實現？比如說，某個庫存操作，既要修改物理庫存，又要修改虛擬庫存，想鎖住物理庫存的同時，又鎖住虛擬庫存。其實也不是很難，參考lock方法，寫一個multiLock方法，提供多個transactionId的入參，for循環處理就可以了。這個後續有時間再補上。