使用小型 Devops 团队在 4 个公共云上管理 50K+ 个 Redis 数据库

现代应用程序为了在当今快节奏的云环境中生存乃至繁荣，需要满足一系列通用需求。其中包括低响应时间（小于 100 毫秒）、无限的可扩展性、高可用性和最佳性能等。在众多可用的现代数据库选项中，Redis 已被证明是最受欢迎的之一。Redis 已帮助 2,500 多家付费客户创建了 50,000 多个数据库，每天新增数据库超过 100 个。作为 Redis 开源项目的主要贡献者，我们看到许多使用 Redis 的用例包括社交应用、在线广告公司和游戏公司。我们在四大主要云（AWS、Azure、GCP 和 SoftLayer）上运行 Redis 服务的经验使我们意识到用户遇到的许多挑战，这促使我们开发了经过充分测试的解决方案，其中一些将在下面分享。

挑战 #1：稳定的卓越性能

虽然 Redis 非常快，能够在不到 1 毫秒的时间内响应请求，但在云中运行它可能会导致性能显著下降。然而，使用 Redis，所有操作都在后台执行，将尽可能多的 Redis 实例整合到集群中，以实现纯粹的多租户架构，而不会降低性能。我们平台上的 Redis 数据库使用主从复制，主节点位于一个节点上，而从节点位于另一个节点上，每个节点上尽可能多地部署实例。此外，集群围绕奇数个节点构建，以便在发生故障时拥有仲裁。我们的零延迟代理向用户隐藏了一切，因此用户只看到一个单一的端点，并且能够通过添加代理来获得更高的吞吐量，而无需了解分片、集群或节点。

挑战 #2：数据中心选择

当我们开始使用 Redis 时，我们面临的主要挑战是了解哪个数据中心最适合每个应用程序。重要的是，每个 Redis 数据库都必须与其相应的应用程序运行在同一个数据中心，以避免网络延迟。用户在区域内创建实例时会选择数据中心，但是，从 AWS 选择区域或数据中心时会出现问题，因为它们在不同账户之间的映射方式不同。例如，Redis 的“us-east-1a”对于其他用户可能表示为“us-east-1c”。尽管这些是完全不同的数据中心，AWS 设置这种方法是为了确保其内部架构的稳定负载均衡。否则，由于大多数用户对特定数据中心没有偏好，大多数用户会选择第一个，从而造成需求不平衡。为了将 Redis 的多云、多区域服务从离用户应用程序最近的位置提供，我们开发了一段代码，用于在我们区域和用户区域之间进行映射。将此应用于我们的示例，我们发现“us-east-1a”的代码与“us-east-1c”的代码匹配。这意味着当用户选择在“us-east-1c”中创建数据库时，应将其映射到我们的“us-east-1a”，以确保最小的网络延迟。

挑战 #3：实例选择

决定在创建节点时选择哪个实例可能会令人困惑。因此，我们决定在 Redis 集群中可以使用任何类型的实例。虽然每种实例类型都有预定义的集合，但在集群内可以存在的规模范围没有限制，无论是 30GB 还是 200GB。这种灵活性是关键。我们希望能够应对高内存使用率和高 CPU 使用率。此外，我们希望在专用基础设施上运行一切，以避免“吵闹的邻居”，并尽可能地节省成本。使用大型实例自动提供了专用实例的设计。这些大型实例随后用于创建我们自己控制的多租户基础设施。为了为任何架构创建稳固的基础设施，建议在不同云中使用特定实例：AWS 中的 c3（用于性能）和 r3（用于内存）；Azure 中的 a4、a5、a6 和 a7；GCP 中的标准高内存和高 CPU；SoftLayer 中裸金属服务器上的基础集群，并添加虚拟机进行横向扩展。

挑战 #4：数据持久性

对于每秒运行 100 万次操作、其中 50% 是写入请求的用户来说，数据持久性对于 Redis 至关重要。问题是，如何在 AWS 的 EBS 基础设施上执行此操作？首先，您需要了解云存储架构背后的细节：本地临时存储相对较快，而网络附加存储（例如 EBS）是持久性的。AWS 上最大的 EBS 卷提供专用的 EBS 磁盘存储（GCP 也是如此）。不幸的是，这不足以应对 Redis 的性能需求。因此，我们将两者混合使用，利用临时存储满足部分存储需求，并结合 EBS 进行持久化。相应地，我们对 Redis 进行了精细调整，以提高其访问磁盘时的速度，并在使用复制时利用从节点执行数据持久化活动，从而释放主节点资源。

挑战 #5：监控

如何监控一切？Zabbix 用于监控节点，至于数据库指标监控，我们未能找到合适的开源项目，因此我们构建了自己的监控系统——Limbic——它基于 Python、RRD 和 Redis。借助这个平台，我们能够监控 50,000 个数据库，每个数据库包含 100 个指标，并保留 10,000 个时间分辨率。适时，它将开源供所有人使用。

我们如何管理服务

凭借我们强大的 DevOps 团队，我们能够处理这些复杂的基础设施，尽管规模不大，但他们得到了对系统了如指掌的开发人员的支持，这些开发人员可以被调动起来实时解决生产问题。我们在迁移到生产环境时也采用“小步快跑”的方法。因此，我们总是从手动配置开始，然后慢慢转向自动化。我们发现这种务实的方法总是能成功。

总的来说，Redis 采取了必要措施，确保为客户提供高质量的 Redis 性能。我们针对上述挑战提出的解决方案，为客户提供了他们所需的安心，使其能够成功专注于自身核心能力。欲了解更多信息，请查看探讨上述挑战的完整视频以及相应的幻灯片演示。