Redis 8 已到来——它是开源的
了解更多
分享
我们很高兴宣布 Redis 8.0 的第三个里程碑版本，这是我们迄今为止最先进、性能最优的产品。
随着我们向正式发布 (GA) 版本迈进，我们将致力于持续推出新功能并改进现有功能。
在之前的里程碑版本中，我们引入了新的数据结构：JSON、时间序列以及 5 种概率数据结构（之前作为独立的 Redis 模块提供）。 我们还引入了显著的性能改进，并增加了垂直和水平扩展 Redis 查询引擎的能力。为了展示这一新成就，我们创建了一个向量搜索基准测试，包含 10 亿个在 Redis 社区版集群上运行的 768 维向量。
现在，在 CE 8.0 M03（里程碑 3 预发布版）中，我们通过使用新的异步 I/O 线程实现以及改进的复制机制，为单核和多核环境引入了新的额外性能改进，提供了比以往任何 Redis 版本都更好的性能和鲁棒性。
在里程碑 3 中，我们为 PFCOUNT、PFMERGE、GET、EXISTS、LRANGE、HSET、LRANGE 和 HGETALL 引入了额外的延迟改进。我们还改进了 CRC64 计算和具有大量参数的命令的性能。这使得 Redis 8.0 成为改进数量最多、性能提升幅度绝对是所有先前 Redis 版本中最大的版本。
与 Redis 7.2.5 相比，我们进一步降低了更广泛命令集的每条命令延迟。在包含 149 项测试的基准测试中，90 项显示延迟降低。延迟降低范围从 5.4% 到 87.4%，中位数为 16.7%。
有关性能改进的完整列表，请参阅 7.4 RC1、8.0 M01、8.0-M02 和 8.0-M03 版本说明中的“性能和资源利用改进”部分。
自 6.0 版本以来，Redis 已经能够使用 I/O 线程来处理客户端请求，包括套接字读取、套接字写入和命令解析。然而，之前的实现并未完全发挥出全部的性能优势。
此版本引入了我们新的 I/O 线程实现。其工作方式是主线程将客户端分配给特定的 I/O 线程。每个 I/O 线程在客户端完成读取和解析查询后通知主线程。主线程处理来自 I/O 线程的查询并生成回复。然后，I/O 线程负责将回复写入客户端。
您可以通过设置 io-threads 配置参数来启用这种新的 I/O 线程实现。默认值为 1。当在多核 Intel CPU 上将参数设置为 8 时，我们测得吞吐量提高了 37% 到 112%（取决于执行的命令）。随着我们进一步改进这项工程工作，预计还会有更多改进。
当在 Redis 集群上执行完全同步时，主节点的数据会被传输到副本节点。然而，在传输进行期间，客户端可以继续发送命令并接收回复。
在此版本之前，主节点会缓冲在 Redis 传输期间执行的命令。传输完成后，会开始将在此期间发生的更改流从主节点传输到副本节点的第二阶段。这个第二阶段引入了一个新问题。主节点存储更改流所需的内存经常会达到其最大大小，导致复制过程中止并重新开始。
我们正在引入一种全新的复制机制。在复制过程中，我们同时启动两个复制流：一个流用于传输主节点的数据，另一个流用于传输在此期间发生的更改。这也意味着第二阶段不再被阻塞，无需等待第一阶段完成。
这种新的复制机制提供了三个主要优势。首先，主节点在复制期间能够以更高的速率处理操作。其次，由于内存需求现在由主节点和副本节点分担，主节点用于保存更改的缓冲区大小更小。第三，复制可以更快完成。
有了这种新的复制机制，完全同步变得更快、更健壮。
下图描绘了对一个 10GB 数据集进行完全同步的情况，其中额外的 2684 万次写操作产生了 25GB 的更改。
上面的图表描绘了 2684 万次写操作随时间推移的执行速率。蓝色线条代表里程碑 3 之前的旧复制机制，而红色线条代表里程碑 3 中引入的新机制。可以看到，在新机制下，主节点在复制期间处理写操作的平均速率提高了 7.5%（47.19 万 ops/秒 对比 43.88 万 ops/秒）。
下面的图表描绘了复制缓冲区大小随时间推移的变化。实线紫色代表旧复制机制中的主节点。虚线是新机制的结果，其中紫色代表主节点，红色代表副本节点。在里程碑 3 中引入的新机制下，复制所需时间减少了 18%（101 秒 对比 123 秒），并且主节点上的峰值复制缓冲区大小降低了 35%（15.16 GB 对比 23.24 GB）。
我们正朝着 Redis 8.0 的正式发布 (GA) 版本迈进，未来还有更多内容与大家分享。现在，您可以通过从 Docker Hub 下载 Alpine 或 Debian Docker 镜像来开始体验这个里程碑版本。或者，您可以使用 snap（latest/edge 版本 – v7.9.226）或 brew 进行安装。
