dubbo中配置优先级规律:方法级配置优先级高于接口级,consumer的优先级高于provider。
详细:
consumer的method配置 > provider的method配置
consumer的reference配置 > provider的service配置
consumer的consumer节点配置 > provider的provider节点配置
本地参数配置优化级:
系统参数(-D),如-Ddubbo.protocol.port > xml配置 > property文件
参数名 | 作用范围 | 默认值 | 说明 | 备注 |
---|---|---|---|---|
actives | consumer | 0 | 每服务消费者每服务每方法最大并发调用数 | 0表示不限制 |
connections | consumer | 对每个提供者的最大连接数,rmi、http、hessian等短连接协议表示限制连接数,dubbo等长连接协表示建立的长连接个数 | dubbo时为1,及复用单链接 | |
accepts | provider | 0 | 服务提供方最大可接受连接数 | 0表示不限制 |
iothreads | provider | cpu个数+1 | io线程池大小(固定大小) | |
threads | provider | 200 | 业务线程池大小(固定大小) | |
executes | provider | 0 | 服务提供者每服务每方法最大可并行执行请求数 | 0表示不限制 |
tps | provider | 指定时间内(默认60s)最大的可执行次数,注意与executes的区别 | 默认不开启 |
1、当consumer发起一个请求时,首先经过active limit(参数actives)进行方法级别的限制,其实现方式为CHM中存放计数器(AtomicInteger),请求时加1,请求完成(包括异常)减1,如果超过actives则等待有其他请求完成后重试或者超时后失败;
2、从多个连接(connections)中选择一个连接发送数据,对于默认的netty实现来说,由于可以复用连接,默认一个连接就可以。不过如果你在压测,且只有一个consumer,一个provider,此时适当的加大connections确实能够增强网络传输能力。但线上业务由于有多个consumer多个provider,因此不建议增加connections参数;
3、连接到达provider时(如dubbo的初次连接),首先会判断总连接数是否超限(acceps),超过限制连接将被拒绝;
4、连接成功后,具体的请求交给io thread处理。io threads虽然是处理数据的读写,但io部分为异步,更多的消耗的是cpu,因此iothreads默认cpu个数+1是比较合理的设置,不建议调整此参数;
5、数据读取并反序列化以后,交给业务线程池处理,默认情况下线程池为fixed,且排队队列为0(queues),这种情况下,最大并发等于业务线程池大小(threads),如果希望有请求的堆积能力,可以调整queues参数。如果希望快速失败由其他节点处理(官方推荐方式),则不修改queues,只调整threads;
6、execute limit(参数executes)是方法级别的并发限制,原理与actives类似,只是少了等待的过程,即受限后立即失败;
7、tps,控制指定时间内(默认60s)的请求数。注意目前dubbo默认没有支持该参数,需要加一个META-INF/dubbo/com.alibaba.dubbo.rpc.Filter文件,文件内容为:
tps=com.alibaba.dubbo.rpc.filter.TpsLimitFilter
如果consumer数*actives>provider数*threads且queues=0,则会存在部分请求无法申请到资源,重试也有很大几率失败。
当需要对一个接口的不同方法进行不同的并发控制时使用executes,否则调整threads就可以。
【转载自:https://blog.csdn.net/youaremoon/article/details/51884644】
dubbo文档:http://alibaba.github.io/dubbo-doc-static/Dubbo+Protocol-zh.htm