点 快速的未来正在您的城市举行活动。

加入我们在Redis发布会上

您可能正在超越逻辑数据库的4个迹象

Redis OSS的逻辑数据库(无论是自部署还是作为托管服务(例如ElastiCache)启动)的目的是通过减少管理需求和提供开箱即用的“一刀切”默认值来简化开发人员的工作。

但是,在生产中,可能会出现您的功能和操作需求发生变化,而单个Redis实例不再足够的情况。

以下四项迹象表明您可能正在超越Redis OSS的逻辑数据库。

您有一个吵闹的邻居

假设您是一家游戏公司的开发者。您使用三个Redis逻辑数据库:一个用于缓存和排行榜,一个用于匹配,另一个用作消息代理。您的公司最近发布了一款成功的全新游戏,每天晚上都会出现匹配请求峰值。但是您的排行榜在此期间显示陈旧数据,而您的消息代理延迟正在增加。

这可能是因为从命令执行的角度来看,单个Redis实例使用单个线程,并且它按顺序服务每个请求。由于逻辑数据库共享同一个实例,因此此线程可能会因针对特定逻辑数据库执行的操作而减速甚至被阻塞,从而影响其他逻辑数据库。如果您有吞吐量密集型用例或您的应用程序使用O(n) Redis命令,这可能会导致问题。

在另一种情况下,您可能存在错误。例如,在微服务上下文中,每个服务读取和写入一个专用逻辑数据库,所有服务的数据库都可能由于单个微服务中的错误而同时失败。将多个用例集中到一个Redis实例中并不具有容错性。

如果您使用专用实例而不是逻辑数据库会怎样? 使用专用数据库处理每个微服务的请求将导致每个服务获得更好的性能,并使您的应用程序更具弹性。

您想要扩展

避免吵闹邻居缺点的一种方法是扩展您的数据库。为此,您可以使用OSS Redis集群,它允许您将数据库跨多个节点进行集群。

但是,这样做只支持位于索引0的逻辑数据库,这意味着您只能扩展一个逻辑数据库。这可能会导致您将与主要用例相关的数据存储在同一个逻辑空间中,从而抵消了保持独立命名空间的最初意图。

如果您使用专用实例而不是逻辑数据库会怎样? 您就可以根据需要不受限制地扩展每个数据库。

您的用例多种多样,需要定制配置

现在假设您是一家电子商务公司的软件开发人员。您使用一个逻辑数据库用于缓存,另一个用于会话管理。您有以下要求

  • 会话存储数据是会话处于活动状态时唯一的真相来源。因此,它需要高可用性和数据持久性,以确保不会丢失事务数据。
  • 但是,如果您的缓存丢失,在永久存储中始终存在副本。

尽管有这些要求,但您的两个逻辑数据库必须共享相同的高可用性和持久性配置,因为它们都共享相同的redis.conf文件。

对于逐出策略和内存限制(特定于缓存用例),以及TLS证书、密码以及更一般地说,Redis OSS的 redis.conf文件中所有配置选项,情况也是如此。

如果您使用专用实例而不是逻辑数据库会怎样? 不再需要妥协。您可以根据业务需要配置每个数据库。

监控和故障排除很痛苦

由于逻辑数据库共享相同的Redis进程,您可能会发现监控和故障排除很繁琐。

第一个示例是monitor命令,该命令回流Redis服务器处理的每个命令。无论您从哪个逻辑数据库运行它,它都会返回发送到服务器上运行的所有逻辑数据库的所有命令,尽管会显示每个命令的数据库索引。

另一个示例是slowlog命令。在这里,不会区分运行记录命令的逻辑数据库。例如,要人为地创建一些慢速执行命令

  • 我在索引0上两次运行debug命令,在索引1上运行一次
  • 然后我在索引1上运行slowlog get
Redis server output for a single command

对于日志、latency子命令或您想要从Redis info命令中grep或获取任何值时也是如此:连接的客户端数量、used_memory、当前IOPS、被逐出的键数量等。

如果您使用第三方工具(如Grafana)来监控Redis,则可以选择在定义Redis数据源时指定数据库编号。但是,仪表板中显示的数据不一定只属于您定义的数据库索引。您确实获得了键空间中的正确键数量,但命令统计信息、客户端连接和IOPS并非特定于所选索引;这些值在整个Redis实例中都是通用的。

最后,假设尽管阅读仪表板和日志很复杂,您还是发现缓存逻辑数据库上的延迟来自您在每次写入时都启用了AOF,因为您的会话存储数据库需要它。那么除了放宽会话数据库的持久性要求之外,您还能做什么呢?这又回到了您正在超越逻辑数据库的前面两个迹象:吵闹的邻居和独特的配置要求。

那么如果您使用专用实例而不是逻辑数据库会怎样? 这将使您更容易、更快地监控每个数据库的性能并识别问题,从而节省您的运维时间和精力。

那么,您的选择有哪些呢?

您可以从使用单独的Redis OSS实例来满足您的不同需求开始。或者,您可以利用Redis Enterprise的集群级多租户,它可以解决吵闹邻居、容错和通用配置问题。

无论您选择哪种方案,都需要将逻辑索引迁移到不同的专用数据库。由于所有逻辑数据库都持久保存到同一个RDB文件中,因此此类迁移的第一步是手动将每个逻辑数据库的数据提取到一个单独的文件中。这样做需要重复加载、刷新和重启辅助Redis服务器的过程。

为了免除您的麻烦,此脚本可以自动化此过程。它将您的数据加载到作为子进程启动的辅助Redis服务器中,并使用此服务器为每个逻辑数据库创建一个RDB文件:0.rdb、1.rdb等。

Redis技术团队很乐意协助您规划迁移。当您联系我们时,请说明您要根据本文内容迁移逻辑数据库。