Dubbo（二）限流之connections參數

在實際的生產環境中，我們不能假設服務端的能力是無窮大的，能接入任意數量的連接，接受任意數量的請求都是不實際的想法。我們在實現服務時都會考慮到一些上限，比如最大連接數，最大請求數。connections參數隸屬於dubbo::service標簽，按照官方文檔的說法：“對每個提供者的最大連接數，rmi、http、hessian等短連接協議表示限制連接數，dubbo等長連接協表示建立的長連接個數”，可以看出它在限制某處連接數量的，那么我們就寫程序看看此參數效果是怎樣的吧。

完整代碼在 https://github.com/ralgond/dubbo-example/releases/tag/v0.0.4

首先修改下provider的配置，在dubbo::service標簽中添加connections="1", 結果如下：

<dubbo:service interface="com.github.ralgond.de.sdk.GreetingService" ref="greetingService" group="dubbo" version="0.0.1" 
    	timeout="30000" connections="1"/>

修改provider中的GreetingServiceImpl為

public class GreetingServiceImpl implements GreetingService {

	@Override
	public String sayHello(String name) {
		return "Hello "+name+" "+RpcContext.getContext().getAttachment("company");
	}

	@Override
	public String sleepMs(long ms) {
		try {
			Thread.sleep(ms);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		return "sleep done";
	}

}

增加類ApiSleepConsumer：

public class ApiSleepConsumer {
	public static void main(String args[]) {
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("consumer.xml");
		context.start();
		
		GreetingService service = (GreetingService)context.getBean("greetingService");
		
		long begin = System.currentTimeMillis();
		System.out.println(""+begin+" "+service.sleepMs(3000));
		long end = System.currentTimeMillis();
		System.out.println(""+end+ " done sleep: "+(end - begin)+"ms");
	}
}

快速地啟動兩個運行ApiSleepConsumer的進程，得到兩組結果：

1604912607942 sleep done
1604912611038 done sleep: 3096ms

以及

1604912607961 sleep done
1604912611051 done sleep: 3090ms

可以看出兩個時間段[1604912607.942,1604912611.038]和[1604912607.961,1604912611.051]是重疊的，也即是服務器同時並行地接受了兩個請求，進一步可以推理出服務器並沒有限制連接數。