掌握微服務(wù)下分布式鎖的正確姿勢
前言
在Java中，我們對于鎖會比較熟悉，常用的有 synchronized、Lock鎖，在java并發(fā)編程中，我們通過鎖，來實(shí)現(xiàn)當(dāng)多個線程競爭同一個共享資源或者變量而造成的數(shù)據(jù)不一致的問題，但是JVM鎖只能針對于單個應(yīng)用服務(wù)，隨著我們業(yè)務(wù)的發(fā)展需要，單體單機(jī)部署的系統(tǒng)早已演化成分布式系統(tǒng)，由于分布式系統(tǒng)的多線程、多進(jìn)程而且分布在不同的機(jī)器上，這個時(shí)候JVM鎖的并發(fā)控制就沒有效果了，為了解決跨JVM鎖并且能夠控制共享資源的訪問，于是有了分布式鎖的誕生。
什么是分布式鎖
分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式。在分布式系統(tǒng)中，常常需要協(xié)調(diào)他們的動作。如果不同的系統(tǒng)或是同一個系統(tǒng)的不同主機(jī)之間共享了一個或一組資源，那么訪問這些資源的時(shí)候，往往需要互斥來防止彼此干擾來保證一致性，在這種情況下，便需要使用到分布式鎖
為什么JVM鎖在分布式下不可以呢?
我們通過代碼來看一下就知道，為什么集群下jvm鎖是不可靠的呢?我們模擬一下商品搶購的場景，A服務(wù)有十個用戶去搶購這個商品，B服務(wù)有十個用戶去搶購這個商品，當(dāng)有其中一個用戶搶購成功后，其他用戶不可以在對這個商品進(jìn)行下單操作，那么到底是A服務(wù)會搶到還是B服務(wù)會搶到這個商品呢，我們來看一下
當(dāng)其中有一個用戶搶購成功后，status會變成1
GrabService：
- public interface GrabService {
- /**
- * 商品搶單
- * @param orderId
- * @param driverId
- * @return
- */
- public ResponseResult grabOrder(int orderId, int driverId);
- }
GrabJvmLockServiceImpl：
- @Service("grabJvmLockService")
- public class GrabJvmLockServiceImpl implements GrabService {
- @Autowired
- OrderService orderService;
- @Override
- public ResponseResult grabOrder(int orderId, int driverId) {
- String lock = (orderId+"");
- synchronized (lock.intern()) {
- try {
- System.out.println("用戶:"+driverId+" 執(zhí)行下單邏輯");
- boolean b = orderService.grab(orderId, driverId);
- if(b) {
- System.out.println("用戶:"+driverId+" 下單成功");
- }else {
- System.out.println("用戶:"+driverId+" 下單失敗");
- }
- } finally {
- }
- }
- return null;
- }
- }
OrderService :
- public interface OrderService {
- public boolean grab(int orderId, int driverId);
- }
OrderServiceImpl :
- @Service
- public class OrderServiceImpl implements OrderService {
- @Autowired
- private OrderMapper mapper;
- public boolean grab(int orderId, int driverId) {
- Order order = mapper.selectByPrimaryKey(orderId);
- try {
- Thread.sleep(1000);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- if(order.getStatus().intValue() == 0) {
- order.setStatus(1);
- mapper.updateByPrimaryKeySelective(order);
- return true;
- }
- return false;
- }
- }
這里我們模擬集群環(huán)境，啟動兩個端口，8004和8005進(jìn)行訪問這里我們用jmeter進(jìn)行測試如果不會jmeter的可以看我之前對tomcat進(jìn)行壓測的文章：tomcat優(yōu)化
項(xiàng)目啟動順序：先啟動 Server-eureka注冊中心、在啟動 8004和8005端口
測試結(jié)果：
這里我們可以看到 8004 服務(wù)和 8005 服務(wù) 同時(shí)都有一個用戶去下單成功這個商品，但是這個商品只能有一個用戶能夠去搶到，因此jvm鎖如果是在集群或分布式下，是無法保證訪問共享變量的數(shù)據(jù)同時(shí)只有一個線程訪問的，無法解決分布式，集群環(huán)境的問題。所以需要使用到分布鎖。
分布式鎖三種實(shí)現(xiàn)方式
分布式鎖的實(shí)現(xiàn)方式總共有三種：
- 基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
- 基于緩存(Redis)實(shí)現(xiàn)分布式鎖
- 基于Zookeeper實(shí)現(xiàn)分布式鎖今天，我們主要講的是基于Redis實(shí)現(xiàn)的分布式鎖
reids實(shí)現(xiàn)分布式鎖有三種方式
1、基于redis的 SETNX 實(shí)現(xiàn)分布式鎖
2、Redisson實(shí)現(xiàn)分布式鎖
3、使用redLock實(shí)現(xiàn)分布式鎖
目錄結(jié)構(gòu)：
方式一：基于 SETNX 實(shí)現(xiàn)分布式鎖
將key的值設(shè)為value ，當(dāng)且僅當(dāng)key不存在。若給定的key已經(jīng)存在，則SETNX不做任何動作。setnx：當(dāng)key存在，不做任何操作，key不存在，才設(shè)置
加鎖：
- SET orderId driverId NX PX 30000
- 上面的命令如果執(zhí)行成功，則客戶端成功獲取到了鎖，接下來就可以訪問共享資源了；而如果上面的命令執(zhí)行失敗，則說明獲取鎖失敗。
釋放鎖：關(guān)鍵，判斷是不是自己加的鎖。
GrabService ：
- public interface GrabService {
- /**
- * 商品搶單
- * @param orderId
- * @param driverId
- * @return
- */
- public ResponseResult grabOrder(int orderId, int driverId);
- }
GrabRedisLockServiceImpl ：
- @Service("grabRedisLockService")
- public class GrabRedisLockServiceImpl implements GrabService {
- @Autowired
- StringRedisTemplate stringRedisTemplate;
- @Autowired
- OrderService orderService;
- @Override
- public ResponseResult grabOrder(int orderId , int driverId){
- //生成key
- String lock = "order_"+(orderId+"");
- /*
- * 情況一，如果鎖沒執(zhí)行到釋放，比如業(yè)務(wù)邏輯執(zhí)行一半，運(yùn)維重啟服務(wù)，或 服務(wù)器掛了，沒走 finally，怎么辦？
- * 加超時(shí)時(shí)間
- */
- // boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"");
- // if(!lockStatus) {
- // return null;
- // }
- /*
- * 情況二：加超時(shí)時(shí)間,會有加不上的情況，運(yùn)維重啟
- */
- // boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"");
- // stringRedisTemplate.expire(lock.intern(), 30L, TimeUnit.SECONDS);
- // if(!lockStatus) {
- // return null;
- // }
- /*
- * 情況三：超時(shí)時(shí)間應(yīng)該一次加，不應(yīng)該分2行代碼，
- *
- */
- boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"", 30L, TimeUnit.SECONDS);
- if(!lockStatus) {
- return null;
- }
- try {
- System.out.println("用戶:"+driverId+" 執(zhí)行搶單邏輯");
- boolean b = orderService.grab(orderId, driverId);
- if(b) {
- System.out.println("用戶:"+driverId+" 搶單成功");
- }else {
- System.out.println("用戶:"+driverId+" 搶單失敗");
- }
- } finally {
- /**
- * 這種釋放鎖有，可能釋放了別人的鎖。
- */
- // stringRedisTemplate.delete(lock.intern());
- /**
- * 下面代碼避免釋放別人的鎖
- */
- if((driverId+"").equals(stringRedisTemplate.opsForValue().get(lock.intern()))) {
- stringRedisTemplate.delete(lock.intern());
- }
- }
- return null;
- }
- }
這里可能會有人問，如果我業(yè)務(wù)的執(zhí)行時(shí)間超過了鎖釋放的時(shí)間，會怎么辦呢?我們可以使用守護(hù)線程，只要我們當(dāng)前線程還持有這個鎖，到了10S的時(shí)候，守護(hù)線程會自動對該線程進(jìn)行加時(shí)操作，會續(xù)上30S的過期時(shí)間，直到把鎖釋放，就不會在進(jìn)行續(xù)約了，開啟一個子線程，原來時(shí)間是N，每隔N/3，在去續(xù)上N
關(guān)注點(diǎn)：
- key，是我們的要鎖的目標(biāo)，比如訂單ID。
- driverId 是由我們的商品ID，它要保證在足夠長的一段時(shí)間內(nèi)在所有客戶端的所有獲取鎖的請求中都是唯一的。即一個訂單被一個用戶搶。
- NX表示只有當(dāng)orderId不存在的時(shí)候才能SET成功。這保證了只有第一個請求的客戶端才能獲得鎖，而其它客戶端在鎖被釋放之前都無法獲得鎖。
- PX 30000表示這個鎖有一個30秒的自動過期時(shí)間。當(dāng)然，這里30秒只是一個例子，客戶端可以選擇合適的過期時(shí)間。
- 這個鎖必須要設(shè)置一個過期時(shí)間。 否則的話，當(dāng)一個客戶端獲取鎖成功之后，假如它崩潰了，或者由于發(fā)生了網(wǎng)絡(luò)分區(qū)，導(dǎo)致它再也無法和Redis節(jié)點(diǎn)通信了，那么它就會一直持有這個鎖，而其它客戶端永遠(yuǎn)無法獲得鎖了。antirez在后面的分析中也特別強(qiáng)調(diào)了這一點(diǎn)，而且把這個過期時(shí)間稱為鎖的有效時(shí)間(lock validity time)。獲得鎖的客戶端必須在這個時(shí)間之內(nèi)完成對共享資源的訪問。
- 此操作不能分割。>SETNX orderId driverId EXPIRE orderId 30 雖然這兩個命令和前面算法描述中的一個SET命令執(zhí)行效果相同，但卻不是原子的。如果客戶端在執(zhí)行完SETNX后崩潰了，那么就沒有機(jī)會執(zhí)行EXPIRE了，導(dǎo)致它一直持有這個鎖。造成死鎖。
方式二：基于redisson實(shí)現(xiàn)分布式鎖
流程圖：
代碼實(shí)現(xiàn)：
- @Service("grabRedisRedissonService")
- public class GrabRedisRedissonServiceImpl implements GrabService {
- @Autowired
- RedissonClient redissonClient;
- @Autowired
- OrderService orderService;
- @Override
- public ResponseResult grabOrder(int orderId , int driverId){
- //生成key
- String lock = "order_"+(orderId+"");
- RLock rlock = redissonClient.getLock(lock.intern());
- try {
- // 此代碼默認(rèn) 設(shè)置key 超時(shí)時(shí)間30秒，過10秒，再延時(shí)
- rlock.lock();
- System.out.println("用戶:"+driverId+" 執(zhí)行搶單邏輯");
- boolean b = orderService.grab(orderId, driverId);
- if(b) {
- System.out.println("用戶:"+driverId+" 搶單成功");
- }else {
- System.out.println("用戶:"+driverId+" 搶單失敗");
- }
- } finally {
- rlock.unlock();
- }
- return null;
- }
- }
關(guān)注點(diǎn)：
1.redis故障問題。如果redis故障了，所有客戶端無法獲取鎖，服務(wù)變得不可用。為了提高可用性。我們給redis 配置主從。當(dāng)master不可用時(shí)，系統(tǒng)切換到slave，由于Redis的主從復(fù)制(replication)是異步的，這可能導(dǎo)致喪失鎖的安全性
- 1.客戶端1從Master獲取了鎖。2.Master宕機(jī)了，存儲鎖的key還沒有來得及同步到Slave上。3.Slave升級為Master。4.客戶端2從新的Master獲取到了對應(yīng)同一個資源的鎖。
客戶端1和客戶端2同時(shí)持有了同一個資源的鎖。鎖的安全性被打破。
2.鎖的有效時(shí)間(lock validity time)，設(shè)置成多少合適?如果設(shè)置太短的話，鎖就有可能在客戶端完成對于共享資源的訪問之前過期，從而失去保護(hù);如果設(shè)置太長的話，一旦某個持有鎖的客戶端釋放鎖失敗，那么就會導(dǎo)致所有其它客戶端都無法獲取鎖，從而長時(shí)間內(nèi)無法正常工作。應(yīng)該設(shè)置稍微短一些，如果線程持有鎖，開啟線程自動延長有效期
方式三：基于RedLock實(shí)現(xiàn)分布式鎖
針對于以上兩點(diǎn)，antirez設(shè)計(jì)了Redlock算法 Redis的作者antirez給出了一個更好的實(shí)現(xiàn)，稱為Redlock，算是Redis官方對于實(shí)現(xiàn)分布式鎖的指導(dǎo)規(guī)范。Redlock的算法描述就放在Redis的官網(wǎng)上：https://redis.io/topics/distlock
目的：對共享資源做互斥訪問
因此antirez提出了新的分布式鎖的算法Redlock，它基于N個完全獨(dú)立的Redis節(jié)點(diǎn)(通常情況下N可以設(shè)置成5)，意思就是N個Redis數(shù)據(jù)不互通，類似于幾個陌生人
代碼實(shí)現(xiàn)：
- @Service("grabRedisRedissonRedLockLockService")
- public class GrabRedisRedissonRedLockLockServiceImpl implements GrabService {
- @Autowired
- private RedissonClient redissonRed1;
- @Autowired
- private RedissonClient redissonRed2;
- @Autowired
- private RedissonClient redissonRed3;
- @Autowired
- OrderService orderService;
- @Override
- public ResponseResult grabOrder(int orderId , int driverId){
- //生成key
- String lockKey = (RedisKeyConstant.GRAB_LOCK_ORDER_KEY_PRE + orderId).intern();
- //紅鎖
- RLock rLock1 = redissonRed1.getLock(lockKey);
- RLock rLock2 = redissonRed2.getLock(lockKey);
- RLock rLock3 = redissonRed2.getLock(lockKey);
- RedissonRedLock rLock = new RedissonRedLock(rLock1,rLock2,rLock3);
- try {
- rLock.lock();
- // 此代碼默認(rèn) 設(shè)置key 超時(shí)時(shí)間30秒，過10秒，再延時(shí)
- System.out.println("用戶:"+driverId+" 執(zhí)行搶單邏輯");
- boolean b = orderService.grab(orderId, driverId);
- if(b) {
- System.out.println("用戶:"+driverId+" 搶單成功");
- }else {
- System.out.println("用戶:"+driverId+" 搶單失敗");
- }
- } finally {
- rLock.unlock();
- }
- return null;
- }
- }
運(yùn)行Redlock算法的客戶端依次執(zhí)行下面各個步驟，來完成 獲取鎖 的操作：
- 獲取當(dāng)前時(shí)間(毫秒數(shù))。
- 按順序依次向N個Redis節(jié)點(diǎn)執(zhí)行 獲取鎖 的操作。這個獲取操作跟前面基于單Redis節(jié)點(diǎn)的 獲取鎖 的過程相同，包含value driverId ，也包含過期時(shí)間(比如 PX30000 ，即鎖的有效時(shí)間)。為了保證在某個Redis節(jié)點(diǎn)不可用的時(shí)候算法能夠繼續(xù)運(yùn)行，這個 獲取鎖 的操作還有一個超時(shí)時(shí)間(time out)，它要遠(yuǎn)小于鎖的有效時(shí)間(幾十毫秒量級)。
- 客戶端在向某個Redis節(jié)點(diǎn)獲取鎖失敗以后，應(yīng)該立即嘗試下一個Redis節(jié)點(diǎn)。這里的失敗，應(yīng)該包含任何類型的失敗，比如該Redis節(jié)點(diǎn)不可用，或者該Redis節(jié)點(diǎn)上的鎖已經(jīng)被其它客戶端持有
- 計(jì)算整個獲取鎖的過程總共消耗了多長時(shí)間，計(jì)算方法是用當(dāng)前時(shí)間減去第1步記錄的時(shí)間。如果客戶端從大多數(shù)Redis節(jié)點(diǎn)(>= N/2+1)成功獲取到了鎖，比如：五臺機(jī)器如果加鎖成功三臺就默認(rèn)加鎖成功，并且獲取鎖總共消耗的時(shí)間沒有超過鎖的有效時(shí)間(lock validity time)，那么這時(shí)客戶端才認(rèn)為最終獲取鎖成功;否則，認(rèn)為最終獲取鎖失敗
- 如果最終獲取鎖成功了，那么這個鎖的有效時(shí)間應(yīng)該重新計(jì)算，它等于最初的鎖的有效時(shí)間減去第3步計(jì)算出來的獲取鎖消耗的時(shí)間。
- 如果最終獲取鎖失敗了(可能由于獲取到鎖的Redis節(jié)點(diǎn)個數(shù)少于N/2+1，或者整個獲取鎖的過程消耗的時(shí)間超過了鎖的最初有效時(shí)間)，那么客戶端應(yīng)該立即向所有Redis節(jié)點(diǎn)發(fā)起 釋放鎖 的操作(即前面介紹的Redis Lua腳本)。上面描述的只是 獲取鎖 的過程，而 釋放鎖 的過程比較簡單：客戶端向所有Redis節(jié)點(diǎn)發(fā)起 釋放鎖 的操作，不管這些節(jié)點(diǎn)當(dāng)時(shí)在獲取鎖的時(shí)候成功與否。
總結(jié)
到這里redis分布式鎖就講完了，具體使用哪一種類型的分布式鎖需要看公司業(yè)務(wù)的，流量大的可以使用RedLock實(shí)現(xiàn)分布式鎖，流量小的可以使用redisson，后面會講解Zookeeper實(shí)現(xiàn)分布式鎖。
