KeyDB是Redis 的一个高性能分支，专注于多线程、内存效率和高吞吐量

KeyDB 是什么？

KeyDB 是 Redis 的一个高性能分支，专注于多线程、内存效率和高吞吐量。除了性能改进外，KeyDB 还提供了活跃复制、FLASH 存储和子键过期等功能。KeyDB 采用了 MVCC 架构，允许您执行 KEYS 和 SCAN 等查询，而不会阻塞数据库并降低性能。

KeyDB 完全兼容 Redis 协议、模块和脚本。这包括脚本和事务的原子性保证。因为 KeyDB 与 Redis 的发展保持同步，所以 KeyDB 是 Redis 功能的超集，使得 KeyDB 可以无缝替换现有的 Redis 部署。

在相同的硬件上，KeyDB 的吞吐量显著高于 Redis。活跃复制简化了热备份故障转移，使您可以轻松地在副本上分配写操作，并使用基于 TCP 的负载均衡/故障转移。KeyDB 更高的性能让您可以用更少的硬件做更多的事情，从而降低运营成本和复杂性。

下面的图表比较了几种 KeyDB 和 Redis 的设置，包括最新的 Redis6 io-threads 选项和 TLS 基准测试。

完整的基准测试结果和设置信息请见这里: https://docs.keydb.dev/blog/2020/09/29/blog-post/

为什么要分支 Redis？

KeyDB 对代码库应该如何发展有不同的哲学观点。我们认为易用性、高性能和“一揽子”方法是创造良好用户体验的最佳方式。尽管我们非常尊重 Redis 的维护者，但我们认为 Redis 的方法过于关注代码库的简单性，而牺牲了用户的复杂性。这导致需要外部组件和解决方案来解决常见问题，从而整体上增加了更多的复杂性。

由于这种意见分歧，适合 KeyDB 的功能可能不适合 Redis。分支允许我们探索这一新的开发路径，并实现可能永远不会成为 Redis 一部分的功能。KeyDB 与上游 Redis 的变化保持同步，适用的情况下，我们会将错误修复和更改上游。我们希望这两个项目能够继续成长并相互学习。

项目支持KeyDB 团队作为 Snap Inc. 的一部分维护这个项目。KeyDB 被 Snap 用作其缓存基础设施的一部分，并且完全开源。没有单独的商业产品和付费支持选项。我们非常重视与开源社区的合作，并欢迎 PR、错误报告和公开讨论。欲了解更多社区支持或进一步参与项目，请查看我们的社区支持选项（slack、论坛、meetup、github 问题）。我们的团队会定期监控这些渠道。

基准测试 KeyDB

请注意，keydb-benchmark 和 redis-benchmark 目前是单线程的，速度太慢，无法正确基准测试 KeyDB。我们建议使用如 memtier 这样的 redis 集群基准测试工具。如果在本地测试，请确保您的机器有足够的核心供 KeyDB 和 memtier 使用。KeyDB 期望独占分配给它的任何核心。

新的配置选项

随着新功能的出现，也有了新的选项。所有其他配置选项的行为与您所期望的一样。您现有的配置文件应该继续无变化地工作。

用于服务请求的线程数量。这应该与您的网络硬件中可用的队列数量相关，而不是您机器上的核心数量。因为 KeyDB 使用自旋锁来降低延迟；如果设置得太高，将降低性能。我们建议在这里使用 4。默认情况下，这被设置为两个。
线程上的最小客户端数量在 KeyDB 将新连接分配给不同线程之前。调整此参数是在锁定开销和在多个核心上分配工作负载之间的权衡
KeyDB 将尝试平均地在线程之间平衡客户端；然而，副本客户端通常比普通客户端更昂贵，因此 KeyDB 将尝试向有副本的线程分配更少的客户端。下面的加权因子旨在帮助调整这种行为。副本加权因子为 2 意味着我们将副本视为两个普通客户端。调整这个值可能在使用复制时提高性能。最佳加权因子取决于工作负载 - 例如，以读为主的工作负载应将其设置为 1。非常以写为主的工作负载可能会从更高的数字中受益。
KeyDB 应该主动尝试在线程之间平衡客户端吗？这可能会影响接受新客户端的性能。默认情况下，这是启用的。如果禁用，即使没有 SO_REUSEPORT，内核也会尽最大努力在线程之间分配，但不会那么公平。默认情况下，这是启用的

如果您正在使用活跃-活跃复制，请将 active-replica 选项设置为yes。这将启用两个实例接受读写操作，同时保持同步。

避免将 RREPLAY 消息转发给其他主服务器？警告：这个设置很危险！您必须确定所有主服务器都以真正的网状拓扑连接在一起，否则会发生数据丢失！这个命令可以用来减少多主总线流量

如果您希望 KeyDB 直接向 AWS S3 转储和加载，此选项指定存储桶。将此选项与传统的 RDB 选项一起使用将导致 KeyDB 同时备份到两个位置。如果两者都指定了，KeyDB 将首先尝试从本地转储文件加载，如果失败，则从 S3 加载。这需要安装和配置 AWS CLI 工具，这些工具在底层用于传输数据。
如果您想使用 KeyDB FLASH 存储，请指定存储介质，后跟您本地 SSD 卷上的目录路径。请注意，这个功能仍然被认为是实验性的，应该谨慎使用。有关配置和设置您的 FLASH 卷的更多细节，请参阅 FLASH 文档。

多线程架构

KeyDB 通过在多个线程上运行正常的 Redis 事件循环来工作。网络 IO 和查询解析是同时进行的。每个连接在 accept() 时被分配一个线程。对核心哈希表的访问由自旋锁保护。由于哈希表访问非常快，这个锁的争用很低。事务在 EXEC 命令的持续期间持有锁。模块与 GIL 协同工作，后者仅在所有服务器线程暂停时获得。这样可以维护模块所期望的原子性保证。

与大多数数据库不同，核心数据结构是系统中最快的部分。大部分查询时间来自于解析 REPL 协议和将数据复制到/从网络复制。

总结

KeyDB 是一个基于 Redis 的高性能分支，专注于多线程、内存效率和高吞吐量。它保持对 Redis 协议、模块和脚本的完全兼容性，并在性能上显著超过 Redis。KeyDB 的多线程架构允许并发网络 IO 和查询解析，且核心数据结构访问非常快速。此外，KeyDB 还引入了一些新的配置选项和功能，如活跃复制、AWS S3 直接存储和 FLASH 存储等。KeyDB 项目完全开源，遵循 BSD 许可证，欢迎社区贡献代码。

英文原文：https://github.com/Snapchat/KeyDB

原文始发于微信公众号（运维帮）：KeyDB是Redis 的一个高性能分支，专注于多线程、内存效率和高吞吐量