Redis 复制与 KeyDB 主动复制：优化系统资源
许多网站为了服务器的高可用性而运行副本节点。这很合理，但这个副本是否被充分利用了？或者您只是为了高可用性而付费，却没有获得相当于资源翻倍的性能提升？本文讨论了 Redis 中使用的选项，以及在兼容 Redis 的数据库 KeyDB 中使用的主动复制选项。
KeyDB 可以作为 Redis 的直接替代数据库，因为它完全兼容 Redis 的模块、API 和协议。KeyDB 拥有开源 Redis 提供的所有功能，但其开源基础代码中还包含了许多其他强大的免费选项，如闪存支持、主动复制、完全多线程、AWS S3 备份等。您可以在这里了解更多。
KeyDB 在其稳定版本 5.0 中引入了主动复制功能，这实质上允许两个主节点进行同步读/写并支持故障转移。这使得读写操作可以负载均衡到两个主节点上。主节点互为副本，在同步的同时都作为主节点工作。
使用 Redis 设置高可用性#
如果您在一个简单的高可用性设置中运行 Redis，您的配置可能如下所示：
使用 KeyDB 设置高可用性#
开源的 KeyDB 在其基础代码中提供了使用主动复制的选项。您可以轻松地用这个服务器替换您的 redis-server 来进行尝试。如果您使用 KeyDB 进行高可用性设置，您的等效配置将如下所示：
此设置有两个相互复制的相同主节点（启用了主动复制）。您现在可以在两者之间进行负载均衡。发生故障时，您只需从活动的主节点进行读/写。脑裂情况通过时间戳来处理。您的节点无需重新配置，当发生故障的节点/连接恢复时，它将同步并像以前一样工作。这很直观且设置简单，因此社区对此功能有强烈的需求。您可以在这里阅读更多关于主动复制功能以及设置示例的信息。
充分利用您的资源#
那么，将负载均衡到您的主-主节点有什么好处呢？当使用两台机器的资源时，数字正如您所期望的那样。请看下面一个通过 HAproxy 进行负载均衡的基准测试。关于基准测试结果的设置详情在页脚。
从上图可以清楚地看出，如果您还没有充分利用副本节点的性能，运行主动复制会带来巨大的好处。对于那些已经将 KeyDB 的读操作负载均衡到副本实例（客户端侧）的用户来说，您可能不会注意到两种设置之间有很大的性能差异。对于 Redis，如果您已经将读操作负载均衡到副本实例并正在使用集群，您可能不会注意到很大的差异，但如果您正在运行服务器而没有使用可用的计算能力，KeyDB 的多线程可以给您带来巨大的提升。
上述测试使用了 m5.large ec2 实例（2核），并且服务器在基准测试中已达到最大负荷。KeyDB 在这里优于 Redis，因为它用满了两个核心（Redis 不是多线程的）。在更大的机器上，您可以将单个 Redis 实例的性能提高一倍以上。
结论#
无论您使用哪种数据库，重要的问题是您是否已经设置为充分利用您的资源。对于开源的 KeyDB，其理念是为您提供一个简单的开源设置选项，在实现高可用性的同时充分利用您的资源。如果您正在运行 Redis，您可以通过运行哨兵节点和集群/分片来实现这样的设置。如果您有 Redis Enterprise，Redislabs 提供了主-主复制的方案。
要了解更多关于主动复制的信息，请点击下方链接
- 关于主动复制 – 阅读以了解更多关于主动复制的信息、视频教程以及 KeyDB 如何处理脑裂情况
- 在 Docker 上运行主动复制
- HAproxy 配置，包含 KeyDB/Redis 设置的注释
基准测试#
对于主动复制，我们将基准测试的读/写操作以轮询方式均衡到两个主动复制节点（互为副本）。对于主-从复制设置，我们运行相同的两个节点，但采用主-从设置，其中流量流向主节点，副本进行同步。此处的基准测试是针对每个数据库实例使用一个 m5.large 实例（2核）进行的，因为它们是预期的瓶颈。每个 KeyDB 实例启用了2个线程。一个 m5.2xlarge 实例（8核）用于 RedisLabs 的 Memtier 客户端（基准测试工具）。Memtier 运行选项为：--threads=7 --requests=30000。这是为了确保客户端不是瓶颈，并有足够的请求以获得一致的结果。HAproxy 配置为启用7个线程以确保它不是瓶颈，采用 tcp 模式和健康检查（点击此处查看示例配置文件）。HAproxy 运行在一个 m5.2xlarge（8核）实例上。