视频
Redis 7.2 在所有 Redis 产品中设定了新的体验标准
了解更多
未来之快即将在您所在城市的一个活动中呈现。
加入我们参加 Redis 已发布
分享
Redis OSS 自 2009 年创建以来，一直拥有非常活跃的开源社区。围绕它开发了许多工具和实用程序，Dynomite 就是其中之一，它是一个非分布式数据存储的点对点地理分布层。
Dynomite 由 Netflix 上的一组工程师开发，并作为开源软件发布。尽管它为特定需求提供了良好的解决方案，但在过去几年中并没有得到有效的维护。此外，Redis OSS 的某些功能、命令和数据类型（例如 Pub/Sub 或 Streams）因 Dynomite 的 Redis OSS 实例发行模型而不可用或受到限制。
因此，我们一直在帮助组织将其 Dynomite 数据库迁移到 Redis Enterprise 集群。
让我们从快速描述 Dynomite 和 Redis Enterprise 的架构开始我们的比较。
典型的 Dynomite 集群可描述如下
Dynomite 是一款点对点分发层，因此客户端可以将写流量发送到 Dynomite 集群中的任何节点。如果节点负责数据，则数据会被写入其本地 Redis OSS 服务器进程，然后异步复制到集群中所有数据中心的其他机架。如果节点不拥有数据，它将充当协调器并将写操作发送到同一机架中拥有数据的节点。它还将写操作复制到其他机架和 DC 中的相应节点。
Redis Enterprise 集群也通过不同的 Redis 实例或分片来分发数据，但有以下两个主要区别
Redis Enterprise 集群的另一个重要组成部分是所谓的“管理路径”，其中包括集群管理器、代理和 REST API/UI。集群管理器负责协调集群，将数据库分片置于高可用节点，并检测故障。代理将应用程序的 Redis Enterprise 集群拓扑隐藏起来，方法是为集群内的每个数据库提供一个从不改变的端点。它也有助于通过复用和分片命令，扩展客户端连接。
以下是典型 Redis Enterprise 集群的示意图
借助 Redis Enterprise 的 Active-Active 功能，你可以创建一个跨越多个集群的全球数据库。这些集群通常位于世界各地的不同数据中心。写入 Active-Active 数据库的应用程序连接到本地实例端点。应用程序对本地实例的所有写入都将复制到具有强烈最终一致性的所有其他实例。
主动-主动复制为地理分布式解决方案提供了许多优势，其中之一是针对简单和复杂的 Redis Enterprise 数据类型的无缝冲突解决，我们将在下面讨论。
现在我们对 Dynomite 和 Redis Enterprise 的拓扑结构有了了解，让我们看看它们对组织中的开发人员和 DevOps 意味着什么。
除了 Dynomite 没有被积极维护之外，从开发者的角度来看，组织想要从 Dynomite 迁移 到 Redis Enterprise 的主要原因有三个：
让我们更详细地了解前两个原因。
正如您可能已经知道的那样，Redis OSS 不是一个简单的键值存储，也就是说，它不仅允许您将字符串键与字符串值相关联。Redis OSS 是一个支持不同类型值（例如列表、集合、哈希或流）的数据结构服务器。我们称之为 Redis OSS 的“核心数据类型”。
Redis OSS 也可通过称为“模块”的动态库进行扩展。借助模块，您可以使用与在内核内部执行类似的功能快速实现新的 Redis 命令。最流行的模块包括提供查询、辅助索引和全文搜索的RediSearch，以及将 Redis OSS 转变为功能强大的文档存储的RedisJSON。
如同在引言中所讨论的，某些 Redis OSS 命令和数据类型由 Dynomite 渲染为不可用或受限。以下是一个非详尽比较
您可以在此处找到 Dynomite 支持和不支持命令的完整列表。
另一方面，Redis Enterprise 与 Redis OSS 并行维护，允许使用模块进行多模型操作，并以完全可编程和分布式的方式执行核心 Redis OSS 数据结构。
Dynomite 是一个 AP 系统，为一致性提供了三种选择。无论您选择哪种选项，务必知道 Dynomite 通过应用Last Write Wins 策略解决异步写冲突。这可能会由于不相关的时间戳导致更新丢失，尤其是在地理分布式写入的上下文中。
另一方面，Redis Enterprise 的 Active-Active 架构基于 Redis OSS 命令和被称为无冲突复制数据类型 (CRDT) 的数据类型的另一种实现。CRDT 使用向量时钟进行事件排序。它们确保当任何两个副本接受相同的一组更新时，它们会通过采用数学上可靠的规则来以确定性的方式达到相同状态，以保证状态收敛。另外，你也可以启用因果一致性。
因此，使用 Redis Enterprise
如果你准备好了，你可以通过关注此 链接 来查找已实现的规则以及冲突解决的示例。
现在，让我们从 DevOps 的角度比较 Dynomite 和 Redis Enterprise，通过讨论以下主题
当一个节点在 Dynomite 机架内出现故障时，写操作和读操作对机架的操作就不可能了。这意味着在本地写入的应用程序需要自己处理到另一个机架的故障转移。请注意，如果你的应用程序是在 Java 中开发的，Netflix 的 Dyno 客户端能够在本地 Dynomite 节点出现故障时处理到远程机架的故障转移。
此外，当节点恢复后，在故障期间写在远程机架上的任何数据都会在出现故障的节点中丢失。如果你在 AWS 自动扩容组内部署，你可以使用 Netflix 的 Dynomite 管理器，它在 AWS 自动扩容组中执行节点替换和节点预热。
Redis Enterprise 的高可用性怎么样？
当一个节点出现故障时，会为所有位于该节点上的主分片执行持续几秒钟的故障转移，并且它们的副本将晋升为主副本。这种自动故障转移机制保证了会在最小的中断下提供数据。
基于这一点，
这些机制能让 Redis Enterprise 保证 99.99% 的正常运行时间和 99.999% 的正常运行时间，用于 Active-Active 部署。
使用 Dynomite 可以扩展 Redis OSS 的规模，同时还可以保持较小的延迟时间，从而获得良好的性能。你可以查看 基准，如果你正在使用 Dynomite，你可能已经知道了这些。
关于可扩展性，Dynomite 和 Redis Enterprise 之间的主要区别是
如果你没有在 AWS 自动扩容组中使用 Dynomite Manager，那么给正在运行的 Dynomite 机架添加主机通常需要
另一方面，借助 Redis Enterprise，你可以
此处是 Redis 几年之前完成的基准，其中 Redis Enterprise 在 40 个 AWS 实例上实现了超过 2 亿次/秒的操作，并具有低于毫秒的延迟时间。
当我们谈及 Redis 的连接管理时，首先想到的是 Redis 客户端（例如 Jedis 或 Lettuce）如何处理连接池和管道。对于这一点，Netflix 也不例外，并为 Dyno 客户端实施了这些功能。
Redis Enterprise 开箱即用就能提供这些功能。代理本身会与集群中的分片建立持久连接，而且这些连接由客户端共享。通过在一系列分片的持久连接的调度请求中应用性能优化，并在 Redis 的一侧执行复用和管道，也会应用性能优化。
此外，代理是多线程的，并且会自动扩展以处理客户端连接中的突发流量。
首先，让我们记住，在一个 Redis Enterprise 集群中一台机器不等于一个 Redis 实例，并且每个主分片最多只能有一个副本。
其次，Redis Enterprise 是 多租户 的。这意味着一个 Redis Enterprise 集群可以处理数百个完全隔离的数据库。使用 Dynomite 这样做远非小事。值得注意的是，Redis Enterprise 的多租户功能非常适合其多模式功能。在微服务的上下文中，人们可以想象在一组节点中运行不同的适合用途的数据库，每个数据库都有自己的复制、扩展、持久性和模块配置。
最后，Redis Enterprise 还有一个名为 Redis On Flash (RoF) 的功能。RoF 使您的数据库能够同时使用 RAM 和专用闪存（SSD/NVMe）来处理更大的数据集，具有与 RAM 一样的延迟和性能，但与全 RAM 数据库相比，成本降低 >70%。
Dynomite 可以部署在运行 Ubuntu、RHEL 和 CentOS 的容器或机器中。部署始终是自我管理的，因为您需要提供基础架构和资源来管理集群。此外，如前所述，如果您想利用 Dynomite Manager 的功能，您需要在 AWS 自动扩展组中部署 Dynomite。
另一方面，Redis Enterprise 有许多部署选项，可以分为两组
