Project Icon

KeyDB

Redis分支KeyDB多线程高性能内存数据库

KeyDB是Redis的高性能分支,专注多线程、内存效率和高吞吐量。它提供主动复制、FLASH存储等特性,保持与Redis完全兼容。KeyDB采用MVCC架构,可执行KEYS和SCAN查询而不阻塞数据库。在相同硬件上实现更高吞吐量,简化热备份,降低运营成本。KeyDB支持主动-主动复制、子键过期等创新特性,适用于需要高吞吐量、低延迟的大规模分布式系统。

当前版本 CI StackShare

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

查看完整的基准测试结果和设置信息: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 32bitmake 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文件。

项目侧边栏1项目侧边栏2
推荐项目
Project Cover

豆包MarsCode

豆包 MarsCode 是一款革命性的编程助手,通过AI技术提供代码补全、单测生成、代码解释和智能问答等功能,支持100+编程语言,与主流编辑器无缝集成,显著提升开发效率和代码质量。

Project Cover

AI写歌

Suno AI是一个革命性的AI音乐创作平台,能在短短30秒内帮助用户创作出一首完整的歌曲。无论是寻找创作灵感还是需要快速制作音乐,Suno AI都是音乐爱好者和专业人士的理想选择。

Project Cover

有言AI

有言平台提供一站式AIGC视频创作解决方案,通过智能技术简化视频制作流程。无论是企业宣传还是个人分享,有言都能帮助用户快速、轻松地制作出专业级别的视频内容。

Project Cover

Kimi

Kimi AI助手提供多语言对话支持,能够阅读和理解用户上传的文件内容,解析网页信息,并结合搜索结果为用户提供详尽的答案。无论是日常咨询还是专业问题,Kimi都能以友好、专业的方式提供帮助。

Project Cover

阿里绘蛙

绘蛙是阿里巴巴集团推出的革命性AI电商营销平台。利用尖端人工智能技术,为商家提供一键生成商品图和营销文案的服务,显著提升内容创作效率和营销效果。适用于淘宝、天猫等电商平台,让商品第一时间被种草。

Project Cover

吐司

探索Tensor.Art平台的独特AI模型,免费访问各种图像生成与AI训练工具,从Stable Diffusion等基础模型开始,轻松实现创新图像生成。体验前沿的AI技术,推动个人和企业的创新发展。

Project Cover

SubCat字幕猫

SubCat字幕猫APP是一款创新的视频播放器,它将改变您观看视频的方式!SubCat结合了先进的人工智能技术,为您提供即时视频字幕翻译,无论是本地视频还是网络流媒体,让您轻松享受各种语言的内容。

Project Cover

美间AI

美间AI创意设计平台,利用前沿AI技术,为设计师和营销人员提供一站式设计解决方案。从智能海报到3D效果图,再到文案生成,美间让创意设计更简单、更高效。

Project Cover

AIWritePaper论文写作

AIWritePaper论文写作是一站式AI论文写作辅助工具,简化了选题、文献检索至论文撰写的整个过程。通过简单设定,平台可快速生成高质量论文大纲和全文,配合图表、参考文献等一应俱全,同时提供开题报告和答辩PPT等增值服务,保障数据安全,有效提升写作效率和论文质量。

投诉举报邮箱: service@vectorlightyear.com
@2024 懂AI·鲁ICP备2024100362号-6·鲁公网安备37021002001498号