飞快的未来将降临在您所在城市的一场活动中。
在 Redis 发布会上加入我们
分享
众所周知，你应该始终采取保护措施，否则事情会很快变得非常糟糕。在云世界中，这转化为我们内存数据存储的容错能力，它有效地决定了在故障场景下抵御故障和从故障中恢复的方式和可能性。
尽管一些应用程序认为丢失部分或全部数据是可以接受的操作模式，但对于大多数应用程序来说，数据持久化和高可用性是硬性要求。我们之前曾在 文章 中讨论过这个问题，但鉴于其重要性，我们希望进一步分享如何在云环境中维护内存数据存储的高可用性 (HA)。
借助诸如 Redis 之类的技术，可以使用开箱即用的工具来支持此类目标。这些根深蒂固的能力提供了一个良好的起点，但通常还不够，尤其是在云环境中使用时。
例如，Redis 配备了内置复制功能，但在拥塞网络中使用时仍会遇到不理想的稳定性和性能影响。Redis 的 Sentinal 解决了高可用性挑战，但尚未 稳定、成熟 以及与大多数 客户端库 集成。
Redis 的集成数据持久化机制（即快照和仅追加文件）非常可靠，但在与云存储一起使用时可能会带来严重的性能损失。不同于 Redis，Memcached 本身不提供任何高可用性功能。在扩展它以实现高可用性时，有两种方法占主导地位：repcached 或客户端复制。然而，每种方法都有各自的缺点，这使得它们不适用于某些应用程序要求。
Repcached 的主要缺点在于它无法扩展并且只能用于 Memcached v1.2.x，并且客户端写入的重复可能会成为主要的性能阻碍。为了在云计算资源上部署真实世界生产级设置，你需要使用额外的可用性预兆对其进行优化。
我们的 Redis 和 Memcached 云服务考虑了多种故障场景，并提供了可用性机制来处理所有这些场景。我们消除的最简单的可用性威胁是单个节点（即云服务器实例）出现故障。
作为整体云环境中的低级别块，节点会定期发生故障，并且确实会发生故障。我们通过在两个或更多节点上复制数据库来保护我们的数据库免受此类故障的影响，这样当一个节点发生故障时，在其他节点上至少有一个副本可用。我们的服务会自动检测到此类故障，无缝地提升一个副本以供使用，并向发生故障的节点提供一个替换节点。
对于我们的常规计划，我们提供了两种复制模式供选择：内存中复制和磁盘中复制。使用内存中复制时，数据库的副本被加载并在备用节点的主内存中随时准备就绪。故障转移到内存中副本几乎是即时的，在大多数情况下，应用程序在切换期间或切换后不会察觉到任何明显影响。
我们建议将内存中复制用于关键应用程序，但 RAM 资源明显比磁盘空间更昂贵。因此，我们还支持免费磁盘基础复制。通过将数据库存储在活动节点的本地存储中并将其复制到空闲备份节点的本地存储中，我们可以实现磁盘基础复制。当服务触发故障转移时，备份节点加载磁盘存储的数据库，并取代目前不活动的副本。当然，对存储的响应时间和访问时间本身比访问内存所需的时间高出几个数量级，因此故障转移持续时间越高，未同步数据丢失的可能性就越大。
我们提供的一些计划可以在整个可用区发生故障的情况下仍然继续正常运行，而仅出现最少的混乱。使用多可用区计划创建的这些实例，其副本保存在不同的可用区中。如果整个区域发生故障，我们的自动故障转移机制会切换到从其余副本提供数据。由于性能方面的考虑，我们的多可用区计划不提供基于磁盘的复制，而仅支持基于内存的复制。
还存在另一种罕见但仍然可能发生的故障情况，即两个副本都受到影响。在这种情况下，简单的复制无济于事，因为没有幸存者。我们通过在持久性云存储服务（例如 Amazon EBS）之上使用原生数据持久性机制（即仅追加文件和快照），来应对此类事件。当发生如此严重的故障时，我们会使用群集恢复工具来重建受损的设置，并从存储中引导数据集。
在可能的故障列表中，最后一种是末日情景，其中云的很大一部分（例如，整个数据中心（又称区域）或多个数据中心（又称数据区域））都化为乌有。市场领先的云提供商 AWS 在去年遇到了不少于 4 次这样的中断。
这些崩溃无法采取对策（至少在云受影响的区域内），但我们的服务通过维护自动每日备份和按需备份到远程存储（即 S3 或 FTP 服务器）来保护您的数据库免受其影响。在完成基础设施资源的恢复和设置后，这些备份使我们的群集恢复工具能够恢复您遭破坏的数据库的内容。
根据他们的计划和需要，在我们服务中托管的数据集在幕后进行分片，以便实现接近无限的可扩展性。
此设计的可喜副产品是数据库的总体可用性得到提高
确保现代计算云的湍流环境中内存数据存储的可用性并非易事。建立可从故障中恢复以维护应用程序持续运行的弹性配置并非一劳永逸的工作，而需要持续的监控和维护。
虽然 Do-It-Yourself 方法可能适合一些人，但我们的服务为那些不想管理内存数据存储而想使用它的人提供了一键式高可用性（以及其他好处）。
