dubbo之启动检查，集群容错，负载均衡，线程模型(三)

下面所有的标签都是在xml中和Spring整合的，关于注解，api等请前往dubbo官网
这里挑了一些自我感觉重要的，全的请前往dubbo官网

1、启动时检查

服务接口启动不检查(默认都是true)

<dubbo:reference interface="com.foo.BarService" check="false" />

(服务端)关闭所有服务的启动时检查

<dubbo:consumer check="false" />

关闭注册中心启动时检查 (注册订阅失败时报错)：

<dubbo:registry check="false" />

2、集群容错模式

失败自动切换，当出现失败，重试其它服务器 。
通常用于读操作，但重试会带来更长延迟
服务端

<dubbo:service retries="2" />

客户端

<dubbo:reference retries="2" />

3、负载均衡

缺省为随机调用(random)

随机策略：

1. radom:默认，按权重设置随机概率
2. roundrobin ：按公约后的权重设置轮询比例
3. leastactive：相同活跃数的随机，越活跃接收的请求越多
4. consistenthash：一致性hash，相同参数请求总是发到同一提供者

标签的配置
有两种，一种是端级别的，另一种是方法级别的
服务端

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端方法级别

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

客户端方法级别

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

4、线程模型

主要是根据自己的业务模型来决定是选择IO线程还是线程池

两种选择的场景：

1. IO线程：事件逻辑能迅速完成，并不会引发新的IO请求，减少线程池的调用
2. 线程池：处理逻辑慢，或者需要发起新的IO请求，则必须发送到线程池，要不引发阻塞就不好了

看下面这张图

就知道用的肯定是设置在服务端的

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

标签里的参数解释看下面

Dispatcher

• all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
• direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
• message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool

• fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
• cached 缓存线程池，空闲一分钟自动删除，需要时重建。
• limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
• eager
  优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)