如果我告诉你有一个分支版本的Redis，它的性能比原来的Redis快了5倍，延迟接近5倍低，你想看看这个项目吗？如果您不再需要哨兵节点并且您的副本可以接受读写，这可能会将分片数量减少10倍，它对您是否更有吸引力？它有多大？我说的分支版本实际上是Redis的一个分支版本，叫做KeyDB。KeyDB是Redis的开源多线程分支。在这篇文章中，我们展示了最新的基准测试结果，并讨论了更强大的KeyDB实例如何减少集群大小并简化堆栈。同时，我们还将讨论多线程架构并演练如何使用它来实现性能提升。为什么是一个新名字，为什么是Redis的一个分支？凭借我们不受限制的代码库开发能力，KeyDB能够在短时间内取得长足进步，其所走的道路将在未来几个月内揭晓摧毁整个数据库格局。至于之所以先建立一个Redisfork，是因为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倍。
