Redis 8 来了——而且它是开源的
了解更多
分享
大家都知道应该始终做好保护，否则事情会很快变得相当糟糕。在云世界中，这意味着我们的内存数据存储具有故障弹性，这有效地决定了它是否以及如何承受故障场景并从中恢复。
虽然对于某些应用程序来说，丢失部分或全部数据是一种可接受的操作模式，但对于大多数应用程序来说，数据持久性和高可用性是硬性要求。我们之前在博文中讨论过这一点，但考虑到其重要性，我们想分享更多关于在云环境中维护内存数据存储高可用性 (HA) 的信息。
借助 Redis 等技术，可以使用现成的工具来实现这些目标。这些固有的能力提供了一个很好的起点，但通常还不够，尤其是在云环境中使用时。
例如，Redis 配备了内置复制功能，但在拥塞网络中使用时仍可能遇到不理想的稳定性和性能影响。Redis 的 Sentinel 解决了高可用性挑战，但尚未稳定和成熟，也尚未与大多数客户端库集成。
Redis 集成的数据持久性机制（即快照和仅追加文件）非常可靠，但在与云存储一起使用时可能会带来严重的性能损失。与 Redis 不同，Memcached 本身不提供高可用性功能。增强它以实现高可用性时，主要有两种方法：repcached 或客户端复制。然而，每种方法都有缺点，使其不适用于某些应用程序需求。
repcached 的主要缺陷在于其无法扩展以及仅适用于 Memcached v1.2.x，而客户端写入的多重性可能会成为主要的性能瓶颈。要在云计算资源上部署真实的生产级设置，您需要通过额外的可用性保护来增强它。
我们的 Redis 和 Memcached Cloud 服务考虑了多种故障场景，并提供了可用性机制来处理它们。我们消除的最简单的可用性威胁形式是单个节点（即云服务器实例）的故障。
作为整个云环境中的低级块，节点确实会定期发生故障。我们通过在两个或更多节点上复制数据库来保护它们免受此类故障的影响，以便当一个节点发生故障时，至少在另一个节点上有一个可用的副本。我们的服务会自动检测此类故障，透明地将副本提升为主库并为故障节点配置一个替代节点。
对于我们的常规计划，我们提供两种复制模式的选择：内存复制和磁盘复制。使用内存复制时，数据库副本会加载到备用节点的主内存中，并准备好立即使用。故障转移到内存副本几乎是瞬时的，在大多数情况下，应用程序在切换期间或切换后不会察觉到任何明显的影响。
我们建议对关键应用程序使用内存复制，但 RAM 资源比磁盘空间贵得多。因此，我们也支持使用基于磁盘的复制，不收取额外费用。我们通过将数据库存储在活动节点的本地存储上并将其复制到空闲备份节点的本地存储来实现基于磁盘的复制。当服务触发故障转移时，备份节点加载磁盘存储的数据库并取代当前非活动的副本。当然，存储的响应时间和访问时间本质上比访问内存所需的时间高出几个数量级，因此故障转移持续时间更长，未同步数据丢失的可能性也更高。
我们提供的一些计划可以在整个可用区发生故障时幸存下来，并且仍然以极小的中断继续正常运行。使用多可用区计划创建的这些实例将副本保存在不同的可用区中。如果整个区域发生故障，我们的自动故障转移机制会切换到从剩余副本提供数据。出于性能考虑，我们的多可用区计划不提供基于磁盘的复制，仅支持内存复制。
另一种更罕见但仍可能发生的故障场景是两个副本都受到影响。在这种情况下，仅仅复制无济于事，因为没有幸存者。我们通过使用原生数据持久性机制，即仅追加文件和快照，以及 AWS EBS 等持久云存储服务来处理此类事件。当发生此类严重故障时，我们使用集群恢复工具重建受损的设置并从存储中引导数据集。
可能发生的故障列表中的最后一项是末日场景，即云的很大一部分——例如整个数据中心（又称区域）甚至多个数据中心（又称数据区域）——化为乌有。去年，市场领先的云提供商 AWS 至少经历了 4 次此类中断。
这些崩溃无法应对（至少在受影响的云区域内），但我们的服务通过将每日自动备份和按需备份到远程存储（即 S3 或 FTP 服务器）来保护您的数据库免受其影响。这使得我们的集群恢复工具能够在完成基础设施资源的恢复和设置后，恢复您损坏的数据库内容。
根据计划和需求，我们服务中托管的数据集在后台进行分片，以实现接近无限的可扩展性。
这种设计的一个受欢迎的副产品是数据库整体可用性的积极提高
在现代计算云的动荡环境中确保内存数据存储的可用性绝非易事。建立一个能够从故障中恢复以维持应用程序持续运行的弹性配置绝非一次性工作，而是需要持续的监控和维护。
虽然“自己动手”的方法可能适合某些人，但我们的服务（以及其他优势）为那些想要使用内存数据存储而不是管理它的人提供了点击按钮即可实现的高可用性。
