1. 您有个“吵闹的邻居”

PS：“吵闹的邻居”指同一个Redis OSS实例中其它繁忙的逻辑数据库。

场景：假设你是一家游戏公司的开发人员，使用三个Redis逻辑数据库：一个用于缓存和排行榜，一个用于匹配，一个作为消息代理。你的公司最近发布了一款非常成功的新游戏，每晚都有匹配请求的访问高峰期。但是在这个时间段，你的排行榜显示的数据可能不是实时的，并且消息代理的延迟正在增加。

问题的起源：

• 这很可能是因为，单个Redis实例，从命令执行的角度来看是单线程的，并且按顺序为每个请求提供服务。由于逻辑数据库都共享同一实例，所以针对特定逻辑数据库执行的操作可能导致此该线程变慢甚至被阻塞，从而影响其他数据库。如果您有吞吐密集型用例或者您的应用程序使用 O(n) 复杂度的 Redis 命令，这可能会导致性能问题。
• 在另一种情况下，您可能会遇到错误。例如，在微服务环境中，每个服务都会读写专用的逻辑数据库，所有服务的数据库可能会由于某个微服务中的错误而同时失效。将多个用例集中在一个 Redis 实例中是不具备容错能力的。

如果您使用专用实例而不是逻辑数据库会怎样呢？

使用专用数据库处理每个微服务的请求将为每个服务提供更好的性能，并使您的应用程序更具弹性。

2. 您想要扩展规模

避免“吵闹邻居”问题的一种方法是扩展您的数据库。为此，您可以使用Redis OSS Cluster，它允许您在多个节点上进行数据库集群化。

存在的问题：然而，这种方式仅支持位于索引0的逻辑数据库，这意味着您只能扩展一个逻辑数据库，这可能会导致您将与更重要的用例相关的数据存储在同一逻辑空间中，从而否定了保留单独名称空间的初衷。

如果您使用专用实例而不是逻辑数据库会怎样呢？

您可以根据需要扩展每个数据库，没有限制。

3. 您的用例多样，需要量身定制的配置

场景：想象一下您是一家电子商务公司的软件开发人员，您使用一个逻辑数据库进行缓存，使用另一个逻辑数据库进行会话管理。您有以下要求：

• 当会话处于活动状态时，会话存储数据是唯一的事务数据源。因此，需要具备高可用和数据持久性以确保事务数据不会丢失。
• 如果您的缓存丢失，永久存储中始终有一份副本。

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

对于缓存用例而言，相同的情况也适用于驱逐策略和内存限制，以及TLS证书、密码，或是Redis OSS的redis.conf文件中的所有配置选项。

如果您使用专用实例而不是逻辑数据库会怎样呢？

不再需要妥协，您可以根据业务需求配置每个数据库。

4. 监控和故障排除很痛苦

场景：因为逻辑数据库共享相同的Redis进程，您可能会发现监控和故障排除变得很繁琐。

案例1：monitor命令。它会将Redis服务器处理的每个命令都返回，无论您从哪个逻辑数据库运行它，它都会返回在服务器上运行的所有逻辑数据库的命令，尽管它会显示每个命令的数据库索引。

案例2：slowlog命令。在这里，没有区分记录的命令是在哪些逻辑数据库中运行的。例如，为了人为地创建一些执行缓慢的命令：

• 我在索引0上运行了两次debug命令，并在索引1上运行了一次
• 然后我在索引1上运行了slowlog get命令

其他场景：这同样适用于日志、延迟子命令，或是您想要 grep 或从 Redis info命令获取的任何值：连接的客户端数量、已用内存、当前 IOPS、逐出键的数量等。

其他解决方案：

使用第三方工具来监视Redis，比如Grafana，您可以在定义Redis数据源时指定数据库编号。然而，仪表板中显示的数据不一定是您定义的数据库索引所独有的。

获取keyspace中正确的键数，但命令统计、客户端连接和IOPS并不基于所选的索引,这些值是整个Redis实例共享的。

设想一下，尽管阅读仪表板和日志很复杂，但您发现缓存逻辑数据库上的延迟来自于您在每次写入时启用 AOF，因为您的会话存储数据库需要它。

除了放宽会话数据库的持久性要求之外，您还能做什么呢？这又回到了逻辑数据库已经无法满足需求的早期迹象：“吵闹的邻居”和独特的配置要求。

（框线或小字）如果您使用专用实例而不是逻辑数据库会怎样呢？

您将更轻松、更快速地监控每个数据库的性能并识别问题，从而节省运维时间和精力。