- 浏览: 83476 次
- 性别:
- 来自: 广州
文章分类
- 全部博客 (110)
- myeclipse JVM 虚拟机内存设置 (1)
- 查询含有clob字段表的sql语句 (1)
- 项目个人价值体现 (1)
- Java多线程并发编程 (1)
- spring (4)
- 启悟 (1)
- hadoop (27)
- mysql数据库乱码问题 (1)
- linux (6)
- 架构与设计 (1)
- java (6)
- mysql (2)
- 分页编程 (1)
- 励志 (2)
- 技术要求 (0)
- guava (1)
- 分布式开发(SOA) (4)
- 微服务架构 + API 网关 (5)
- 消息中间件 (4)
- Dubbo (8)
- 面谈 (0)
- 高并发架构 (1)
- maven (1)
- MongoDB (1)
- hbase (2)
最新评论
消费端调优:
一、connections
这个参数可以在服务提供端发布服务的时候配置,也可以在消费端引用服务的时候配置,但是这个值是只对消费端生效的,所以一般是服务提供端不建议配置,如果配置,请斟酌一下,详情请查看《对connections参数的设置 》。不管是在消费端或者服务提供端,如果对某个服务配置了connections参数,并且该参数大于1,那么就会导致消费端在创建该服务的远程socketclient的时候(如果是dubbo协议的话)将会给该服务初始化一个私有的socketclient。所以一般不建议对这个值进行调整。
服务端优化调整:
相对余消费端,服务端调优的参数相对多一些,但是配置的时候也需要谨慎。
一、executes
这个参数是可以精确到方法级别的参数,就是可以指定调用远程接口某个方法的是该参数的值。具体是怎么配置的可以到官方文档里面去看看那,这里只是描述这个参数实际意义以及使用的时候应该注意点。
要说这个参数,就要所介绍ExecuteLimitFilter,他是这个参数使用者,看到Filter大家就应该懂了,就是在每个方法请求前后加上业务逻辑。下面贴出里面的代码:
[java] view plain copy 在CODE上查看代码片派生到我的代码片
@Activate(group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)
public class ExecuteLimitFilter implements Filter {
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
URL url = invoker.getUrl();
String methodName = invocation.getMethodName();
int max = url.getMethodParameter(methodName, Constants.EXECUTES_KEY, 0);
if (max > 0) {
RpcStatus count = RpcStatus.getStatus(url, invocation.getMethodName());
if (count.getActive() >= max) {
throw new RpcException("Failed to invoke method " + invocation.getMethodName() + " in provider " + url + ", cause: The service using threads greater than <dubbo:service executes=\"" + max + "\" /> limited.");
}
}
long begin = System.currentTimeMillis();
boolean isException = false;
RpcStatus.beginCount(url, methodName);
try {
Result result = invoker.invoke(invocation);
return result;
} catch (Throwable t) {
isException = true;
if(t instanceof RuntimeException) {
throw (RuntimeException) t;
}
else {
throw new RpcException("unexpected exception when ExecuteLimitFilter", t);
}
}
finally {
RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, isException);
}
}
}
上面这段代码主要是看两个地方,分别是第7行和第10行,第7行是获取配置的executes的值,是一个int类型的,描述数量,然后第10行是获取当前请求方法当前的状态,里面既有一个active属性(该属性是AtomacInteger类型的,大家应该懂了为什么用这个类型),表示当前请求的方法处于执行状态的线程数量,如果这个值大于或者等于配置的值那么直接抛出异常,那么消费端就会收到一个RPC的异常导致调用服务失败,这是这个参数最终导致的效果。
二、actives
这个参数基本上和excetes一样,但是有一点不同,在说这不同之前,还是看看另一个Filter,看名字你们应该就知道它是做什么的了—— ActiveLimitFilter,下面同样贴出代码:
[java] view plain copy 在CODE上查看代码片派生到我的代码片
@Activate(group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)
public class ActiveLimitFilter implements Filter {
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
URL url = invoker.getUrl();
String methodName = invocation.getMethodName();
int max = invoker.getUrl().getMethodParameter(methodName, Constants.ACTIVES_KEY, 0);
RpcStatus count = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
if (max > 0) {
long timeout = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.TIMEOUT_KEY, 0);
long start = System.currentTimeMillis();
long remain = timeout;
int active = count.getActive();
if (active >= max) {
synchronized (count) {
while ((active = count.getActive()) >= max) {
try {
count.wait(remain);
} catch (InterruptedException e) {
}
long elapsed = System.currentTimeMillis() - start;
remain = timeout - elapsed;
if (remain <= 0) {
throw new RpcException("Waiting concurrent invoke timeout in client-side for service: "
+ invoker.getInterface().getName() + ", method: "
+ invocation.getMethodName() + ", elapsed: " + elapsed
+ ", timeout: " + timeout + ". concurrent invokes: " + active
+ ". max concurrent invoke limit: " + max);
}
}
}
}
}
try {
long begin = System.currentTimeMillis();
RpcStatus.beginCount(url, methodName);
try {
Result result = invoker.invoke(invocation);
RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, true);
return result;
} catch (RuntimeException t) {
RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, false);
throw t;
}
} finally {
if(max>0){
synchronized (count) {
count.notify();
}
}
}
}
}
上面代码大致上和executes一样,唯一不同的就是多了一个等待时间,当当前执行该方法的线程超出了最大限制,那么可以等待一个timeout时间,如果时间过了还是超出了最大限制,那么就抛出异常。这个相对余executes来说温柔那么点。这就是那点不同!
三、accepts
在看代码之前先看看这个参数的意思,这个参数是告知服务提供端能接收多少个消费端连接该服务提供方。下面接着上代码,这个参数的体现是在类AbstractServer中。代码如下:
要说这个参数,就要所介绍ExecuteLimitFilter,他是这个参数使用者,看到Filter大家就应该懂了,就是在每个方法请求前后加上业务逻辑。下面贴出里面的代码:
[java] view plain copy 在CODE上查看代码片派生到我的代码片
@Override
public void connected(Channel ch) throws RemotingException {
Collection<Channel> channels = getChannels();
if (accepts > 0 && channels.size() > accepts) {
logger.error("Close channel " + ch + ", cause: The server " + ch.getLocalAddress() + " connections greater than max config " + accepts);
ch.close();
return;
}
super.connected(ch);
}
这个方法是每个消费端向服务提供端创建一个socket连接的时候都会触发,上面可以清晰看到如果连接当前服务端的消费端数量超出了配置的值,那么将会关闭当前消费端连接的请求。这个只是对socket连接的数量限制,而不是像上面两个参数对调用线程的配置。
以上归纳出的几个参数建议服务端生效的在服务端配置,消费端生效的在消费端配置,不然会导致一些不可控的现象出现。这也叫改哪里的东西就应该在哪里,而不能乱放。
摘自:http://blog.csdn.net/jdream314/article/details/44590937
一、connections
这个参数可以在服务提供端发布服务的时候配置,也可以在消费端引用服务的时候配置,但是这个值是只对消费端生效的,所以一般是服务提供端不建议配置,如果配置,请斟酌一下,详情请查看《对connections参数的设置 》。不管是在消费端或者服务提供端,如果对某个服务配置了connections参数,并且该参数大于1,那么就会导致消费端在创建该服务的远程socketclient的时候(如果是dubbo协议的话)将会给该服务初始化一个私有的socketclient。所以一般不建议对这个值进行调整。
服务端优化调整:
相对余消费端,服务端调优的参数相对多一些,但是配置的时候也需要谨慎。
一、executes
这个参数是可以精确到方法级别的参数,就是可以指定调用远程接口某个方法的是该参数的值。具体是怎么配置的可以到官方文档里面去看看那,这里只是描述这个参数实际意义以及使用的时候应该注意点。
要说这个参数,就要所介绍ExecuteLimitFilter,他是这个参数使用者,看到Filter大家就应该懂了,就是在每个方法请求前后加上业务逻辑。下面贴出里面的代码:
[java] view plain copy 在CODE上查看代码片派生到我的代码片
@Activate(group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)
public class ExecuteLimitFilter implements Filter {
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
URL url = invoker.getUrl();
String methodName = invocation.getMethodName();
int max = url.getMethodParameter(methodName, Constants.EXECUTES_KEY, 0);
if (max > 0) {
RpcStatus count = RpcStatus.getStatus(url, invocation.getMethodName());
if (count.getActive() >= max) {
throw new RpcException("Failed to invoke method " + invocation.getMethodName() + " in provider " + url + ", cause: The service using threads greater than <dubbo:service executes=\"" + max + "\" /> limited.");
}
}
long begin = System.currentTimeMillis();
boolean isException = false;
RpcStatus.beginCount(url, methodName);
try {
Result result = invoker.invoke(invocation);
return result;
} catch (Throwable t) {
isException = true;
if(t instanceof RuntimeException) {
throw (RuntimeException) t;
}
else {
throw new RpcException("unexpected exception when ExecuteLimitFilter", t);
}
}
finally {
RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, isException);
}
}
}
上面这段代码主要是看两个地方,分别是第7行和第10行,第7行是获取配置的executes的值,是一个int类型的,描述数量,然后第10行是获取当前请求方法当前的状态,里面既有一个active属性(该属性是AtomacInteger类型的,大家应该懂了为什么用这个类型),表示当前请求的方法处于执行状态的线程数量,如果这个值大于或者等于配置的值那么直接抛出异常,那么消费端就会收到一个RPC的异常导致调用服务失败,这是这个参数最终导致的效果。
二、actives
这个参数基本上和excetes一样,但是有一点不同,在说这不同之前,还是看看另一个Filter,看名字你们应该就知道它是做什么的了—— ActiveLimitFilter,下面同样贴出代码:
[java] view plain copy 在CODE上查看代码片派生到我的代码片
@Activate(group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)
public class ActiveLimitFilter implements Filter {
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
URL url = invoker.getUrl();
String methodName = invocation.getMethodName();
int max = invoker.getUrl().getMethodParameter(methodName, Constants.ACTIVES_KEY, 0);
RpcStatus count = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
if (max > 0) {
long timeout = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.TIMEOUT_KEY, 0);
long start = System.currentTimeMillis();
long remain = timeout;
int active = count.getActive();
if (active >= max) {
synchronized (count) {
while ((active = count.getActive()) >= max) {
try {
count.wait(remain);
} catch (InterruptedException e) {
}
long elapsed = System.currentTimeMillis() - start;
remain = timeout - elapsed;
if (remain <= 0) {
throw new RpcException("Waiting concurrent invoke timeout in client-side for service: "
+ invoker.getInterface().getName() + ", method: "
+ invocation.getMethodName() + ", elapsed: " + elapsed
+ ", timeout: " + timeout + ". concurrent invokes: " + active
+ ". max concurrent invoke limit: " + max);
}
}
}
}
}
try {
long begin = System.currentTimeMillis();
RpcStatus.beginCount(url, methodName);
try {
Result result = invoker.invoke(invocation);
RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, true);
return result;
} catch (RuntimeException t) {
RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, false);
throw t;
}
} finally {
if(max>0){
synchronized (count) {
count.notify();
}
}
}
}
}
上面代码大致上和executes一样,唯一不同的就是多了一个等待时间,当当前执行该方法的线程超出了最大限制,那么可以等待一个timeout时间,如果时间过了还是超出了最大限制,那么就抛出异常。这个相对余executes来说温柔那么点。这就是那点不同!
三、accepts
在看代码之前先看看这个参数的意思,这个参数是告知服务提供端能接收多少个消费端连接该服务提供方。下面接着上代码,这个参数的体现是在类AbstractServer中。代码如下:
要说这个参数,就要所介绍ExecuteLimitFilter,他是这个参数使用者,看到Filter大家就应该懂了,就是在每个方法请求前后加上业务逻辑。下面贴出里面的代码:
[java] view plain copy 在CODE上查看代码片派生到我的代码片
@Override
public void connected(Channel ch) throws RemotingException {
Collection<Channel> channels = getChannels();
if (accepts > 0 && channels.size() > accepts) {
logger.error("Close channel " + ch + ", cause: The server " + ch.getLocalAddress() + " connections greater than max config " + accepts);
ch.close();
return;
}
super.connected(ch);
}
这个方法是每个消费端向服务提供端创建一个socket连接的时候都会触发,上面可以清晰看到如果连接当前服务端的消费端数量超出了配置的值,那么将会关闭当前消费端连接的请求。这个只是对socket连接的数量限制,而不是像上面两个参数对调用线程的配置。
以上归纳出的几个参数建议服务端生效的在服务端配置,消费端生效的在消费端配置,不然会导致一些不可控的现象出现。这也叫改哪里的东西就应该在哪里,而不能乱放。
摘自:http://blog.csdn.net/jdream314/article/details/44590937
发表评论
-
使用Hystrix对Dubbo消费者提供线程隔离保护
2016-11-12 00:36 1496在dubbo中对于消费者的 ... -
基于Dubbo的跨主机容器通信遇到的问题
2016-11-11 14:01 1432最近在项目中使用到Docker和Dubbo,想在Docker中 ... -
dubbo协议下的单一长连接与多线程并发如何协同工作
2016-11-10 16:57 0上班的路上突然就冒出了这么个问题:既然在dubbo中描述消费者 ... -
redis + dubbo 高并发出现的问题及其解决思路
2016-11-10 16:02 0dubbo报错问题解决,最终发现是redis process执 ... -
dubbo服务中的hessian序列化工厂使用hashmap加锁在高并发场景下的问题
2016-11-10 15:49 1160[摘要:1.题目描绘 我们 ... -
DUBBO配置规则详解
2016-11-10 15:03 351研究DUBBO也已经大半年 ... -
dubbo学习与常遇问题汇总
2016-11-10 12:45 388dubbo学习与常遇问题汇总 http://www.cnblo ... -
Dubbo架构设计详解(清楚深入,值得研读)
2016-11-10 12:40 498Dubbo是Alibaba开源的分布式服务框架,它最大的特点是 ... -
dubbo接口添加白名单——dubbo Filter的使用
2016-11-10 00:51 1822在开发中,有时候需要限制访问的权限,白名单就是一种方法。对于J ...
相关推荐
dubbo服务并发控制(executes),连接控制(accepts),路由规则测试,服务降级。 具体请参考:https://dubbo.gitbooks.io/dubbo-user-book/
dubbo入门helloworld例子,使用maven构建,下载后可以直接导入工程运行
基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统 基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统 基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统 基于SpringBoot+...
SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zipSpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zipSpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zipSpringBoot+Zookeeper+Dubbo...
主要介绍了springboot+dubbo+validation 进行rpc参数校验的实现方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
dubbo资源 dubbo-admin dubbo demo
基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zip基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zip基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zip基于SpringBoot...
1.dubbo-zookeeper springSpringMVC 一个生产者,多消费者 例子 2. ssm-dubbo 源码 ssm-tomcat 里放的是 warbao ,程序包 zookeeper-3.4.9 zookeeper 免安装包 设置都是默认的 zookeeper 端口 2181 dubbo-...
Dubbo是阿里巴巴开源的分布式服务化治理框架(微服务框架),久经阿里巴巴电商平台的大规模复杂业务的高并发考验,到目前为止Dubbo仍然是开源界中体系最完善的服务化治理框架,因此Dubbo被国内大量的的互联网公司和...
Dubbo分布式服务架构,对于研究大型Web服务器的并发技术的同学们有帮助。
本项目需要安装Nacos,并启动Nacos,然后启动两个子项目,根据http:localhost/wife/clean,观看到网页显示...这几个注解不能忘,否则会报错,或者达不到预计效果,对于此项目的部分ERROR如果不影响运行,则不需要要注意
dubbo示例代码dubbo-sample
incubator-dubbo-dubbo-2.6.1
前段时间排查某问题的时候,想要快速知道某些dubbo接口(三无)的响应结果,但不想启动项目(因为这些项目不是你负责的,不会部署而且超级笨重),也不想新建一个dubbo客户端项目(占地方),也不想开telnet客户端...
dubbo是目前分布式系统开发里面使用非常多的一个RPC框架。本套视频从分布式系统的基本概念出发,由浅入深,讲解了RPC原理,Dubbo基本使用,Dubbo高可用场景以及Dubbo原理,涉及了分布式系统中服务注册、服务发现、...
dubbo资源包
首先,从知识层面对Dubbo有一个了解和认识,请看《Dubbo培训与实战.pptx》,然后把Dubbo用到实际项目中来,请看实例代码《Dubbo实例代码(Sping+Dubbo+Maven).zip》,里面包括dubboDemoProvide和dubboDemoConsumer...
使用dubbo架构的第一个例子
dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.dubbo源码解析2.
SpringBoot+Dubbo构建的电商平台-微服务架构、商城、电商、微服务、高并发、kafka、Elasticsearch