2021-02-17 分類: 網(wǎng)站建設(shè)
前言
在一個(gè)高并發(fā)系統(tǒng)中對(duì)流量的把控是非常重要的,當(dāng)巨大的流量直接請(qǐng)求到我們的服務(wù)器上沒(méi)多久就可能造成接口不可用,不處理的話甚至?xí)斐烧麄€(gè)應(yīng)用不可用。
比如最近就有個(gè)這樣的需求,我作為客戶端要向kafka生產(chǎn)數(shù)據(jù),而kafka的消費(fèi)者則再源源不斷的消費(fèi)數(shù)據(jù),并將消費(fèi)的數(shù)據(jù)全部請(qǐng)求到web服務(wù)器,雖說(shuō)做了負(fù)載(有4臺(tái)web服務(wù)器)但業(yè)務(wù)數(shù)據(jù)的量也是巨大的,每秒鐘可能有上萬(wàn)條數(shù)據(jù)產(chǎn)生。如果生產(chǎn)者直接生產(chǎn)數(shù)據(jù)的話極有可能把web服務(wù)器拖垮。
對(duì)此就必須要做限流處理,每秒鐘生產(chǎn)一定限額的數(shù)據(jù)到kafka,這樣就能極大程度的保證web的正常運(yùn)轉(zhuǎn)。
其實(shí)不管處理何種場(chǎng)景,本質(zhì)都是降低流量保證應(yīng)用的高可用。
常見(jiàn)算法
對(duì)于限流常見(jiàn)有兩種算法:
漏桶算法比較簡(jiǎn)單,就是將流量放入桶中,漏桶同時(shí)也按照一定的速率流出,如果流量過(guò)快的話就會(huì)溢出(漏桶并不會(huì)提高流出速率)。溢出的流量則直接丟棄。
如下圖所示:
這種做法簡(jiǎn)單粗暴。
漏桶算法雖說(shuō)簡(jiǎn)單,但卻不能應(yīng)對(duì)實(shí)際場(chǎng)景,比如突然暴增的流量。
這時(shí)就需要用到令牌桶算法:
令牌桶會(huì)以一個(gè)恒定的速率向固定容量大小桶中放入令牌,當(dāng)有流量來(lái)時(shí)則取走一個(gè)或多個(gè)令牌。當(dāng)桶中沒(méi)有令牌則將當(dāng)前請(qǐng)求丟棄或阻塞。
相比之下令牌桶可以應(yīng)對(duì)一定的突發(fā)流量。
RateLimiter實(shí)現(xiàn)
對(duì)于令牌桶的代碼實(shí)現(xiàn),可以直接使用Guava包中的RateLimiter。
- @Override
- public BaseResponse<UserResVO> getUserByFeignBatch(@RequestBody UserReqVO userReqVO) {
- //調(diào)用遠(yuǎn)程服務(wù)
- OrderNoReqVO vo = new OrderNoReqVO() ;
- vo.setReqNo(userReqVO.getReqNo());
- RateLimiter limiter = RateLimiter.create(2.0) ;
- //批量調(diào)用
- for (int i = 0 ;i< 10 ; i++){
- double acquire = limiter.acquire();
- logger.debug("獲取令牌成功!,消耗=" + acquire);
- BaseResponse<OrderNoResVO> orderNo = orderServiceClient.getOrderNo(vo);
- logger.debug("遠(yuǎn)程返回:"+JSON.toJSONString(orderNo));
- }
- UserRes userRes = new UserRes() ;
- userRes.setUserId(123);
- userRes.setUserName("張三");
- userRes.setReqNo(userReqVO.getReqNo());
- userRes.setCode(StatusEnum.SUCCESS.getCode());
- userRes.setMessage("成功");
- return userRes ;
- }
詳見(jiàn)此。
調(diào)用結(jié)果如下:
代碼可以看出以每秒向桶中放入兩個(gè)令牌,請(qǐng)求一次消耗一個(gè)令牌。所以每秒鐘只能發(fā)送兩個(gè)請(qǐng)求。按照?qǐng)D中的時(shí)間來(lái)看也確實(shí)如此(返回值是獲取此令牌所消耗的時(shí)間,差不多也是每500ms一個(gè))。
使用RateLimiter有幾個(gè)值得注意的地方:
允許先消費(fèi),后付款,意思就是它可以來(lái)一個(gè)請(qǐng)求的時(shí)候一次性取走幾個(gè)或者是剩下所有的令牌甚至多取,但是后面的請(qǐng)求就得為上一次請(qǐng)求買單,它需要等待桶中的令牌補(bǔ)齊之后才能繼續(xù)獲取令牌。
總結(jié)
針對(duì)于單個(gè)應(yīng)用的限流 RateLimiter 夠用了,如果是分布式環(huán)境可以借助 Redis 來(lái)完成。
來(lái)做演示。
在 Order 應(yīng)用提供的接口中采取了限流。首先是配置了限流工具的 Bean:
- @Configuration
- public class RedisLimitConfig {
- @Value("${redis.limit}")
- private int limit;
- @Autowired
- private JedisConnectionFactory jedisConnectionFactory;
- @Bean
- public RedisLimit build() {
- RedisClusterConnection clusterConnection = jedisConnectionFactory.getClusterConnection();
- JedisCluster jedisCluster = (JedisCluster) clusterConnection.getNativeConnection();
- RedisLimit redisLimit = new RedisLimit.Builder<>(jedisCluster)
- .limit(limit)
- .build();
- return redisLimit;
- }
- }
接著在 Controller 使用組件:
- @Autowired
- private RedisLimit redisLimit ;
- @Override
- @CheckReqNo
- public BaseResponse<OrderNoResVO> getOrderNo(@RequestBody OrderNoReqVO orderNoReq) {
- BaseResponse<OrderNoResVO> res = new BaseResponse();
- //限流
- boolean limit = redisLimit.limit();
- if (!limit){
- res.setCode(StatusEnum.REQUEST_LIMIT.getCode());
- res.setMessage(StatusEnum.REQUEST_LIMIT.getMessage());
- return res ;
- }
- res.setReqNo(orderNoReq.getReqNo());
- if (null == orderNoReq.getAppId()){
- throw new SBCException(StatusEnum.FAIL);
- }
- OrderNoResVO orderNoRes = new OrderNoResVO() ;
- orderNoRes.setOrderId(DateUtil.getLongTime());
- res.setCode(StatusEnum.SUCCESS.getCode());
- res.setMessage(StatusEnum.SUCCESS.getMessage());
- res.setDataBody(orderNoRes);
- return res ;
- }
為了方便使用,也提供了注解:
- @Override
- @ControllerLimit
- public BaseResponse<OrderNoResVO> getOrderNoLimit(@RequestBody OrderNoReqVO orderNoReq) {
- BaseResponse<OrderNoResVO> res = new BaseResponse();
- // 業(yè)務(wù)邏輯
- return res ;
- }
該注解攔截了 http 請(qǐng)求,會(huì)再請(qǐng)求達(dá)到閾值時(shí)直接返回。
普通方法也可使用:
- @CommonLimit
- public void doSomething(){}
會(huì)在調(diào)用達(dá)到閾值時(shí)拋出異常。
為了模擬并發(fā),在 User 應(yīng)用中開(kāi)啟了 10 個(gè)線程調(diào)用 Order(限流次數(shù)為5) 接口(也可使用專業(yè)的并發(fā)測(cè)試工具 JMeter 等)。
- @Override
- public BaseResponse<UserResVO> getUserByFeign(@RequestBody UserReqVO userReq) {
- //調(diào)用遠(yuǎn)程服務(wù)
- OrderNoReqVO vo = new OrderNoReqVO();
- vo.setAppId(1L);
- vo.setReqNo(userReq.getReqNo());
- for (int i = 0; i < 10; i++) {
- executorService.execute(new Worker(vo, orderServiceClient));
- }
- UserRes userRes = new UserRes();
- userRes.setUserId(123);
- userRes.setUserName("張三");
- userRes.setReqNo(userReq.getReqNo());
- userRes.setCode(StatusEnum.SUCCESS.getCode());
- userRes.setMessage("成功");
- return userRes;
- }
- private static class Worker implements Runnable {
- private OrderNoReqVO vo;
- private OrderServiceClient orderServiceClient;
- public Worker(OrderNoReqVO vo, OrderServiceClient orderServiceClient) {
- this.vo = vo;
- this.orderServiceClient = orderServiceClient;
- }
- @Override
- public void run() {
- BaseResponse<OrderNoResVO> orderNo = orderServiceClient.getOrderNoCommonLimit(vo);
- logger.info("遠(yuǎn)程返回:" + JSON.toJSONString(orderNo));
- }
- }
為了驗(yàn)證分布式效果啟動(dòng)了兩個(gè) Order 應(yīng)用。
效果如下:
實(shí)現(xiàn)原理
實(shí)現(xiàn)原理其實(shí)很簡(jiǎn)單。既然要達(dá)到分布式全局限流的效果,那自然需要一個(gè)第三方組件來(lái)記錄請(qǐng)求的次數(shù)。
其中 Redis 就非常適合這樣的場(chǎng)景。
Lua 腳本如下:
--lua 下標(biāo)從 1 開(kāi)始-- 限流 keylocal key = KEYS[1]-- 限流大小local limit = tonumber(ARGV[1])-- 獲取當(dāng)前流量大小local curentLimit = tonumber(redis.call('get', key) or "0")if curentLimit + 1 > limit then -- 達(dá)到限流大小 返回 return 0;else -- 沒(méi)有達(dá)到閾值 value + 1 redis.call("INCRBY", key, 1) redis.call("EXPIRE", key, 2) return curentLimit + 1end
Java 中的調(diào)用邏輯:
- --lua 下標(biāo)從 1 開(kāi)始
- -- 限流 key
- local key = KEYS[1]
- -- 限流大小
- local limit = tonumber(ARGV[1])
- -- 獲取當(dāng)前流量大小
- local curentLimit = tonumber(redis.call('get', key) or "0")
- if curentLimit + 1 > limit then
- -- 達(dá)到限流大小 返回
- return 0;
- else
- -- 沒(méi)有達(dá)到閾值 value + 1
- redis.call("INCRBY", key, 1)
- redis.call("EXPIRE", key, 2)
- return curentLimit + 1
- end
所以只需要在需要限流的地方調(diào)用該方法對(duì)返回值進(jìn)行判斷即可達(dá)到限流的目的。
當(dāng)然這只是利用 Redis 做了一個(gè)粗暴的計(jì)數(shù)器,如果想實(shí)現(xiàn)類似于上文中的令牌桶算法可以基于 Lua 自行實(shí)現(xiàn)。
Builder 構(gòu)建器
在設(shè)計(jì)這個(gè)組件時(shí)想盡量的提供給使用者清晰、可讀性、不易出錯(cuò)的 API。
比如第一步,如何構(gòu)建一個(gè)限流對(duì)象。
最常用的方式自然就是構(gòu)造函數(shù),如果有多個(gè)域則可以采用重疊構(gòu)造器的方式:
- public A(){}
- public A(int a){}
- public A(int a,int b){}
缺點(diǎn)也是顯而易見(jiàn)的:如果參數(shù)過(guò)多會(huì)導(dǎo)致難以閱讀,甚至如果參數(shù)類型一致的情況下客戶端顛倒了順序,但不會(huì)引起警告從而出現(xiàn)難以預(yù)測(cè)的結(jié)果。
第二種方案可以采用 JavaBean 模式,利用 setter 方法進(jìn)行構(gòu)建:
- A a = new A();
- a.setA(a);
- a.setB(b);
這種方式清晰易讀,但卻容易讓對(duì)象處于不一致的狀態(tài),使對(duì)象處于線程不安全的狀態(tài)。
所以這里采用了第三種創(chuàng)建對(duì)象的方式,構(gòu)建器:
標(biāo)題名稱:分布式限流,你想知道的都在這里
URL網(wǎng)址:http://www.rwnh.cn/news15/101365.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站導(dǎo)航、網(wǎng)頁(yè)設(shè)計(jì)公司、定制網(wǎng)站、App設(shè)計(jì)、建站公司、關(guān)鍵詞優(yōu)化
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容