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