mysql居然還能實現(xiàn)分布式鎖的方法

前言

之前的文章中通過電商場景中秒殺的例子和大家分享了單體架構(gòu)中鎖的使用方式，但是現(xiàn)在很多應用系統(tǒng)都是相當龐大的，很多應用系統(tǒng)都是微服務的架構(gòu)體系，那么在這種跨jvm的場景下，我們又該如何去解決并發(fā)。

單體應用鎖的局限性

在進入實戰(zhàn)之前簡單和大家粗略聊一下互聯(lián)網(wǎng)系統(tǒng)中的架構(gòu)演進。

在互聯(lián)網(wǎng)系統(tǒng)發(fā)展之初，消耗資源比較小，用戶量也比較小，我們只部署一個tomcat應用就可以滿足需求。一個tomcat我們可以看做是一個jvm的進程，當大量的請求并發(fā)到達系統(tǒng)時，所有的請求都落在這唯一的一個tomcat上，如果某些請求方法是需要加鎖的，比如上篇文章中提及的秒殺扣減庫存的場景，是可以滿足需求的。但是隨著訪問量的增加，一個tomcat難以支撐，這時候我們就需要集群部署tomcat，使用多個tomcat支撐起系統(tǒng)。

在上圖中簡單演化之后，我們部署兩個Tomcat共同支撐系統(tǒng)。當一個請求到達系統(tǒng)的時候，首先會經(jīng)過nginx，由nginx作為負載均衡，它會根據(jù)自己的負載均衡配置策略將請求轉(zhuǎn)發(fā)到其中的一個tomcat上。當大量的請求并發(fā)訪問的時候，兩個tomcat共同承擔所有的訪問量。這之后我們同樣進行秒殺扣減庫存的時候，使用單體應用鎖，還能滿足需求么？

之前我們所加的鎖是JDK提供的鎖，這種鎖在單個jvm下起作用，當存在兩個或者多個的時候，大量并發(fā)請求分散到不同tomcat，在每個tomcat中都可以防止并發(fā)的產(chǎn)生，但是多個tomcat之間，每個Tomcat中獲得鎖這個請求，又產(chǎn)生了并發(fā)。從而扣減庫存的問題依舊存在。這就是單體應用鎖的局限性。那我們?nèi)绻鉀Q這個問題呢？接下來就要和大家分享分布式鎖了。

分布式鎖

什么是分布式鎖？

那么什么是分布式鎖呢，在說分布式鎖之前我們看到單體應用鎖的特點就是在一個jvm進行有效，但是無法跨越jvm以及進程。所以我們就可以下一個不那么官方的定義，分布式鎖就是可以跨越多個jvm，跨越多個進程的鎖，像這樣的鎖就是分布式鎖。

設(shè)計思路

由于tomcat是java啟動的，所以每個tomcat可以看成一個jvm，jvm內(nèi)部的鎖無法跨越多個進程。所以我們實現(xiàn)分布式鎖，只能在這些jvm外去尋找，通過其他的組件來實現(xiàn)分布式鎖。

上圖兩個tomcat通過第三方的組件實現(xiàn)跨jvm，跨進程的分布式鎖。這就是分布式鎖的解決思路。

實現(xiàn)方式

那么目前有哪些第三方組件來實現(xiàn)呢？目前比較流行的有以下幾種：

• 數(shù)據(jù)庫，通過數(shù)據(jù)庫可以實現(xiàn)分布式鎖，但是高并發(fā)的情況下對數(shù)據(jù)庫的壓力比較大，所以很少使用。
• Redis，借助redis可以實現(xiàn)分布式鎖，而且redis的java客戶端種類很多，所以使用方法也不盡相同。
• Zookeeper，也可以實現(xiàn)分布式鎖，同樣zk也有很多java客戶端，使用方法也不同。

針對上述實現(xiàn)方式，老貓還是通過具體的代碼例子來一一演示。

基于數(shù)據(jù)庫的分布式鎖

思路：基于數(shù)據(jù)庫悲觀鎖去實現(xiàn)分布式鎖，用的主要是select ... for update。select ... for update是為了在查詢的時候就對查詢到的數(shù)據(jù)進行了加鎖處理。當用戶進行這種行為操作的時候，其他線程是禁止對這些數(shù)據(jù)進行修改或者刪除操作，必須等待上個線程操作完畢釋放之后才能進行操作，從而達到了鎖的效果。

實現(xiàn)：我們還是基于電商中超賣的例子和大家分享代碼。

咱們還是利用上次單體架構(gòu)中的超賣的例子和大家分享，針對上次的代碼進行改造，我們新鍵一張表，叫做distribute_lock，這張表的目的主要是為了提供數(shù)據(jù)庫鎖，我們來看一下這張表的情況。

由于我們這邊模擬的是訂單超賣的場景，所以在上圖中我們有一條訂單的鎖數(shù)據(jù)。

我們將上一篇中的代碼改造一下抽取出一個controller然后通過postman去請求調(diào)用，當然后臺是啟動兩個jvm進行操作，分別是8080端口以及8081端口。完成之后的代碼如下：

/**
 * @author kdaddy@163.com
 * @date 2021/1/3 10:48
 * @desc 公眾號“程序員老貓”
 */
@Service
@Slf4j
public class MySQLOrderService {
  @Resource
  private KdOrderMapper orderMapper;
  @Resource
  private KdOrderItemMapper orderItemMapper;
  @Resource
  private KdProductMapper productMapper;
  @Resource
  private DistributeLockMapper distributeLockMapper;
  //購買商品id
  private int purchaseProductId = 100100;
  //購買商品數(shù)量
  private int purchaseProductNum = 1;
  
  @Transactional(propagation = Propagation.REQUIRED)
  public Integer createOrder() throws Exception{
    log.info("進入了方法");
    DistributeLock lock = distributeLockMapper.selectDistributeLock("order");
    if(lock == null) throw new Exception("該業(yè)務分布式鎖未配置");
    log.info("拿到了鎖");
    //此處為了手動演示并發(fā)，所以我們暫時在這里休眠1分鐘
    Thread.sleep(60000);

    KdProduct product = productMapper.selectByPrimaryKey(purchaseProductId);
    if (product==null){
      throw new Exception("購買商品："+purchaseProductId+"不存在");
    }
    //商品當前庫存
    Integer currentCount = product.getCount();
    log.info(Thread.currentThread().getName()+"庫存數(shù)"+currentCount);
    //校驗庫存
    if (purchaseProductNum > currentCount){
      throw new Exception("商品"+purchaseProductId+"僅剩"+currentCount+"件，無法購買");
    }

    //在數(shù)據(jù)庫中完成減量操作
    productMapper.updateProductCount(purchaseProductNum,"kd",new Date(),product.getId());
    //生成訂單
    ...次數(shù)省略，源代碼可以到老貓的github下載：https://github.com/maoba/kd-distribute
    return order.getId();
  }
}

SQL的寫法如下：

select
  *
  from distribute_lock
  where business_code = #{business_code,jdbcType=VARCHAR}
  for update

以上為主要實現(xiàn)邏輯，關(guān)于代碼中的注意點：

• createOrder方法必須要有事務，因為只有在事務存在的情況下才能觸發(fā)select for update的鎖。
• 代碼中必須要對當前鎖的存在性進行判斷，如果為空的情況下，會報異常

我們來看一下最終運行的效果，先看一下console日志，

8080的console日志情況：

11:49:41  INFO 16360 --- [nio-8080-exec-2] c.k.d.service.MySQLOrderService          : 進入了方法
11:49:41  INFO 16360 --- [nio-8080-exec-2] c.k.d.service.MySQLOrderService          : 拿到了鎖

8081的console日志情況：

11:49:48  INFO 17640 --- [nio-8081-exec-2] c.k.d.service.MySQLOrderService          : 進入了方法

通過日志情況，兩個不同的jvm，由于第一個到8080的請求優(yōu)先拿到了鎖，所以8081的請求就處于等待鎖釋放才會去執(zhí)行，這說明我們的分布式鎖生效了。
再看一下完整執(zhí)行之后的日志情況：

8080的請求：

11:58:01  INFO 15380 --- [nio-8080-exec-1] c.k.d.service.MySQLOrderService          : 進入了方法
11:58:01  INFO 15380 --- [nio-8080-exec-1] c.k.d.service.MySQLOrderService          : 拿到了鎖
11:58:07  INFO 15380 --- [nio-8080-exec-1] c.k.d.service.MySQLOrderService          : http-nio-8080-exec-1庫存數(shù)1

8081的請求：

11:58:03  INFO 16276 --- [nio-8081-exec-1] c.k.d.service.MySQLOrderService          : 進入了方法
11:58:08  INFO 16276 --- [nio-8081-exec-1] c.k.d.service.MySQLOrderService          : 拿到了鎖
11:58:14  INFO 16276 --- [nio-8081-exec-1] c.k.d.service.MySQLOrderService          : http-nio-8081-exec-1庫存數(shù)0
11:58:14 ERROR 16276 --- [nio-8081-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.Exception: 商品100100僅剩0件，無法購買] with root cause

java.lang.Exception: 商品100100僅剩0件，無法購買
 at com.kd.distribute.service.MySQLOrderService.createOrder(MySQLOrderService.java:61) ~[classes/:na]

很明顯第二個請求由于沒有庫存，導致最終購買失敗的情況，當然這個場景也是符合我們正常的業(yè)務場景的。最終我們數(shù)據(jù)庫的情況是這樣的：

很明顯，我們到此數(shù)據(jù)庫的庫存和訂單數(shù)量也都正確了。到此我們基于數(shù)據(jù)庫的分布式鎖實戰(zhàn)演示完成，下面我們來歸納一下如果使用這種鎖，有哪些優(yōu)點以及缺點。

• 優(yōu)點：簡單方便、易于理解、易于操作。
• 缺點：并發(fā)量大的時候?qū)?shù)據(jù)庫的壓力會比較大。
• 建議：作為鎖的數(shù)據(jù)庫和業(yè)務數(shù)據(jù)庫分開。

寫在最后

對于上述數(shù)據(jù)庫分布式鎖，其實在我們的日常開發(fā)中用的也是比較少的。基于redis以及zk的鎖倒是用的比較多一些，本來老貓想把redis鎖以及zk鎖放在這一篇中一起分享掉，但是再寫在同一篇上面的話，篇幅就顯得過長了，因此本篇就和大家分享這一種分布式鎖。源碼大家可以在老貓的github中下載到。地址是：https://github.com/maoba/kd-distribute

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