4 个迹象表明您可能正在超出逻辑数据库的承载能力

Redis OSS 的逻辑数据库（无论是自行部署还是作为托管服务启动，如 ElastiCache）的目的是通过减少管理需求和提供开箱即用的通用默认设置来简化开发人员的工作。

然而，在生产环境中，您的功能和操作需求可能会发生变化，单个 Redis 实例可能不再足够。

以下是四个迹象，表明您可能正在超出 Redis OSS 逻辑数据库的承载能力。

您有一个嘈杂的邻居

假设您是游戏公司的开发人员。您使用了三个 Redis 逻辑数据库：一个用于缓存和排行榜，一个用于匹配，一个用作消息代理。贵公司最近发布了一款成功的新游戏，并且您每天晚上都有高峰匹配请求。但在那个时间段内，您的排行榜显示的是过时数据，并且您的消息代理的延迟正在增加。

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

在另一种情况下，您可能有 bug。例如，在微服务环境中，每个服务都读写一个专用的逻辑数据库，但由于单个微服务中的 bug，所有服务的数据库可能同时发生故障。将多个用例集中到单个 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

日志、延迟子命令也是如此，或者如果您想从 Redis info 命令中 grep 或获取任何值：连接客户端数、已用内存、当前 IOPS、被逐出键数等。

如果您使用第三方工具（例如 Grafana）来监控 Redis，您可以在定义 Redis 数据源时指定数据库编号。但是，仪表板中显示的数据不一定仅限于您定义的数据库索引。您确实可以获得键空间中正确的键数量，但命令统计、客户端连接和 IOPS 对选定的索引不是特有的；这些值是整个 Redis 实例通用的。

最后，假设尽管读取仪表板和日志很复杂，您还是确定了您的缓存逻辑数据库上的延迟是由于您为会话存储数据库需要而启用了每次写入时的 AOF。那么除了放宽会话数据库的持久性要求外，您还能做什么呢？这就回到了您正在超出逻辑数据库承载能力的两个早期迹象：嘈杂邻居和独特的配置要求。

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

那么，您有哪些选择？

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

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

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

您的Redis 技术团队乐意协助您规划迁移。当您联系我们时，请提及您想根据本文内容迁移您的逻辑数据库。