[Day 17] - 『转职工作的Lessons learned』 - Cube.js / Redis TimeoutError

今天要继续讲转职工作使用到的工具以及遇到的一些问题及处理方式。

公司的专案在制作图表有使用到Cube.js这个工具，这应该是很多使用javascript开发网页，有图表需求的APP会使用到的工具。

极简介绍Cube.js架构

（上图摘录之官网）

由上图所示，一个典型的 Cube.js 生产集群由一个或多个 API 实例、一个 Refresh Worker、Redis 和一个 Cube Store 集群组成。

Cube.js && Redis

在使用这项工具开发时，有出现过图表跑不出来，画面出现TimeoutError: ResourceRequest timed out的问题。仔细去查询了Cube.js的Doc之後发现，是因为在使用Cube.js时搭配使用的Redis所造成。

Redis用於管理队列(queue)和查询级缓存(query-level cache)。

在Cube.js在连线Redis有一些额外参数设定可以设定Redis Pool
CUBEJS_REDIS_URL提供 Cube.js，默认情况下将创建一个最少 2 个，最多 1000 个并发连接的 Redis 连接池，而CUBEJS_REDIS_POOL_MIN和CUBEJS_REDIS_POOL_MAX环境变量可以用来调整池的大小限制。

TimeoutError: ResourceRequest timed out

造成原因应是来自redis pool的设定

解法是将CUBEJS_REDIS_POOL_MAX和CUBEJS_REDIS_POOL_MIN设大一点，避免连接池不够用。

If your maximum concurrent connections limit is too low, you may see TimeoutError: ResourceRequest timed out errors. As a rule of a thumb, you need to have Queue Size * Number of tenants concurrent connections to ensure the best performance possible. If you use clustered deployments, please make sure you have enough connections for all Cube.js server instances. A lower number of connections still can work, however Redis becomes a performance bottleneck in this case.(摘录自cube.js)
(翻译：如果您的最大并发连接限制太低，您可能会看到 TimeoutError: ResourceRequest timed out错误。根据经验，您需要有Queue Size * Number of tenants并发连接以确保可能的最佳性能。如果您使用集群部署，请确保您有足够的连接用於所有 Cube.js 服务器实例。较少的连接数仍然可以工作，但是在这种情况下 Redis 会成为性能瓶颈。）

你可会疑惑，既然他是效能的bottleneck那总可以舍弃不用Redis吧？！没错，Cube.js非需要使用Redis，如果你想在没有 Redis 的情况下在生产中运行 Cube.js，你可以使用CUBEJS_CACHE_AND_QUEUE_DRIVER环境变量来memory，但没有Redis就无法运行无服务器和集群部署，因为它用於管理查询队列。