写点什么

dubbo 几个问题整理:优雅停机、线程池配置

发布于: 2021 年 04 月 02 日

一 dubbo 优雅停机

优雅停机,是指当我们关闭 dubbo 时,正在处理中的请求能够正常结束,如果是做服务上线动作,那么希望在上线期间不会有请求发到已经停止的服务上,导致业务方收到大量服务不可用的报错。我们的预期,上线应该是确保平滑的,对使用方来说时无感知的。


解决方法:

1、集成 dubbo monitor

web.xml 中替换 spring 的 org.springframework.web.context.ContextLoaderListener

为:

DubboSpringContainerListener

其他方法,在 spring 容器关闭之前调用 ProtocolConfig.destroyAll();

dubbo 的优雅停机的超时时间为 10 秒,所以检查 tomcat 服务在指定 waitTime 应大于这个 dubbo 的 timeout 时间,使得 dubbo 能够有机会执行关闭,

目前这边的配置 tomcat 超时 kill -9 的 waitTime 为 15 秒。另外在提供方发布的时候建议折半发布,这样可以保证消费可以重试别的 provider

核心:避免过早 kill -9

1、服务能安全停止:正在读或者写的消息,需要继续处理;线程池需等所有任务执行完成后,才关闭;

2、期间不再分配新请求

dubbo 2.5.4 以下版本不支持优雅停机,因为服务端关闭时,客户端主动关闭长连接,导致服务端响应消息不能返回。

在服务端和客户端配置参数:-Ddubbo.service.shutdown.wait=30000,该参数为停机等待时间,但是结果也不生效,还是马上停机了。

二 线程池配置

熟悉 dubbo 的朋友们应该知道,dubbo 的线程池参数,以及默认的线程数(200)。因为 dubbo 的连接模式,根据官方文档描述:

  • 注册中心,服务提供者,服务消费者三者之间均为长连接,监控中心除外

  • 注册中心通过长连接感知服务提供者的存在,服务提供者宕机,注册中心将立即推送事件通知消费者


主要线程配置在 protocol 配置项中 详细见官方文档:thread-model,

threadpool 线程池类型,可选:fixed, cached, limited, eager, 一般配置 cached 就 OK

threads 服务最大线程池,根据上面的计算,来适当配置

iothreads cpu 个数+1 io 线程池大小(固定大小) ,不可优化

accepts 服务提供方最大可接受连接数,默认 0

2、线程池调整思路

1. 根据机器内存调整线程数,根据系统配置,优化 linux 线程核 io 相关 limit,根据 linux 系统可用线程数,适当调整线程数上限;

以单个服务为例: 服务器配置:8c32g 问题:日调用量 2 千万,1 小时内调用量最高的时候 2 百万,配置线程数 500,不够用了,调整思路如下:

<1> 根据给 jvm 分配的内存 调整 线程数,7 个服务 JVM 堆分配的总内存 17G 左右 + JVM 元数据区内存(2G), 剩余 13G -> 13G/1M(线程栈大小)约等于 1.3 万,在去除 tomcat 和系统本身线程数,理论 Java 线程数上限可以达到(所有) 1w 左右,单个服务调整可以按照 1.5 倍或者两倍进行增加调整, 那么园务服务的线程数可以调整到 800 或者 1000

<2> 调整 linux 用户上限线程数

2. Dispatcher 改为: message,或者 connection

message: 只有请求响应消息派发到线程池,其它连接断开事件,心跳等消息,直接在 IO 线程上执行。

connection: 在 IO 线程上,将连接断开事件放入队列,有序逐个执行,其它消息派发到线程池。


发布于: 2021 年 04 月 02 日阅读数: 22
用户头像

磨炼中成长,痛苦中前行 2017.10.22 加入

微信公众号【程序员架构进阶】。多年项目实践,架构设计经验。曲折中向前,分享经验和教训

评论

发布
暂无评论
dubbo几个问题整理:优雅停机、线程池配置