關(guān)鍵資源

關(guān)鍵資源總是有限的，也就意味著處理能力也有限，所以當面對大量業(yè)務(wù)時，為了保障自己能夠有序的提供服務(wù)最經(jīng)濟的做法就是限制同一時間處理的事務(wù)數(shù)。比如銀行的工作人員，一個工作人員同時只能為一個客戶服務(wù)，來多了根本處理不了,不光是一種浪費而且有可以造成混亂的局面導(dǎo)致工作人員無法工作。

網(wǎng)絡(luò)請求漏斗

越上層的服務(wù)器處理的事務(wù)越輕，應(yīng)付請求的能力也越強，也就意味著同一請求越上層處理時間越短。為了有效的保護下層服務(wù)器，就需要對發(fā)送給下層的請求量做限流，在下層服務(wù)器可接受的范圍內(nèi)。否則就可能會出現(xiàn)下層服務(wù)器資源耗盡而無法正常提供服務(wù)的情況。

限流場景服務(wù)端限流

如果在服務(wù)端做限流，無論有多少個客戶端，總的提供能力是固定的（感謝@ xuanbg提出的評論，指出服務(wù)端也可以對客戶端做精準的判斷，后續(xù)我再想想實現(xiàn)方案），所以不會因為客戶端數(shù)量過多而導(dǎo)致資源不足，因為處理不過來的請求會被阻塞等待獲取資源。

缺點

缺點也比較明顯，由于服務(wù)提供者整體設(shè)置了最大限流數(shù)，此時所有的客戶端共享同一份限流數(shù)據(jù)，那么有可能導(dǎo)致有的服務(wù)能分配到資源有些服務(wù)請求分配不到資源導(dǎo)致無法請求的情況。

客戶端限流

客戶端限流解決上服務(wù)端限流提到的問題，它能保證每個客戶端都能得到響應(yīng)。但是從其它方面考慮，必須針對不同的客戶端做不同的限流策略：

請求量大，但時效性不高，此時將限流數(shù)控制小一些會比較合適請求量大，但時效性高，此時將限流數(shù)適當調(diào)高響應(yīng)時間長，即慢接口，適當降低主流業(yè)務(wù)，核心業(yè)務(wù)，適當調(diào)高非主流業(yè)務(wù)，適當降低......

缺點

如果客戶端的數(shù)量不固定，那么有可能導(dǎo)致客戶端數(shù)量過多造成大量請求打到服務(wù)端導(dǎo)致處理不了的結(jié)果，所以需要嚴格監(jiān)控客戶端的調(diào)用情況。

配置復(fù)雜，需要針對每個客戶端做相對精準的判斷

RPC實現(xiàn)

限流

這里指的限流是指每秒從客戶端提交到服務(wù)端的請求數(shù)量。

服務(wù)引用注解上增加限流

public @interface RpcReference {
  boolean isSync() default true;

  /**
   * 客戶端最大并發(fā)數(shù)
   * @return
   */
  int maxExecutesCount() default 10;
}

創(chuàng)建動態(tài)代理時將限流參數(shù)傳遞到服務(wù)端

需要修改RpcProxy類,構(gòu)造函數(shù)中增加服務(wù)引用注解參數(shù)，然后在invoke方法中從服務(wù)引用注解中獲取限流參數(shù)傳遞給request對象。

public RpcProxy(Class<T> clazz,ReferenceConfig referenceConfig,RpcReference reference) {
    this.clazz = clazz;
    this.referenceConfig=referenceConfig;
    this.reference=reference;
    this.isSync=reference.isSync();
  }

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

    ...

    if (this.reference != null) {
      request.setMaxExecutesCount(this.reference.maxExecutesCount());
    }
    ...
  }

AbstractInvoker修改buildRpcInvocation方法

從request對象中獲取限流參數(shù)，傳遞給RpcInvocation對象。

public interface RpcInvocation {

  ...

  int getMaxExecutesCount();

}

AccessLimitFilter修改令牌管理器

按接口分配令牌管理器，令牌管理器存儲在map中共享。如果未初始化則進行令牌管理器的初始化，如果已經(jīng)初始化則直接申請令牌。

public RpcInvocation buildRpcInvocation(RpcRequest request){
    RpcInvocation rpcInvocation=new RpcInvocation() {
      ...
      @Override
      public int getMaxExecutesCount() {
        return request.getMaxExecutesCount();
      }
    };
    return rpcInvocation;
  }

修改invoke方法

將invocation參數(shù)傳遞給acquire方法。

  public Object invoke(RpcInvoker invoker, RpcInvocation invocation) {
    logger.info("before acquire,"+new Date());
    AccessLimitManager.acquire(invocation);

    Object rpcResponse=invoker.invoke(invocation);
    logger.info("after acquire,"+new Date());
    return rpcResponse;
  }

客戶端服務(wù)引用配置限流

這里配置每秒一個請求

@RpcReference(maxExecutesCount = 1)
private ProductService productService;

執(zhí)行結(jié)果

如下圖所示，每次請求相隔了一秒，達到了限流請求的目的。

支持方法級限流

以上只支持客戶端接口級別的限流配置，可以再單獨創(chuàng)建一個方法級的注解來配置相關(guān)參數(shù)。

支持服務(wù)端限流

服務(wù)端限流盡管有它的缺點，但為了更好的保護服務(wù)提供者，需要結(jié)合多種業(yè)務(wù)場景來配合客戶端限流一起完善，取長補短共同發(fā)揮作用。

本文源碼

https://github.com/jiangmin168168/jim-framework

文中代碼是依賴上述項目的，如果有不明白的可下載源碼

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論