KeyDB

KeyDB现已成为Snap Inc.的一部分！查看此处的公告

版本v6.3.0现已发布，带来重大改进，我们将开源版和企业版整合为单一的BSD-3许可项目。查看我们的路线图了解详情。

想用JavaScript扩展KeyDB？试试ModJS

需要帮助？查看我们详尽的文档。

KeyDB已加入Slack。点击这里了解更多并加入KeyDB社区Slack工作空间。

什么是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基准测试。

<img src="https://yellow-cdn.veclightyear.com/835a84d5/bb56a583-4dbb-4c95-bea6-4aeb86465fd9.png"/>

查看完整的基准测试结果和设置信息：https://docs.keydb.dev/blog/2020/09/29/blog-post/

为什么要分叉Redis？

KeyDB对代码库应如何发展有不同的理念。我们认为易用性、高性能和"功能齐全"的方法是创造良好用户体验的最佳途径。虽然我们非常尊重Redis的维护者，但我们认为Redis的方法过于注重代码库的简单性，而牺牲了用户的便利性。这导致需要外部组件和变通方法来解决常见问题 - 最终导致整体复杂性增加。

由于这种观点的差异，适合KeyDB的功能可能不适合Redis。分叉允许我们探索这条新的开发路径，并实现可能永远不会成为Redis一部分的功能。KeyDB与上游Redis变更保持同步，在适用的情况下，我们会向上游提交bug修复和变更。我们希望两个项目能继续成长并相互学习。

项目支持

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

额外资源

尝试KeyDB的Docker镜像

加入我们的Slack

通过KeyDB详尽的文档了解更多

查看KeyDB路线图，了解未来计划

KeyDB基准测试

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

新配置选项

新功能带来了新选项。所有其他配置选项的行为与您预期的一样。您现有的配置文件应该可以继续使用，无需更改。

    server-threads N
    server-thread-affinity [true/false]

用于处理请求的线程数。这应该与网络硬件中可用的队列数量相关，而不是机器的核心数。因为KeyDB使用自旋锁来减少延迟；设置得过高会降低性能。我们建议在这里使用4。默认设置为2。

min-clients-per-thread 50

在KeyDB将新连接分配到不同线程之前，一个线程上的最小客户端数。调整此参数是在锁定开销和在多个核心上分配工作负载之间的权衡

replica-weighting-factor 2

KeyDB将尝试在线程之间均衡分配客户端；然而，副本客户端通常比普通客户端昂贵得多，因此KeyDB会尝试为有副本的线程分配较少的客户端。下面的权重因子旨在帮助调整这种行为。副本权重因子为2意味着我们将一个副本视为相当于两个普通客户端。当使用复制时，调整这个值可能会提高性能。最佳权重是特定于工作负载的 - 例如，读取密集型工作负载应将其设置为1。非常写入密集型的工作负载可能会从更高的数字中受益。

active-client-balancing yes

KeyDB是否应该积极尝试在线程之间平衡客户端？这可能会影响接受新客户端的性能。默认情况下，这是启用的。如果禁用，内核仍会通过SO_REUSEPORT尽最大努力分配线程，但分配不会那么公平。默认情况下，这是启用的

    active-replica yes

如果您使用主动-主动复制，请将active-replica选项设置为"yes"。这将使两个实例都能接受读写操作，同时保持同步。点击这里在我们的文档部分查看更多关于主动复制的信息。文档中还有docker示例。

multi-master-no-forward no

避免将RREPLAY消息转发给其他主节点？警告：此设置很危险！您必须确保所有主节点以真正的网状拓扑相互连接，否则将发生数据丢失！此命令可用于减少多主总线流量

    db-s3-object /path/to/bucket

如果您希望KeyDB直接转储和加载到AWS S3，此选项指定存储桶。将此选项与传统RDB选项一起使用将导致KeyDB备份两次到两个位置。如果两者都指定，KeyDB将首先尝试从本地转储文件加载，如果失败，则从S3加载。这需要安装和配置AWS CLI工具，这些工具在底层用于传输数据。

storage-provider flash /path/to/flash

如果您想使用KeyDB FLASH存储，请指定存储介质，后跟本地SSD卷上的目录路径。请注意，此功能仍被视为实验性的，应谨慎使用。有关配置和设置FLASH卷的更多详细信息，请参阅FLASH文档。

构建KeyDB

KeyDB可以在Linux上编译和测试使用。KeyDB目前依赖于SO_REUSEPORT的负载均衡行为，这仅在Linux上可用。当我们支持跨线程编组连接时，我们计划支持其他操作系统，如FreeBSD。

有关CentOS/Archlinux/Alpine/Debian/Ubuntu的依赖项和构建的更多信息可以在这里找到：https://docs.keydb.dev/docs/build/

初始化并克隆子模块依赖项：

% git submodule init && git submodule update

安装依赖项：

% sudo apt install build-essential nasm autotools-dev autoconf libjemalloc-dev tcl tcl-dev uuid-dev libcurl4-openssl-dev libbz2-dev libzstd-dev liblz4-dev libsnappy-dev libssl-dev

编译非常简单：

% make

要构建支持systemd的版本，您需要systemd开发库（如Debian/Ubuntu上的libsystemd-dev或CentOS上的systemd-devel）并运行：

% make USE_SYSTEMD=yes

要为KeyDB程序名称添加后缀，请使用：

% make PROG_SUFFIX="-alt"

***注意可能需要以下依赖项： % sudo apt-get install autoconf autotools-dev libnuma-dev libtool

KeyDB默认构建时启用TLS。要构建不支持TLS的版本，请使用：

% make BUILD_TLS=no

使用启用TLS的版本运行测试（您需要安装tcl-tls）：

% ./utils/gen-test-certs.sh
% ./runtest --tls

要构建支持KeyDB FLASH的版本，请使用：

% make ENABLE_FLASH=yes

***请注意，KeyDB FLASH功能被视为实验性（测试版），应谨慎使用

修复依赖项或缓存的构建选项导致的构建问题

KeyDB有一些包含在deps目录中的依赖项。 即使依赖项的源代码发生变化，make也不会自动重新构建依赖项。

当您使用git pull更新源代码时，或者当依赖项树中的代码以任何其他方式被修改时，请确保使用以下命令真正清理所有内容并从头开始重新构建：

make distclean

这将清理：jemalloc、lua、hiredis、linenoise。

此外，如果您强制使用某些构建选项，如32位目标、无C编译器优化（用于调试目的）以及其他类似的构建时选项，这些选项会无限期缓存，直到您发出make distclean命令。

修复构建32位二进制文件的问题

如果在使用32位目标构建KeyDB后需要重新构建为64位目标，或者反之，您需要在KeyDB分发包的根目录执行make distclean。

如果在尝试构建KeyDB的32位二进制文件时遇到构建错误，请尝试以下步骤：

• 安装libc6-dev-i386包（也可以尝试g++-multilib）。
• 尝试使用以下命令行代替make 32bit： make CFLAGS="-m32 -march=native" LDFLAGS="-m32"

分配器

在构建KeyDB时选择非默认内存分配器是通过设置MALLOC环境变量来完成的。默认情况下，KeyDB会编译并链接到libc malloc，但在Linux系统上默认使用jemalloc。之所以选择这个默认值，是因为jemalloc已被证明比libc malloc具有更少的碎片问题。

要强制编译使用libc malloc，请使用：

% make MALLOC=libc

要在Mac OS X系统上编译使用jemalloc，请使用：

% make MALLOC=jemalloc

单调时钟

默认情况下，KeyDB将使用POSIX的clock_gettime函数作为单调时钟源。在大多数现代系统上，可以使用内部处理器时钟来提高性能。相关注意事项可以在这里找到： http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/

要构建支持处理器内部指令时钟，请使用：

% make CFLAGS="-DUSE_PROCESSOR_CLOCK"

详细构建

默认情况下，KeyDB将以用户友好的彩色输出进行构建。 如果您想看到更详细的输出，请使用以下命令：

% make V=1

运行KeyDB

要使用默认配置运行KeyDB，只需输入：

% cd src
% ./keydb-server

如果您想提供自己的keydb.conf，您需要使用额外的参数（配置文件的路径）运行：

% cd src
% ./keydb-server /path/to/keydb.conf

可以通过直接在命令行中传递参数作为选项来更改KeyDB配置。例如：

% ./keydb-server --port 9999 --replicaof 127.0.0.1 6379
% ./keydb-server /etc/keydb/6379.conf --loglevel debug

keydb.conf中的所有选项也都支持作为命令行选项使用，名称完全相同。

使用TLS运行KeyDB：

请参阅TLS.md文件，了解如何使用TLS运行KeyDB的更多信息。

使用KeyDB

您可以使用keydb-cli与KeyDB交互。启动一个keydb-server实例，然后在另一个终端中尝试以下操作：

% cd src
% ./keydb-cli
keydb> ping
PONG
keydb> set foo bar
OK
keydb> get foo
"bar"
keydb> incr mycounter
(integer) 1
keydb> incr mycounter
(integer) 2
keydb>

您可以在https://docs.keydb.dev/docs/commands/找到所有可用命令的列表。

安装KeyDB

要将KeyDB二进制文件安装到/usr/local/bin，只需使用：

% make install

如果您希望使用不同的目标目录，可以使用make PREFIX=/some/other/directory install。

make install只会在您的系统中安装二进制文件，但不会在适当的位置配置初始化脚本和配置文件。如果您只是想稍微尝试一下KeyDB，这不是必需的，但如果您要为生产系统正确安装它，我们有一个脚本可以为Ubuntu和Debian系统执行此操作：

% cd utils
% ./install_server.sh

注意：install_server.sh在Mac OSX上不起作用；它只为Linux设计。

该脚本会问您几个问题，并设置运行KeyDB所需的一切，使其作为后台守护进程正常运行，并在系统重启时再次启动。

您可以使用名为/etc/init.d/keydb_<portnumber>的脚本来停止和启动KeyDB，例如/etc/init.d/keydb_6379。

多线程架构

KeyDB通过在多个线程上运行普通的Redis事件循环来工作。网络IO和查询解析是并发进行的。每个连接在接受时都会分配一个线程。对核心哈希表的访问由自旋锁保护。由于哈希表访问极快，这个锁的争用很低。事务在EXEC命令的持续时间内持有锁。模块与全局解释器锁（GIL）协同工作，只有在所有服务器线程暂停时才获取GIL。这保持了模块期望的原子性保证。

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

代码贡献

注意：通过任何形式向KeyDB项目贡献代码，包括通过Github发送拉取请求、通过私人电子邮件或公共讨论组发送代码片段或补丁，您同意根据BSD许可证的条款发布您的代码，该许可证可以在KeyDB源代码分发包中的COPYING文件中找到。

更多信息请参阅本源代码分发包中的CONTRIBUTING文件。