芋道skill在高并发场景下的性能优化实战

2次阅读

没有评论

共计 2148 个字符，预计需要花费 6 分钟才能阅读完成。

在传统单体架构下部署芋道 skill 时，我们观察到当并发请求量超过 2000 QPS 后，系统出现明显性能劣化。通过 Arthas 工具监控发现主要存在以下瓶颈点：

数据库连接池耗尽 ：默认 Druid 配置(maxActive=20) 导致大量请求阻塞在获取数据库连接阶段
线程竞争激烈：同步处理流程中，业务逻辑线程与 I / O 线程存在资源争抢
重复计算开销：热点数据查询未有效缓存，导致数据库负载居高不下
锁粒度不合理：分布式环境下采用粗粒度锁引发线程阻塞

采用多级缓存策略降低数据库压力：

L1 缓存：本地 Caffeine 缓存(最大 10000 条目，过期时间 5 分钟)
L2 缓存：Redis 集群 (6 节点三主三从) 存储序列化后的业务对象
缓存击穿防护：BloomFilter+ 互斥锁双重保障

重构核心业务流程为异步模式：

使用 Disruptor 实现无锁化事件处理
业务日志采用异步 Appender 写入 ES
支付回调等非关键路径改用 MQ 削峰

针对 Druid 连接池的关键参数调整：

# 初始连接数(建议等于核心线程数)
druid.initialSize=10
# 最大活跃连接数(根据 DB 实例配置调整)
druid.maxActive=50
# 获取连接超时时间(毫秒)
druid.maxWait=500
# 空闲连接检测间隔
druid.timeBetweenEvictionRunsMillis=30000

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface CacheEnhance {
    // 缓存 key 前缀
    String prefix() default "";
    // 过期时间(秒)
    int expire() default 300;
    // 是否开启防击穿
    boolean preventBreakdown() default true;}

// AOP 切面实现
@Around("@annotation(cacheEnhance)")
public Object around(ProceedingJoinPoint pjp, CacheEnhance cacheEnhance) {String cacheKey = buildKey(pjp, cacheEnhance.prefix());
    // 布隆过滤器预校验
    if(cacheEnhance.preventBreakdown() && !bloomFilter.mightContain(cacheKey)) {return pjp.proceed();
    }
    // 缓存查询逻辑...
}

@Slf4j
public class AsyncTaskHandler {
    private final RingBuffer<AsyncEvent> ringBuffer;

    public AsyncTaskHandler() {
        Disruptor<AsyncEvent> disruptor = new Disruptor<>(
            AsyncEvent::new, 
            1024, 
            Executors.defaultThreadFactory(),
            ProducerType.MULTI,
            new BlockingWaitStrategy());

        disruptor.handleEventsWith(this::processEvent);
        this.ringBuffer = disruptor.start();}

    private void processEvent(AsyncEvent event, long sequence, boolean endOfBatch) {
        try {event.getTask().run();} catch (Exception e) {log.error("Async task failed", e);
        }
    }
}

使用 JMeter 进行压测(并发用户 5000，持续 10 分钟)：