{ "componentChunkName": "component---src-templates-issues-tsx", "path": "/issues/282", "result": {"data":{"issuesJson":{"id":"2434a038-b038-5909-9a8c-c7cf6fc5c90b","title":"Snapchat/KeyDB: KeyDB 是 Redis 的高性能分支，专注于多线程、内存效率和高吞吐量。除了性能改进之外，KeyDB 还提供主动复制、闪存存储和子密钥过期等功能。","number":282,"bodyHTML":"
\n



\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ReposSnapchat/KeyDB
Views\"views\"
Stars\"stars\"
Forks\"forks\"
License\"license\"
UpdatedAt\"last-commit\"
CreatedAt\"create-at\"
\n\n

\"\"

\n\n
\n

\"Current
\n\"CI\"
\n\"StackShare\"

\n
KeyDB is now a part of Snap Inc! Check out the announcement here
\n
Release v6.3.0 is here with major improvements as we consolidate our Open Source and Enterprise offerings into a single BSD-3 licensed project. See our roadmap for details.
\n
Want to extend KeyDB with Javascript? Try ModJS
\n
Need Help? Check out our extensive documentation.
\n
KeyDB is on Slack. Click here to learn more and join the KeyDB Community Slack workspace.
\n

What is KeyDB?

\n

KeyDB is a high performance fork of Redis with a focus on multithreading, memory efficiency, and high throughput. In addition to performance improvements, KeyDB offers features such as Active Replication, FLASH Storage and Subkey Expires. KeyDB has a MVCC architecture that allows you to execute queries such as KEYS and SCAN without blocking the database and degrading performance.

\n

KeyDB maintains full compatibility with the Redis protocol, modules, and scripts. This includes the atomicity guarantees for scripts and transactions. Because KeyDB keeps in sync with Redis development KeyDB is a superset of Redis functionality, making KeyDB a drop in replacement for existing Redis deployments.

\n

On the same hardware KeyDB can achieve significantly higher throughput than Redis. Active-Replication simplifies hot-spare failover allowing you to easily distribute writes over replicas and use simple TCP based load balancing/failover. KeyDB's higher performance allows you to do more on less hardware which reduces operation costs and complexity.

\n

The chart below compares several KeyDB and Redis setups, including the latest Redis6 io-threads option, and TLS benchmarks.

\n

\n

See the full benchmark results and setup information here: https://docs.keydb.dev/blog/2020/09/29/blog-post/

\n

Why fork Redis?

\n

KeyDB has a different philosophy on how the codebase should evolve. We feel that ease of use, high performance, and a \"batteries included\" approach is the best way to create a good user experience. While we have great respect for the Redis maintainers it is our opinion that the Redis approach focuses too much on simplicity of the code base at the expense of complexity for the user. This results in the need for external components and workarounds to solve common problems - resulting in more complexity overall.

\n

Because of this difference of opinion features which are right for KeyDB may not be appropriate for Redis. A fork allows us to explore this new development path and implement features which may never be a part of Redis. KeyDB keeps in sync with upstream Redis changes, and where applicable we upstream bug fixes and changes. It is our hope that the two projects can continue to grow and learn from each other.

\n

Project Support

\n

The KeyDB team maintains this project as part of Snap Inc. KeyDB is used by Snap as part of its caching infrastructure and is fully open sourced. There is no separate commercial product and no paid support options available. We really value collaborating with the open source community and welcome PRs, bug reports, and open discussion. For community support or to get involved further with the project check out our community support options here (slack, forum, meetup, github issues). Our team monitors these channels regularly.

\n

Additional Resources

\n

Try the KeyDB Docker Image

\n

Join us on Slack

\n

Learn more using KeyDB's extensive documentation

\n

See the KeyDB Roadmap to see what's in store

\n

Benchmarking KeyDB

\n

Please note keydb-benchmark and redis-benchmark are currently single threaded and too slow to properly benchmark KeyDB. We recommend using a redis cluster benchmark tool such as memtier. Please ensure your machine has enough cores for both KeyDB and memtier if testing locally. KeyDB expects exclusive use of any cores assigned to it.

\n

New Configuration Options

\n

With new features comes new options. All other configuration options behave as you'd expect. Your existing configuration files should continue to work unchanged.

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

The number of threads used to serve requests. This should be related to the number of queues available in your network hardware, not the number of cores on your
\nmachine. Because KeyDB uses spinlocks to reduce latency; making this too high will reduce performance. We recommend using 4 here. By default this is set to two.

\n
min-clients-per-thread 50\n
\n

The minimum number of clients on a thread before KeyDB assigns new connections to a different thread. Tuning this parameter is a tradeoff between locking overhead and distributing the workload over multiple cores

\n
replica-weighting-factor 2\n
\n

KeyDB will attempt to balance clients across threads evenly; However, replica clients are usually much more expensive than a normal client, and so KeyDB will try to assign fewer clients to threads with a replica. The weighting factor below is intended to help tune this behavior. A replica weighting factor of 2 means we treat a replica as the equivalent of two normal clients. Adjusting this value may improve performance when replication is used. The best weighting is workload specific - e.g. read heavy workloads should set this to 1. Very write heavy workloads may benefit from higher numbers.

\n
active-client-balancing yes\n
\n

Should KeyDB make active attempts at balancing clients across threads? This can impact performance accepting new clients. By default this is enabled. If disabled there is still a best effort from the kernel to distribute across threads with SO_REUSEPORT but it will not be as fair. By default this is enabled

\n
    active-replica yes\n
\n

If you are using active-active replication set active-replica option to “yes”. This will enable both instances to accept reads and writes while remaining synced. Click here to see more on active-rep in our docs section. There are also docker examples on docs.

\n
multi-master-no-forward no\n
\n

Avoid forwarding RREPLAY messages to other masters? WARNING: This setting is dangerous! You must be certain all masters are connected to eachother in a true mesh topology or data loss will occur! This command can be used to reduce multimaster bus traffic

\n
    db-s3-object /path/to/bucket\n
\n

If you would like KeyDB to dump and load directly to AWS S3 this option specifies the bucket. Using this option with the traditional RDB options will result in KeyDB backing up twice to both locations. If both are specified KeyDB will first attempt to load from the local dump file and if that fails load from S3. This requires the AWS CLI tools to be installed and configured which are used under the hood to transfer the data.

\n
storage-provider flash /path/to/flash\n
\n

If you would like to use KeyDB FLASH storage, specify the storage medium followed by the directory path on your local SSD volume. Note that this feature is still considered experimental and should be used with discretion. See FLASH Documentation for more details on configuration and setting up your FLASH volume.

\n

Building KeyDB

\n

KeyDB can be compiled and is tested for use on Linux. KeyDB currently relies on SO_REUSEPORT's load balancing behavior which is available only in Linux. When we support marshalling connections across threads we plan to support other operating systems such as FreeBSD.

\n

More on CentOS/Archlinux/Alpine/Debian/Ubuntu dependencies and builds can be found here: https://docs.keydb.dev/docs/build/

\n

Init and clone submodule dependencies:

\n
% git submodule init && git submodule update\n
\n

Install dependencies:

\n
% 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\n
\n

Compiling is as simple as:

\n
% make\n
\n

To build with systemd support, you'll need systemd development libraries (such
\nas libsystemd-dev on Debian/Ubuntu or systemd-devel on CentOS) and run:

\n
% make USE_SYSTEMD=yes\n
\n

To append a suffix to KeyDB program names, use:

\n
% make PROG_SUFFIX=\"-alt\"\n
\n

***Note that the following dependencies may be needed:
\n% sudo apt-get install autoconf autotools-dev libnuma-dev libtool

\n

KeyDB by default is built with TLS enabled. To build without TLS support, use:

\n
% make BUILD_TLS=no\n
\n

Running the tests with TLS enabled (you will need tcl-tls
\ninstalled):

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

To build with KeyDB FLASH support, use:

\n
% make ENABLE_FLASH=yes\n
\n

***Note that the KeyDB FLASH feature is considered experimental (beta) and should used with discretion

\n

Fixing build problems with dependencies or cached build options

\n

KeyDB has some dependencies which are included in the deps directory.
\nmake does not automatically rebuild dependencies even if something in
\nthe source code of dependencies changes.

\n

When you update the source code with git pull or when code inside the
\ndependencies tree is modified in any other way, make sure to use the following
\ncommand in order to really clean everything and rebuild from scratch:

\n
make distclean\n
\n

This will clean: jemalloc, lua, hiredis, linenoise.

\n

Also if you force certain build options like 32bit target, no C compiler
\noptimizations (for debugging purposes), and other similar build time options,
\nthose options are cached indefinitely until you issue a make distclean
\ncommand.

\n

Fixing problems building 32 bit binaries

\n

If after building KeyDB with a 32 bit target you need to rebuild it
\nwith a 64 bit target, or the other way around, you need to perform a
\nmake distclean in the root directory of the KeyDB distribution.

\n

In case of build errors when trying to build a 32 bit binary of KeyDB, try
\nthe following steps:

\n\n

Allocator

\n

Selecting a non-default memory allocator when building KeyDB is done by setting
\nthe MALLOC environment variable. KeyDB is compiled and linked against libc
\nmalloc by default, with the exception of jemalloc being the default on Linux
\nsystems. This default was picked because jemalloc has proven to have fewer
\nfragmentation problems than libc malloc.

\n

To force compiling against libc malloc, use:

\n
% make MALLOC=libc\n
\n

To compile against jemalloc on Mac OS X systems, use:

\n
% make MALLOC=jemalloc\n
\n

Monotonic clock

\n

By default, KeyDB will build using the POSIX clock_gettime function as the
\nmonotonic clock source. On most modern systems, the internal processor clock
\ncan be used to improve performance. Cautions can be found here:
\nhttp://oliveryang.net/2015/09/pitfalls-of-TSC-usage/

\n

To build with support for the processor's internal instruction clock, use:

\n
% make CFLAGS=\"-DUSE_PROCESSOR_CLOCK\"\n
\n

Verbose build

\n

KeyDB will build with a user friendly colorized output by default.
\nIf you want to see a more verbose output, use the following:

\n
% make V=1\n
\n

Running KeyDB

\n

To run KeyDB with the default configuration, just type:

\n
% cd src\n% ./keydb-server\n
\n

If you want to provide your keydb.conf, you have to run it using an additional
\nparameter (the path of the configuration file):

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

It is possible to alter the KeyDB configuration by passing parameters directly
\nas options using the command line. Examples:

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

All the options in keydb.conf are also supported as options using the command
\nline, with exactly the same name.

\n

Running KeyDB with TLS:

\n

Please consult the TLS.md file for more information on
\nhow to use KeyDB with TLS.

\n

Playing with KeyDB

\n

You can use keydb-cli to play with KeyDB. Start a keydb-server instance,
\nthen in another terminal try the following:

\n
% cd src\n% ./keydb-cli\nkeydb> ping\nPONG\nkeydb> set foo bar\nOK\nkeydb> get foo\n\"bar\"\nkeydb> incr mycounter\n(integer) 1\nkeydb> incr mycounter\n(integer) 2\nkeydb>\n
\n

You can find the list of all the available commands at https://docs.keydb.dev/docs/commands/

\n

Installing KeyDB

\n

In order to install KeyDB binaries into /usr/local/bin, just use:

\n
% make install\n
\n

You can use make PREFIX=/some/other/directory install if you wish to use a
\ndifferent destination.

\n

Make install will just install binaries in your system, but will not configure
\ninit scripts and configuration files in the appropriate place. This is not
\nneeded if you just want to play a bit with KeyDB, but if you are installing
\nit the proper way for a production system, we have a script that does this
\nfor Ubuntu and Debian systems:

\n
% cd utils\n% ./install_server.sh\n
\n

Note: install_server.sh will not work on Mac OSX; it is built for Linux only.

\n

The script will ask you a few questions and will setup everything you need
\nto run KeyDB properly as a background daemon that will start again on
\nsystem reboots.

\n

You'll be able to stop and start KeyDB using the script named
\n/etc/init.d/keydb_<portnumber>, for instance /etc/init.d/keydb_6379.

\n

Multithreading Architecture

\n

KeyDB works by running the normal Redis event loop on multiple threads. Network IO, and query parsing are done concurrently. Each connection is assigned a thread on accept(). Access to the core hash table is guarded by spinlock. Because the hashtable access is extremely fast this lock has low contention. Transactions hold the lock for the duration of the EXEC command. Modules work in concert with the GIL which is only acquired when all server threads are paused. This maintains the atomicity guarantees modules expect.

\n

Unlike most databases the core data structure is the fastest part of the system. Most of the query time comes from parsing the REPL protocol and copying data to/from the network.

\n

Code contributions

\n

Note: by contributing code to the KeyDB project in any form, including sending
\na pull request via Github, a code fragment or patch via private email or
\npublic discussion groups, you agree to release your code under the terms
\nof the BSD license that you can find in the COPYING file included in the KeyDB
\nsource distribution.

\n

Please see the CONTRIBUTING file in this source distribution for more
\ninformation.

","updatedAt":"2025-05-21T16:05:39Z","upvoteCount":null,"author":{"login":"eryajf","avatarUrl":"https://avatars.githubusercontent.com/u/33259379?u=e4a4090a38ac2473aaed4ef9945233636776c6c3&v=4","url":"https://github.com/eryajf"},"category":null,"labels":{"edges":[{"node":{"name":"更多","color":"25B472"}},{"node":{"name":"Database","color":"3fbc9d"}},{"node":{"name":"Snapchat","color":"994f29"}}]},"comments":{"edges":[]}}},"pageContext":{"number":282,"previous":{"title":"keycloak/keycloak: Keycloak提供用户联合、强身份验证、用户管理、细粒度授权等功能","number":281},"next":{"title":"kubernetes-sigs/kind: 使用 Docker 容器作为节点，在本地快速运行起 Kubernetes 集群的工具","number":283}}}, "staticQueryHashes": ["151096407","2861350382"]}