四、总结
我们仍然欣赏由社区提出的种种有趣思路和技术方案。其中一部分有望在未来进入 Redis（我们已经开始研究 io_uring、更现代的字典、更丰富的线程使用策略等）。但在可预见的未来，我们不会放弃 Redis 所坚守的无共享、多进程等基本架构原则。这种设计不仅具备最佳性能、可扩展性和弹性，同时也能够支持内存内实时数据平台所需要的各类部署架构。
附录：Redis 7.0 对 Draonfly 基准测试细节
1、结果概述
1）版本
我们使用 Redis 7.0.0，直接通过源码构建。
Dragonfly 使用的则是构建自 https://github.com/Dragonfly/dragonfly#building-from-source 的 6 月 3 日版源码（hash=e806e6ccd8c79e002f721a1a5ecb847bd7a06489）。
2）目标
验证 Dragonfly 公布的结果是否可重现，并确定检索结果的完整条件（鉴于 memtier_benchmark、操作系统版本等信息有所缺失）。
确定 AWS c6gn.16xlarge 实例上可实现的最佳 OSS Redis 7.0.0 集群性能，并与 Dragonfly 的基准测试结果相比较。
3）客户端配置
OSS Redis 7.0 解决方案需要大量接入 Redis 集群的开放连接，因为每个 memtier_benchmark 线程都需要连接到所有分片。
OSS Redis 7.0 解决方案在使用两个 memtier_benchmark 进程时成绩最好，而且为了与 Dragonfly 基准相适应，这两个进程运行在同样的客户端虚拟机上。
4）资源利用与配置优化
OSS Redis 集群在 40 个主分片的配置下性能表现最佳，对应的就是虚拟机上有 24 个备用 vCPU。虽然设备资源仍未得到全部利用，但我们发现继续增加分片数量已经没有意义，反而会拉低整体性能。我们仍在调查具体原因。
另一方面，Dragonfly 解决方案彻底耗尽了虚拟机性能，所有 64 上 vCPU 均达到了 100% 利用率。
在两种解决方案中，我们调整了客户端配置以实现最佳结果。如下所示，我们成功重现了大部分 Dragonfly 基准数据，甚至在 30 通道条件下得出了比项目方更高的测试成绩。
本次测试强调与 Dragonfly 测试环境保持一致，如果调整测试环境，Redis 的成绩还有望进一步提升。
最后，我们还发现 Redis 和 Dragonfly 都不受网络每秒数据包或传输带宽的限制。我们已经确认在 2 个虚拟机间（分别作为客户端和服务器，且均使用 c6gn.16xlarge 实例）使用 TCP 传递约 300 B 大小的数据包负载时，可以让每秒数据包传输量达到 1000 万以上、传输带宽超过 30 Gbps。
2、分析结果
1）单 GET 通道延迟低于 1 毫秒
OSS Redis：每秒 443 万次操作，其中延迟平均值与第 50 百分位值均达到亚毫秒级别。平均客户端延迟为 0.383 毫秒。
Dragonfly 声称每秒 400 万次操作：
- 我们成功重现至每秒 380 万次操作，平均客户端延迟为 0.390 毫秒
Redis 对 Dragonfly——Redis 吞吐量比 Dragonfly 声称的结果高出 10%，比我们成功重现的 Dragonfly 结果高 18%。
2）30 条 GET 通道
OSS Redis：每秒 2290 万次操作，客户端平均延迟为 2.239 毫秒
Dragonfly 声称每秒可达 1500 万次操作：
- 我们成功重现了每秒 1590 万次操作，客户端平均延迟为 3.99 毫秒
Redis 对 Dragonfly——与 Dragonfly 的重现结果和声称结果相比，Redis 分别胜出 43% 和 52%
3）单 SET 通道延迟低于 1 毫秒
OSS Redis：每秒 474 万次操作，延迟平均值与第 50 百分位值均达到亚毫秒级。客户端平均延迟为 0.391 毫秒
Dragonfly 声称每秒 400 万次操作：
- 我们成功重现了每秒 400 万次操作，客户端平均延迟为 0.500 毫秒
Redis 对 Dragonfly——与 Dragonfly 的重现结果和声称结果相比，Redis 均胜出 19%
4）30 条 SET 通道
OSS Redis：每秒 1985 万次操作，客户端平均延迟为 2.879 毫秒
Dragonfly 声称每秒 1000 万次操作：
- 我们成功重现了每秒 1400 万次操作，客户端平均延迟为 4.203 毫秒
Redis 对 Dragonfly——与 Dragonfly 的重现结果和声称结果相比，Redis 分别胜出 42% 和 99%
用于各变体的 memtier_benchmark 命令：
1）单 GET 通道延迟低于 1 毫秒
Redis:2X: memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram
Dragonfly:memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram
2）30 条 GET 通道
Redis:2X: memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram –pipeline 30
Dragonfly:memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30
3）单 SET 通道延迟低于 1 毫秒
Redis:2X: memtier_benchmark –ratio 1:0 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram
Dragonfly:memtier_benchmark –ratio 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram
4）30 条 SET 通道
Redis:2X: memtier_benchmark –ratio 1:0 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram –pipeline 30
Dragonfly:memtier_benchmark –ratio 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30
3、测试设施细节
在本次比较测试中，我们在客户端（用于运行 memtier_benchmark）和服务器（用于运行 Redis 和 Dragonfly）使用了相同的虚拟机类型，具体规格为：
- 虚拟机：AWS c6gn.16xlarge
- aarch64
- ARM Neoverse-N1
- 每插槽核心数：64
- 每核心线程数：1
- NUMA 节点数：1
- 核心版本：Arm64 Kernel 5.10
- 安装内存：126 GB
参考资料
- https://redis.com/blog/redis-architecture-13-years-later/
- https://www.reddit.com/r/programming/comments/wiztpx/redis_hits_back_at_dragonfly/
