zoukankan      html  css  js  c++  java
  • Dubbo线程模型

     

     

      事件处理线程说明

      • 如果事件处理的逻辑能迅速完成,并且不会发起新的IO请求,比如只是在内存中记个标识,则直接在IO线程上处理更快,因为减少了线程池调度。
      • 但如果事件处理逻辑较慢,或者需要发起新的IO请求,比如需要查询数据库,则必须派发到线程池,否则IO线程阻塞,将导致不能接收其它请求。
      • 如果用IO线程处理事件,又在事件处理过程中发起新的IO请求,比如在连接事件中发起登录请求,会报“可能引发死锁”异常,但不会真死锁。
    • Dispatcher

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

      • fixed 固定大小线程池,启动时建立线程,不关闭,一直持有。(缺省)
      • cached 缓存线程池,空闲一分钟自动删除,需要时重建。
      • limited 可伸缩线程池,但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。

    配置如:

    <dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />
    参考链接:http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E7%BA%BF%E7%A8%8B%E6%A8%A1%E5%9E%8B
  • 相关阅读:
    Beta版使用说明
    【每日scrum】NO.7
    【每日scrum】NO.6
    【每日scrum】NO.5
    【每日scrum】NO.4
    【每日scrum】NO.3
    【每日scrum】NO.2
    【每日scrum】NO.1
    运行及总结
    测试与调试
  • 原文地址:https://www.cnblogs.com/shoshana-kong/p/10751350.html
Copyright © 2011-2022 走看看