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]是重叠的，也即是服务器同时并行地接受了两个请求，进一步可以推理出服务器并没有限制连接数。