我说的这个分支版本，它其实是 Redis 的一个分叉版本，名叫 KeyDB 。KeyDB 是 Redis 开源的多线程分叉版本。本文我们将提供最新的基准测试结果，并讨论更强大的 KeyDB 实例如何减少集群大小以及简化堆栈。同时我们还将讨论了多线程体系结构，并演练了如何利用它实现性能的提升。
为什么要取个新名字，为什么要做 Redis 的分叉?
凭借着我们不受限制的代码库开发能力，KeyDB 能够在短时间内取得长足的进步，并且所走的道路将在未来几个月内破坏整个数据库格局。
关于为什么首先搞一个 Redis 分叉的原因，这是因为 KeyDB 和 Redis 在如何发展方面有不同的理念。我们认为易用性、高性能和“内置动力”的方法是创造良好用户体验的最佳方法。尽管我们非常尊重 Redis 维护者，但我们认为 Redis 的方法过于注重代码的简单性，而以牺牲用户的便利性为代价。这导致经常需要借助外部组件和方案来解决很多常见问题。
由于存在意见分歧，因此适合 KeyDB 的功能可能不适用于 Redis。而做一个新的分叉版本可以允许我们探索这一新的开发路径并实现可能永远不会成为 Redis 一部分的功能。KeyDB 将与上游的 Redis 代码变更保持同步，在适用的情况下，我们还给 Redis 提交错误修复和改进。我们希望这两个项目能够继续发展并相互学习。
最新基准数据
KeyDB 于今年3月推出，尽管我们的性能有所提高，但我们仍然希望它能更快地发展。我们最新的基准测试数据显示，KeyDB的单个实例的每秒操作数(图范围为53-5.49)比Redis(v5)的单个实例多5倍以上，而延迟(图形范围为4.6-5.1)近5倍：
多线程的优势
增加 KeyDB 的单个实例/节点的功能可以减少分片的需要，并且可以大大减少数据移动的数量。您可能会问，与在单个节点上多线程化相比，在群集中运行许多Redis 节点是否可以获得比单线程多线程更多的吞吐量?您可以像 Redis 一样对 KeyDB 进行分片，这对数据库进行水平扩展很有意义。但是，如果您可以选择增加马力而不购买第二辆车，那为什么不呢?除分片外，还能够扩展节点的大小，为用户增加了新的功能和选择。这是 Redis 与 KeyDB 之间意见分歧的其中之一。这不仅是社区中的常见讨论点，还是某些圈子中的争论点。
因此，为了回答 “用 KeyDB 运行更多线程看起来像什么?” 这个问题，我们提供了一些基本数字，以便您对此问题有所了解。
以下是基准测试(操作/秒)与使用的线程数对应关系的图表：
随着分配更多资源给实例，您可以看到性能得到大幅提高。同时还可以可以将线程固定到某个CPU上以得到进一步的提升，但最适合您的选择可能取决于您的设置。默认情况下，此选项是禁用的。
仅将一个线程分配给KeyDB，平均而言，与 Redis 的单个线程实例相比，它仍可保持约5%的性能提升。因此，即使添加了新功能并更改了体系结构，性能也没有受到影响。
多线程架构
KeyDB 通过在多个线程上运行常规的 Redis 事件循环来工作。网络 IO 和查询解析是同时进行的。每个连接在 accept() 上分配一个线程。自旋锁保护对核心哈希表的访问。因为哈希表访问非常快，所以此锁的争用较低。事务在EXEC命令的持续时间内保持锁定。模块与GIL协同工作，而GIL仅在所有服务器线程都暂停时才获取。这保持了模块期望的原子性保证。
与大多数数据库不同，核心数据结构是系统中最快的部分。查询的大部分时间来自解析REPL协议并将数据复制到网络或从网络复制数据。
未来的工作包括允许在连接之后重新平衡与不同线程的连接，并允许多个读取器同时访问哈希表
进一步优化设置
此外，KeyDB 还提供了一些有助于简化用户体验的功能。例如活动副本功能已在最新的稳定版本 5 中广泛采用并在生产中使用。此功能使您能够在两个主节点彼此复制，同时接受读取和写入操作。而且不需要哨点节点来控制故障转移。您将获得很高的可用性，同时最大限度地利用资源。如果尚未平衡对副本节点的读取，则可以使用此选项将吞吐量提高一倍。这意味着从简单的 Redis 主副本设置转移到使用 KeyDB 的多线程活动副本设置，可以将分片需求减少多达10倍。
