如何使用 JedisPool 优化 Redis?



您是否喜欢阅读有关如何追踪和修复各种与性能相关的问题?如果是这样,这就是我们如何通过优化 JedisPool 来解决我们面临的 Redis 性能问题的故事。我们希望这将帮助您加强您的 IT 环境。



我们的 Redis 性能问题以及寻找原因的努力


响应时间激增



Site24x7 使用 Redis 内存数据结构来减少对我们后端数据库的访问。我们开始发现我们的应用程序响应时间偶尔会出现峰值。经过调查,我们发现 Redis 缓存调用失败,并且 servlet 开始访问数据库,这导致整个应用程序响应时间出现峰值。这随机发生了几秒钟,然后应用程序恢复正常,Redis 故障为零。


Redis 大键


由于我们到 Redis 的流量几乎全天保持不变,因此我们排除了与扩展相关的问题。然后,我们开始监控 Redis 机器参数,发现每当 Redis 连接下降时,我们就会观察到 CPU 过高警报。然后,我们能够将高 CPU 使用率与 Redis 故障相关联,但高 CPU 使用率的原因仍然是个谜。


我们的怀疑指向 BigKeys 和 CPU 密集型命令,例如 SMEMBERS 密钥。Redis 命令行提供了一个选项来扫描 BigKeys (redis-cli --bigkeys) 并根据数据类型查看 BigKeys 列表。作为解决问题的下一步,我们删除了大于 1MB 的 BigKey。我们还尝试使用Redis 慢日志 列出所有可能降低系统速度的命令,但没有列出 CPU 密集型命令。



Redis连接


此时,我们有点疑惑,因为我们在慢日志中找不到任何 BigKey 或慢命令,但我们仍然观察到 CPU 峰值和连接断开。由于创建新连接是一项 I/O 密集型操作,我们开始观察新连接的模式。令我们惊讶的是,我们发现每秒创建的连接数等于执行的命令数。我们对这一发现感到惊讶,因为我们已经在使用 JedisPool(可重用 Jedis 连接的集合)来重用连接,并且没有更改我们的 JedisPool 配置。


经过进一步研究,我们了解到 JedisPool 提供了许多选项来根据应用程序的需要设置配置。但是我们使用的是默认配置。当我们有较少的应用程序服务器时,这工作得很好。随着我们扩展应用服务器,默认配置导致 JedisPool 的使用效率低下。


Jedis 是 Redis 最常用的 Java 客户端库之一,也是 Redis 官方客户端列表中推荐的客户端之一。您可以在此处下载最新版本。


由于单个 Jedis 实例不是线程安全的,因此在多线程环境中使用它们会导致各种错误或不一致。此外,为每个 Redis 查询创建新连接并不是一个理想的选择,因为这会产生 I/O 开销,从而导致性能问题。为了克服这些挑战,我们决定尝试 JedisPool,它是线程安全的 Jedis 实例的集合。


默认情况下,与 JedisPool 相关的 maxPoolSize 和 maxIdle 值都是 8。随着产品的增长,我们需要更多的连接,因此我们将 maxPoolSize 增加到 150,而 maxIdle 保持不变。因此,使用此配置,JedisPool 可以在任何给定时间创建最多 150 个连接。尽管如此,它一次只能在池中保存 8 个空闲连接,并且剩余的连接被丢弃。



绝地连接