如果您实现了优先级速度的缓存，消息代理或任何其他数据用例，那么您可能会使用Redis。在过去的十年中，Redis一直是最受欢迎的内存数据存储，这是有充分理由的。它是为处理这些类型的用例而建造的。但是，如果您要操作一个重新的实例，则应意识到最常见的故障点，其中大多数是其单线程设计的结果。
如果您的REDIS实例完全失败，或者只是暂时无法使用，则可能会发生数据丢失，因为在这些时期内可以编写新数据。如果您将Redis用作缓存，则结果将是用户性能差，并且可能是暂时的停电。但是，如果您将Redis用作主要数据存储，那么您可能会遭受部分数据丢失。更糟糕的是，如果Redis问题会影响其拍摄适当快照的能力，或者快照损坏，则最终可能会失去整个数据集。
。在本文中，我们将解释您的Redis实例可能失败的主要原因，并提供建议避免这种情况。我们还将将REDIS（OSS版本）的可靠性与Dragonfly的可靠性与源可用的多线程内存数据库的可靠性与现代架构旨在避免许多此类问题。
。REDIS实例可能失败的主要原因
Redis架构中的可伸缩性限制
redis仅限于单个线程，这会导致瓶颈和高工作负载期间的性能降低。垂直缩放不会使您对Redis的距离很远 - 没有什么可以阻止您提供128个CPU内核，但是Redis只能使用其中之一。这意味着水平缩放是您唯一的现实选择，这立即使事情变得更加复杂，因为您现在必须部署和维护分布式系统。
聚类将大大增加维护重新部署所需的工作量。如果您获得了不健康的节点，则可以轻松替换而没有停机时间（因此数据丢失），除非您实施高可用性实践。高可用性不仅意味着设置更多的节点来处理额外的负载，而且还要配置这些节点以具有一个或多个复制品 - 需要更多的基础架构和维护资源，而不是只需扩展。
与许多重新的问题一样，这是由于其设计所致。 Redis最初做出了某些设计权衡，使其成为速度和延迟的行业领导者。但是，从那时起，更强大的公共云托管已经发展出来，并且已经提高了消费者的期望 - 他们希望快速，高度可用的应用程序导致开发人员需要更高的速度，较低的延迟和更高的系统可靠性。
记忆不足
像所有内存数据库一样，REDIS将其所有数据存储在内存中。这使得数据更快地检索了，但是如果您的系统无法记忆，则可能会遭受数据丢失。 REDIS在快照阶段特别容易损失记忆力。
每次备份Redis数据集时，快照过程都会在后台启动。如果Redis在重大写入负载下试图备份数据，则记忆使用情况大大增加，并且如果您没有足够的记忆来一次分配这两个任务，则可能会带来整个REDIS的风险实例。
>带有1000万键的Redis实例正在使用56个GIB内存。快照过程是在60秒后开始的，并且内存使用量增加到其原始大小（105 GIB）的两倍，然后在过程完成后240秒降至正常水平。
如果您尝试在沉重的写入负载期间进行扩展或升级redis实例，则可能发生完全相同的问题：如果您没有足够的内存分配，则可以run out，导致崩溃和/或数据损失。
redis群集节点之间缺乏一致性
redis不能保证一致性 - 这是一个折衷，以达到非常低的延迟。一致性意味着群集的主和复制节点之间的数据始终是同步的。问题在于，当数据写入主节点主节点时，它会发出一条消息，说在写入之前，写入成功。因此，如果在此过程中主节点发生了什么事，则副本将晋升为Master和the latest data write gets lost forever。
另一个一致性问题被称为“分裂大脑”。另一个复制品。然后，复制品将晋升为主，一旦发生这种情况，可能会将不同的数据写给两个不同的主节点，从而导致它们退出同步。
复制循环
随着您的redis数据库越大，同步两者时，将数据从主复制到副本的复制所需的时间更长。主节点具有复制缓冲区，并且在将其复制到副本之前将其复制到此。此复制缓冲区的尺寸是有限的，因此，如果您的Redis数据库很大，则缓冲区可以在复制完成之前完全填充。这意味着，当您的主节点获得完整更新时，您的副本会错过其中的一些数据。
这是一个比复制品更大的问题，只是缺少少量数据：REDIS依赖于Master和Replica在继续执行下一个更新步骤之前是同步的检查，此问题意味着条件永远不会被满足。 REDIS通过重新启动整个复制过程来处理这一事实，这会导致无限的replication loop，这使您的实例不可用。
未能提供Redis需要的额外记忆
如果您的数据库很大，则主节点将需要大量的其他内存才能完成快照过程。 Redis通常需要的内存量是通常使用的三倍，以便可以成功完成快照。为了避免记忆力用完，您唯一的解决方案是大量提供数据库服务器。这是一个昂贵的创可贴，但这是Redis可以处理内存密集型快照过程的唯一方法。
解决最常见的重生故障原因：Redis Oss和Dragonfly之间的比较
在大多数情况下，您可以使用Dragonfly作为REDIS的替换，因为它的API兼容性。如下所示，蜻蜓直接解决了重生故障的大多数常见原因，大大降低了操作复杂性和提高可靠性。
| redis | 蜻蜓 |
|---|---|
| Single-threaded ：导致瓶颈和性能问题。 | 多线程：更快，更可靠。 |
| 对于较大的重新播放实例， horizontally scaling is really the only option 以提高性能，这意味着您需要维护重新群体。 | 可以是垂直缩放，这要简单得多。 |
| Memory overload ：这是因为redis需要处理数据库交易以及运行背景任务，例如单个线程上的快照。 | 记忆峰值不会在快照期间发生：数据库交易，而诸如快照之类的任务都可以分布在多个线程中并更快地完成，，因此崩溃的可能性要小得多。 |
| 您必须over-provision your servers 才能应对快照带来的内存使用。 | 由于使用基础硬件的效率更高，因此无需过度提供服务器。 |
蜻蜓很容易部署，并且容易扩展
蜻蜓是一个带有高吞吐量，低延迟和有效内存管理的替换。我们有动力创建蜻蜓来处理自己部署中Redis失败所看到的许多问题，包括耗尽记忆，快照问题，复制循环以及对服务器进行过度证明的需求。
蜻蜓垂直缩放，使您可以在一个实例上垂直扩展到数据超过1TB和每秒400万个查询。当您需要更大的容量时，您可以简单地调整VM大小。
REDIS作为feature, not a bug吹捧其单线式体系结构，并认为它作为集群的一部分运行时仍然表现良好。但是，保持集群为您的部署增加了复杂性，并使它们难以维护，因此需要持续重新调整才能最佳地表现。虽然那里肯定有复杂的DevOps团队通过自动化解决了这些重新质量问题，但我们发现这是一种麻烦，我们决定为其他开发人员建立一个开箱即用的解决方案。
如果您想了解更多信息，则可以通过viewing our docs立即开始或检查Dragonfly project on GitHub。