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 转储和加载，此选项指定存储桶。
