tomcat 集群监控与弹性伸缩详解

Madeleine ·

更新时间:2024-11-10

· 608 次阅读

如何给 tomcat 配置合适的线程池

如何监控 tomcat 线程池的工作情况

tomcat 线程池扩缩容

tomcat 是如何避免原生线程池的缺陷的

如何给 tomcat 配置合适的线程池

任务分为 CPU 密集型和 IO 密集型

对于 CPU 密集型的应用来说，需要大量 CPU 计算速度很快，线程池如果过多，则保存和切换上下文开销过高反而会影响性能，可以适当将线程数量调小一些

对于 IO 密集型应用来说常见于普通的业务系统，比如会去查询 mysql、redis 等然后在内存中做简单的数据组装和逻辑判断，此时由于有 epoll、dma 等支持，消耗较长时间的线程不会长时间占据 CPU 时间，所以可以适当将线程数量调大一些

对于线程数到底该设置多大，网上有很多的方案

我们在实际情况中基于 wrk 等压测工具进行压测，压测逻辑相对复杂请求量相对较高的接口先配置一个相对保守的值

先预估假设当前接口处理平均耗时 300MS，1S 一个线程平均处理 3 个请求，最大 100 个线程 1S 能处理 300 TPS

粗略估算每个请求会消耗多大的内容空间，假如是 2KB，那么每秒会消耗 600KB 以此来估算 YGC 多久会触发一次，假设年轻代为 1GB 那么大约 29 分钟触发一次 YGC

然后再看 100 个线程持续处理 300TPS 的时候 CPU 消耗情况

观察内存几分钟 GC 一次，或者 CPU 使用率稳定在 50% 左右就好，假设此时线程池 70 个线程都在运作

那么监控系统采集到线程池线程使用率达到了 80% 就开始扩容，因为扩容拉起新的服务器到提供服务可能也需要1-2分钟的时间，所以需要预留服务器资源能够处理弹性扩容期间的流量

实际场景中是相对比较复杂的，前期最好设置一个相对保守的扩容阈值，如果发现在达到这个阈值前服务器已经顶不住了就可以实时的缩小阈值

同时还可以根据在达到扩容阈值扩容的时候，观察线上真实的 CPU 和内存使用情况，可以基于 promethues + grafana 来进行监控，如果发现扩容时候 CPU 使用率和内存使用率 GC 评率比较低，那么可以再配置中心动态的调整线程池的大小

所以说与其寻找一个准确的计算线程池数量的配置方式，不如提供一个可以动态调整的线程池作为 tomcat 的线程池

如何监控 tomcat 线程池的工作情况

spring boot 在启动过程中会调用 TomcatProtocolHandlerCustomizer 的实现类，此处可以自定化 tomcat 线程池，也可以获取到 tomcat 线程池

public class MyTomcatProtocolHandlerCustomizer implements TomcatProtocolHandlerCustomizer<ProtocolHandler> {
    private final ThreadPoolExecutor tomcatThreadPoolExecutor;
    public TomcatProtocolHandlerCustomizer(ThreadPoolExecutor tomcatThreadPoolExecutor) {
        this.tomcatThreadPoolExecutor = tomcatThreadPoolExecutor;
    }
    @Override
    public void customize(ProtocolHandler protocolHandler) {
        protocolHandler.setExecutor(tomcatThreadPoolExecutor);
    }
    public ThreadPoolExecutor getThreadPoolExecutor() {
        return tomcatThreadPoolExecutor;
    }
}

然后将线程池装入一个容器 bean 中注册到 promethues 监控中，当每秒进行采集的时候通过回调的方法去获取线程池的最新指标

promethues 每秒采集一次容器的线程池运行指标、服务器测 CPU 使用率当满足定义的扩容阈值时就拉起新的 POD

grafana 每秒采集一次 promethues 的数据汇聚图标展示

@Bean
public AllServersThreadPoolCollector allServersThreadPoolCollector(@Qualifier(value = "GrpcThreadPoolExecutor") ThreadPoolExecutor GrpcThreadPoolExecutor,
                                                                   @Qualifier(value = "jdTomcatThreadPoolExecutor") org.apache.tomcat.util.threads.ThreadPoolExecutor TomcatThreadPoolExecutor,
                                                                   MeterRegistry registry) {
    return new AllServersThreadPoolCollector(GrpcThreadPoolExecutor, jdTomcatThreadPoolExecutor, registry);
}

public void init() {
    try {
        createGauge(this, "grpc_tomcat_core_pool_size", pool -&gt; this.getCorePoolSize());
        createGauge(this, "grpc_tomcat_maximum_pool_size", pool -&gt; this.getMaximumPoolSize());
        createGauge(this, "grpc_tomcat_busy_pool_size", pool -&gt; this.getActiveCount());
        createGauge(this, "grpc_tomcat_wait_queue_size", pool -&gt; this.getWaitQueueSize());
    } catch (Exception e) {
        log.error("注册 all servers 监控失败", e);
    }
}
private void createGauge(AllServersThreadPoolCollector weakRef, String metric, ToDoubleFunction&lt;AllServersThreadPoolCollector&gt; measure) {
    Gauge.builder(metric, weakRef, measure)
            .register(this.registry);
}
public int getWaitQueueSize() {
    return grpcThreadPoolExecutor.getQueue().size() + tomcatThreadPoolExecutor.getQueue().size();
}

tomcat 线程池扩缩容

Java 线程池是支持直接修改 corePoolSize、maximumPoolSize 的

修改 corePoolSize

（1）数量小于 maximumPoolSize 抛异常

（2）如果 corePoolSize - 原来的 = delta，delta 大于 0 那么创建等待队列任务数量和 delta 个线程来处理等待处理的任务

（3）如果正在运行的线程数量 > corePoolSize 那么就中断多余的线程

修改 maximumPoolSize

（1）maximumPoolSize 小于 corePoolSize 抛错

（2）如果运行的线程大于 maximumPoolSize 中断掉一些空闲的线程

基于这些机制就能在运行期间动态调整线程池内容

无需担心会中断掉正在运行的任务，因为线程池 worker 线程每执行一个任务的时候

tomcat 是如何避免原生线程池的缺陷的