超快速的未来将于线下活动来到你的城市。
加入 us at Redis Released
分享
现代应用程序有以下一系列通常需求，这不仅让它们能在今日快速发展的云环境中生存，更能让它们茁壮发展。其中包括较低的响应时间（少于 100 毫秒），无限的可扩展性，高可用性和最优性能（仅举几例）。在大量可用的现代数据库选项中，Redis 已被证明是最受欢迎的一个选择。Redis 已帮助 2500 多名付费客户创建了 50000 多个数据库，且每天还创建 100 多个新的数据库。作为 Redis 开源项目的 主要贡献者，我们看到使用 Redis 的许多用例包括社交应用程序、在线广告公司和游戏公司。我们在四大云（AWS、Azure、GCP 和 SoftLayer）中运行 Redis 服务的经验让我们意识到用户面临的许多挑战，这进而推动了我们彻底测试的解决方案，以下列出我们共享的其中一些解决方案。
虽然 Redis 非常快（它有在少于 1 毫秒内响应请求的能力），但在云中运行它会导致性能严重下降。不过，借助 Redis，所有操作都在后台执行，可以将尽可能多的 Redis 实例纳入一个集群，从而启用纯粹的多租户架构，而且不会导致性能下降。我们的平台上的 Redis 数据库使用主从复制，其中，主节点位于一个节点上，而从节点位于另一个节点上，同时每个节点有尽可能多的实例。此外，集群围绕奇数个节点构建，以便在发生故障时能够形成法定人数。我们的零延迟代理从用户的角度隐匿所有内容，这样用户仅会看到一个端点，且能够添加代理以接收更多吞吐量，同时无权查看分片、集群或节点。
当我们开始使用 Redis 之旅时，我们的主要挑战是了解哪个数据中心最适合每个应用程序。每个 Redis 数据库在与相应的应用程序相同的数据中心上运行非常重要，以避免网络延迟。用户在区域内创建实例时会选择数据中心，但是，从 AWS 中选择区域或数据中心时会出现一个问题，因为它们在帐户之间以不同的方式进行映射。例如，Redis 的“us-east-1a”对于其他用户来说可以表示为“us-east-1c”。虽然这些是完全不同的数据中心，但 AWS 设置了此方法以确保其内部架构的稳定负载均衡。否则，由于大多数用户对特定数据中心没有偏好，大多数用户会选择第一个，从而造成需求水平不平衡。为了从尽可能最接近用户应用程序的位置提供 Redis 的多云、多区域服务，我们开发了一个在我们的区域和用户区域之间执行映射的代码。将此应用于我们的示例，我们发现“us-east-1a”的代码与“us-east-1c”的代码相匹配。这告诉我们，当用户选择在“us-east-1c”中创建数据库时，应将其映射到我们的“us-east-1a”，以确保最小的网络延迟。
在创建节点时决定选择哪个实例可能会让人困惑。因此，我们决定可以在 Redis 集群中使用任何类型的实例。虽然每种实例类型都有一个预定义的集合，但是集群中可以存在的尺寸范围没有限制，无论是 30GB 还是 200GB。这种灵活性是关键。我们希望能够应对高内存使用量和高 CPU 使用量。此外，我们希望在专用的基础设施上运行所有内容，以避免“嘈杂的邻居”，并尽可能降低成本。按设计，使用大型实例自动提供专用实例。然后，这些大型实例用于创建我们自己受控的多租户基础设施。为了创建适用于任何架构的坚实基础设施，建议在云中使用特定实例：AWS 中的 c3（用于性能）和 r3（用于内存）；Azure 中的 a4、a5、a6 和 a7；GCP 中的标准高内存和高 CPU；SoftLayer 中基于裸机服务器的基本集群，并添加虚拟机进行扩展。
对于每秒运行 100 万次操作的用户，其中 50% 是写请求，数据持久性对 Redis 来说极其重要。问题是，这如何在 AWS 的 EBS 基础设施上执行？首先，您需要了解云存储架构背后的细节：本地临时存储相对较快，而网络附加存储（例如 EBS）是持久的。AWS 上最大的 EBS 卷提供专门的 EBS 磁盘存储（GCP 也是如此）。遗憾的是，这还不足以应对 Redis 的性能。结果，我们对两者进行混合，将临时存储用于某些存储需求，与 EBS 结合用于持久性。相应地，我们对 Redis 进行微调，以提高它在访问磁盘时的速度，并在使用复制时使用从属副本执行数据持久性活动，从而释放主副本。
如何监控一切？Zabbix 用于监控节点，而在监控数据库指标方面，我们搜索了一个开源项目，但无济于事，这促使我们构建自己的监控系统 – Limbic – 它基于 Python、RRD 和 Redis。借助此平台，我们能够监控 50,000 个数据库，每个数据库具有 100 个指标，并保持 10,000 个时间分辨率。在适当的时候，它将以开源方式提供，供所有人享用。
我们能够在我们实力强大的 DevOps 团队的帮助下处理这些复杂的架构，虽然规模很小，但得到了十分了解系统内部机制的开发人员的支持，并且可以实时参与解决生产问题。我们在转移到生产时还会采用一种“循序渐进”的方法。结果，我们始终从手动配置开始，然后逐渐过渡到自动化。我们已经发现这种实用方法总是奏效。
总体而言，Redis 已经采取必要的步骤，确保为我们的客户提供优质的 Redis 性能。我们针对上述挑战提出的解决方案为我们的客户提供了必要的安心，以便他们能够成功专注于自己的核心能力。如需更多信息，请查看完整的视频，其中探讨了上述挑战以及相应的幻灯片放映。
