概述

互聯(lián)網(wǎng)應用發(fā)展到今天，從單體應用架構到SOA以及今天的微服務，隨著微服務化的不斷升級進化，服務和服務之間的穩(wěn)定性變得越來越重要，分布式系統(tǒng)之所以復雜，主要原因是分布式系統(tǒng)需要考慮到網(wǎng)絡的延時和不可靠，微服務很重要的一個特質就是需要保證服務冪等，保證冪等性很重要的前提需要分布式鎖控制并發(fā)，同時緩存、降級和限流是保護微服務系統(tǒng)運行穩(wěn)定性的三大利器。

隨著業(yè)務不斷的發(fā)展，按業(yè)務域的劃分子系統(tǒng)越來越多，每個業(yè)務系統(tǒng)都需要緩存、限流、分布式鎖、冪等工具組件，distributed-tools組件(暫未開源)正式包含了上述分布式系統(tǒng)所需要的基礎功能組件。

distributed-tools組件基于tair、redis分別提供了2個springboot starter，使用起來非常簡單。 以使用緩存使用redis為例，application.properties添加如下配置

redis.extend.hostName=127.0.0.1 redis.extend.port=6379 redis.extend.password=pwdcode redis.extend.timeout=10000 redis.idempotent.enabled=true

接下來的篇幅，重點會介紹一下緩存、限流、分布式鎖、冪等的使用方式。

緩存

緩存的使用可以說無處不在，從應用請求的訪問路徑來看，用戶user -> 瀏覽器緩存 -> 反向代理緩存-> WEB服務器緩存 -> 應用程序緩存 -> 數(shù)據(jù)庫緩存等，幾乎每條鏈路都充斥著緩存的使用，緩存最直白的解釋就是“用空間換時間”的算法。緩存就是把一些數(shù)據(jù)暫時存放于某些地方，可能是內(nèi)存，也有可能硬盤。總之，目的就是為了避免某些耗時的操作。我們常見的耗時的操作，比如數(shù)據(jù)庫的查詢、一些數(shù)據(jù)的計算結果，或者是為了減輕服務器的壓力。其實減輕壓力也是因查詢或計算，雖然短耗時，但操作很頻繁，累加起來也很長，造成嚴重排隊等情況，服務器抗不住。

distributed-tools組件提供了一個CacheEngine接口，基于Tair、Redis分別有不同的實現(xiàn)，具體CacheEngine定義如下：

public?String?get(String?key); ????/** ?????*?獲取指定的key對應的對象,異常也會返回null ?????*? ?????*?@param?key ?????*?@param?clazz ?????*?@return ?????*/ ????public??T?get(String?key,?Class?clz); ????/** ?????*?存儲緩存數(shù)據(jù),忽略過期時間 ?????*? ?????*?@param?key ?????*?@param?value ?????*?@return ?????*/ ????public??boolean?put(String?key,?T?value); ????/** ?????*?存儲緩存數(shù)據(jù) ?????*? ?????*?@param?key ?????*?@param?value ?????*?@param?expiredTime ?????*?@param?unit ?????*?@return ?????*/ ????public??boolean?put(String?key,?T?value,?int?expiredTime,?TimeUnit?unit); ????/** ?????*?基于key刪除緩存數(shù)據(jù) ?????*? ?????*?@param?key ?????*?@return ?????*/ ????public?boolean?invalid(String?key);

get方法針對key進行查詢，put存儲緩存數(shù)據(jù)，invalid刪除緩存數(shù)據(jù)。

限流

在分布式系統(tǒng)中，尤其面對一些秒殺、瞬時高并發(fā)場景，都需要進行一些限流措施，保證系統(tǒng)的高可用。通常來說限流的目的是通過對并發(fā)訪問/請求進行限速，或者一個時間窗口內(nèi)的的請求進行限速來保護系統(tǒng)，一旦達到限制速率則可以 拒絕服務（定向到錯誤頁或告知資源沒有了）、排隊 或 等待（比如秒殺、評論、下單）、降級（返回托底數(shù)據(jù)或默認數(shù)據(jù)，如商品詳情頁庫存默認有貨）。

常見的一些限流算法包括固定窗口、滑動窗口、漏桶、令牌桶，distributed-tools組件目前基于計數(shù)器只實現(xiàn)了固定窗口算法，具體使用方式如下：

/** ?????*?指定過期時間自增計數(shù)器，默認每次+1，非滑動窗口 ?????*? ?????*?@param?key?計數(shù)器自增key ?????*?@param?expireTime?過期時間 ?????*?@param?unit??時間單位 ?????*?@return ?????*/ ????public?long?incrCount(String?key,?int?expireTime,?TimeUnit?unit); ????/** ?????*?指定過期時間自增計數(shù)器,單位時間內(nèi)超過最大值rateThreshold返回true，否則返回false ?????*? ?????*?@param?key?限流key ?????*?@param?rateThreshold?限流閾值 ?????*?@param?expireTime?固定窗口時間 ?????*?@param?unit?時間單位 ?????*?@return ?????*/ ????public?boolean?rateLimit(final?String?key,?final?int?rateThreshold,?int?expireTime,?TimeUnit?unit);

基于CacheEngine的rateLimit方法可以實現(xiàn)限流，expireTime只能設定固定窗口時間，非滑動窗口時間。 另外distributed-tools組件提供了模板RateLimitTemplate可以簡化限流的易用性，可以直接調(diào)用RateLimitTemplate的execute方法處理限流問題。

/** ?????*?@param?limitKey?限流KEY ?????*?@param?resultSupplier?回調(diào)方法 ?????*?@param?rateThreshold?限流閾值 ?????*?@param?limitTime?限制時間段 ?????*?@param?blockDuration?阻塞時間段 ?????*?@param?unit?時間單位 ?????*?@param?errCodeEnum?指定限流錯誤碼 ?????*?@return ?????*/ ????public??T?execute(String?limitKey,?Supplier?resultSupplier,?long?rateThreshold,?long?limitTime, ?????????????????????????long?blockDuration,?TimeUnit?unit,?ErrCodeEnum?errCodeEnum)?{ ????????boolean?blocked?=?tryAcquire(limitKey,?rateThreshold,?limitTime,?blockDuration,?unit); ????????if?(errCodeEnum?!=?null)?{ ????????????AssertUtils.assertTrue(blocked,?errCodeEnum); ????????}?else?{ ????????????AssertUtils.assertTrue(blocked,?ExceptionEnumType.ACQUIRE_LOCK_FAIL); ????????} ????????return?resultSupplier.get(); ????}

另外distributed-tools組件還提供了注解@RateLimit的使用方式，具體注解RateLimit定義如下：

@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) @Documented public?@interface?RateLimit?{ ????/** ?????*?限流KEY ?????*/ ????String?limitKey(); ????/** ?????*?允許訪問的次數(shù)，默認值MAX_VALUE ?????*/ ????long?limitCount()?default?Long.MAX_VALUE; ????/** ?????*?時間段 ?????*/ ????long?timeRange(); ????/** ?????*?阻塞時間段 ?????*/ ????long?blockDuration(); ????/** ?????*?時間單位，默認為秒 ?????*/ ????TimeUnit?timeUnit()?default?TimeUnit.SECONDS; }

基于注解的方式限流使用代碼如下：

@RateLimit(limitKey?=?"#key",?limitCount?=?5,?timeRange?=?2,?blockDuration?=?3,?timeUnit?=?TimeUnit.MINUTES) public?String?testLimit2(String?key)?{ ????.......... ????return?key; }

任何方法添加上述注解具備了一定的限流能力(具體方法需要在spring aop指定攔截范圍內(nèi))，如上代碼表示以參數(shù)key作為限流key，每2分鐘請求次數(shù)不超過5次，超過限制后阻塞3分鐘。

分布式鎖

在Java單一進程中通過synchronized關鍵字和ReentrantLock可重入鎖可以實現(xiàn)在多線程環(huán)境中控制對資源的并發(fā)訪問，通常本地的加鎖往往不能滿足我們的需要，我們更多的面對場景是分布式系統(tǒng)跨進程的鎖，簡稱為分布式鎖。分布式鎖實現(xiàn)手段通常是將鎖標記存在內(nèi)存中，只是該內(nèi)存不是某個進程分配的內(nèi)存而是公共內(nèi)存如Redis、Tair，至于利用數(shù)據(jù)庫、文件等做鎖與單機的實現(xiàn)是一樣的，只要保證標記能互斥就行。分布式鎖相對單機進程的鎖之所以復雜，主要原因是分布式系統(tǒng)需要考慮到網(wǎng)絡的延時和不可靠。

distributed-tools組件提供的分布式鎖要具備如下特性：互斥性:同本地鎖一樣具有互斥性，但是分布式鎖需要保證在不同節(jié)點進程的不同線程的互斥。可重入性:同一個節(jié)點上的同一個線程如果獲取了鎖之后那么也可以再次獲取這個鎖。鎖超時:和本地鎖一樣支持鎖超時，防止死鎖，通過異步心跳demon線程刷新過期時間，防止特殊場景(如FGC死鎖超時)下死鎖。高性能、高可用:加鎖和解鎖需要高性能，同時也需要保證高可用防止分布式鎖失效，可以增加降級。支持阻塞和非阻塞:同ReentrantLock一樣支持lock和trylock以及tryLock(long timeOut)。公平鎖和非公平鎖(不支持):公平鎖是按照請求加鎖的順序獲得鎖，非公平鎖就相反是無序的，目前distributed-tools組件提供的分布式鎖不支持該特性。

distributed-tools組件提供的分布式鎖，使用起來非常簡單，提供了一個分布式鎖模板：DistributedLockTemplate，可以直接調(diào)用模板提供的靜態(tài)方法(如下)：

/** ?????*?分布式鎖處理模板執(zhí)行器 ?????*? ?????*?@param?lockKey?分布式鎖key ?????*?@param?resultSupplier?分布式鎖處理回調(diào) ?????*?@param?waitTime?鎖等待時間 ?????*?@param?unit?時間單位 ?????*?@param?errCodeEnum?指定特殊錯誤碼返回 ?????*?@return ?????*/ ????public?static??T?execute(String?lockKey,?Supplier?resultSupplier,?long?waitTime,?TimeUnit?unit, ????????????????????????????????ErrCodeEnum?errCodeEnum)?{ ????????AssertUtils.assertTrue(StringUtils.isNotBlank(lockKey),?ExceptionEnumType.PARAMETER_ILLEGALL); ????????boolean?locked?=?false; ????????Lock?lock?=?DistributedReentrantLock.newLock(lockKey); ????????try?{ ????????????locked?=?waitTime?>?0???lock.tryLock(waitTime,?unit)?:?lock.tryLock(); ????????}?catch?(InterruptedException?e)?{ ????????????throw?new?RuntimeException(String.format("lock?error,lockResource:%s",?lockKey),?e); ????????} ????????if?(errCodeEnum?!=?null)?{ ????????????AssertUtils.assertTrue(locked,?errCodeEnum); ????????}?else?{ ????????????AssertUtils.assertTrue(locked,?ExceptionEnumType.ACQUIRE_LOCK_FAIL); ????????} ????????try?{ ????????????return?resultSupplier.get(); ????????}?finally?{ ????????????lock.unlock(); ????????} ????}

冪等

在分布式系統(tǒng)設計中冪等性設計中十分重要的，尤其在復雜的微服務中一套系統(tǒng)中包含了多個子系統(tǒng)服務，而一個子系統(tǒng)服務往往會去調(diào)用另一個服務，而服務調(diào)用服務無非就是使用RPC通信或者restful，分布式系統(tǒng)中的網(wǎng)絡延時或中斷是避免不了的，通常會導致服務的調(diào)用層觸發(fā)重試。具有這一性質的接口在設計時總是秉持這樣的一種理念：調(diào)用接口發(fā)生異常并且重復嘗試時，總是會造成系統(tǒng)所無法承受的損失，所以必須阻止這種現(xiàn)象的發(fā)生。

冪等通常會有兩個維度： 1. 空間維度上的冪等，即冪等對象的范圍，是個人還是機構，是某一次交易還是某種類型的交易。 2. 時間維度上的冪等，即冪等的保證時間，是幾個小時、幾天還是永久性的。

在實際系統(tǒng)中有很多操作，不管操作多少次，都應該產(chǎn)生一樣的效果或返回相同的結果。以下這些應用場景也是通常比較常見的應用場景： 1. 前端重復提交請求，且請求數(shù)據(jù)相同時，后臺需要返回對應這個請求的相同結果。 2. 發(fā)起一次支付請求，支付中心應該只扣用戶賬戶一次錢，當遇到網(wǎng)絡中斷或系統(tǒng)異常時，也應該只扣一次錢。 3. 發(fā)送消息，同樣內(nèi)容的短信發(fā)給用戶只發(fā)一次。 4. 創(chuàng)建業(yè)務訂單，一次業(yè)務請求只能創(chuàng)建一個，重試請求創(chuàng)建多個就會出大問題。 5. 基于msgId的消息冪等處理

在正式使用distributed-tools組件提供的冪等之前，我們先看下distributed-tools冪等組件的設計。

冪等key提取能力：獲取唯一冪等key冪等key的提取支持2中注解：IdempotentTxId、IdempotentTxIdGetter，任意方法添加以上2注解，即可提取到相關冪等key，前提條件是需要將Idempotent注解添加相關需要冪等的方法上。

如果單純使用冪等模板進行業(yè)務處理，需要自己設置相關冪等key，且要保證其唯一性。

分布式鎖服務能力：提供全局加鎖、解鎖的能力distributed-tools冪等組件需要使用自身提供的分布式鎖功能，保證其并發(fā)唯一性，distributed-tools提供的分布式鎖能夠提供其可靠、穩(wěn)定的加鎖、解鎖能力。

高性能的寫入、查詢能力：針對冪等結果查詢與存儲distributed-tools冪等組件提供了基于tair、redis的存儲實現(xiàn)，同時支持自定義一級、二級存儲通過spring依賴注入到IdempotentService，建議distributed-tools冪等存儲結果一級存儲tair mdb，二級存儲ldb或者tablestore，一級存儲保證其高性能，二級存儲保證其可靠性。

二級存儲并行查詢會返回查詢最快的冪等結果。 二級存儲并行異步寫入，進一步提高性能。

高可用的冪等寫入、查詢能力：冪等存儲出現(xiàn)異常，不影響業(yè)務正常流程，增加容錯distributed-tools冪等組件支持二級存儲，為了保證其高可用，畢竟二級存儲出現(xiàn)故障的概率太低，不會導致業(yè)務上不可用，如果二級存儲同時出現(xiàn)故障，業(yè)務上做了一定的容錯，針對不確定性的異常采取重試策略，會執(zhí)行具體冪等方法。

一級存儲與二級存儲的寫入與查詢處理進行隔離，任何一級存儲的異常不會影響整體業(yè)務執(zhí)行。

在了解了distributed-tools組件冪等之后，接下來我們來看下如何去使用冪等組件，首先了解下common-api提供的冪等注解,具體冪等注解使用方式如下：

注解定義使用范圍使用描述Idempotent方法Idempotent需要定義到具體Method上。Idempotent有個屬性定義：

expireDate表示冪等有效期，默認30天。

spelKey表示可以使用spring表達式生成冪等唯一ID，比如直接獲取到對象屬性或者方法或者其他表達式。IdempotentTxId參數(shù)、對象屬性IdempotentTxId可以直接定義到方法參數(shù)或者參數(shù)對象屬性上,直接獲取冪等IDIdempotentTxIdGetter方法IdempotentTxIdGetter可以直接定義參數(shù)對象的方法上，調(diào)用該方法獲取冪等ID

冪等攔截器獲取冪等ID的優(yōu)先級：

首先判斷Idempotent的spelKey的屬性是否為空，如果不為空會根據(jù)spelKey定義的spring表達式生成冪等ID。

其次判斷參數(shù)是否包含IdempotentTxId注解，如果有IdempotentTxId，會直接獲取參數(shù)值生成冪等ID。

再次通過反射獲取參數(shù)對象屬性是否包含IdempotentTxId注解，如果對象屬性包含IdempotentTxId注解會獲取該參數(shù)對象屬性生成冪等ID。

最后以上三種情況仍未獲取到冪等ID，會進一步通過反射獲取參數(shù)對象的Method是否定義IdempotentTxIdGetter注解，如果包含該注解則通過反射生成冪等ID。

代碼使用示例：

@Idempotent(spelKey?=?"#request.requestId",?firstLevelExpireDate?=?7，secondLevelExpireDate?=?30) ????public?void?execute(BizFlowRequest?request)?{ ???????.................. ????}

如上述代碼表示從request獲取requestId作為冪等key，一級存儲有效期7天，二級存儲有效期30天。

distributed-tools除了可以使用冪等注解外，冪等組件還提供了一個通用冪等模板IdempotentTemplate，使用冪等模板的前提必須設置tair.idempotent.enabled=true或者redis.idempotent.enabled=true，默認為false，同時需要指定冪等結果一級存儲，冪等結果存儲為可選項配置。 具體使用冪等模板IdempotentTemplate的方法如下：

/** ?????*?冪等模板處理器 ?????* ?????*?@param?request?冪等Request信息 ?????*?@param?executeSupplier?冪等處理回調(diào)function ?????*?@param?resultPreprocessConsumer?冪等結果回調(diào)function?可以對結果做些預處理 ?????*?@param?ifResultNeedIdempotence?除了根據(jù)異常還需要根據(jù)結果判定是否需要冪等性的場景可以提供此參數(shù) ?????*?@return ?????*/ ????public?R?execute(IdempotentRequest

?request,?Supplier?executeSupplier, ?????????????????????Consumer>?resultPreprocessConsumer,?Predicate?ifResultNeedIdempotence)?{ ??????........ ????}

request：冪等參數(shù)IdempotentRequest組裝，可以設置冪等參數(shù)和冪等唯一ID

executeSupplier：具體冪等的方法邏輯，比如針對支付、下單接口，可以通過JDK8函數(shù)式接口Supplier Callback進行處理。

resultBiConsumer：冪等返回結果的處理，該參數(shù)可以為空，如果為空采取默認的處理，根據(jù)冪等結果，如果成功、不可重試的異常錯誤碼，直接返回結果，如果失敗可重試異常錯誤碼，會進行重試處理。 如果該參數(shù)值不為空，可以針對返回冪等結果進行特殊邏輯處理設置ResultStatus(ResultStatus包含三種狀態(tài)包括成功、失敗可重試、失敗不可重試)。