最近在进行cube.js优化的时候碰到了此问题,实际上后边经过查看官方文档,官方也说明了次问题
主要的原因
redis 并发连接配置的(但是不简单是这样的,经过测试在极端情况下如果连接池可用连接不够的时候会出现整个服务都不可用的问题)
官方的解决方法
结合自己实际的用户查询请求配置连接池
- 参考配置
CUBEJS_REDIS_POOL_MAX=2000
CUBEJS_REDIS_POOL_MIN=50
REDIS_URL=redis://127.0.0.1:6379 // 参考连接,具体可以结合ioredis以及redis 客户端
- 一个参考优化配置
合理的还是尽量别触发最大连接数,经过压力测试,在一些极端情况下容易出现连接被用满之后,整个服务都不用的(哪怕之后连接释放)
具体是cube.js 基于generic-pool的连接池对于资源每次检查释放数,推荐次数可以是经过配置的,可以尽快释放,规避不可用造成服务不能
用
packages/cubejs-query-orchestrator/src/orchestrator/RedisPool.ts
const opts = {
min,
max,
acquireTimeoutMillis: 5000,
idleTimeoutMillis: 3000,
numTestsPerEvictionRun:300, // 可以通过配置解决
evictionRunIntervalMillis: 5000
};
说明
短期内解决方法还是使用较大的连接池数, 后期多进行下压测,同时看看能否添加配置到官方代码中
参考资料
https://cube.dev/docs/deployment/production-checklist
https://github.com/coopernurse/node-pool