mirror of
http://github.com/valkey-io/valkey
synced 2024-11-22 18:54:58 +00:00
7eb850ef0e
Redis provides support for blocking operations such as BLPOP or BRPOP. This operations are identical to normal LPOP and RPOP operations as long as there are elements in the target list, but if the list is empty they block waiting for new data to arrive to the list. All the clients blocked waiting for th same list are served in a FIFO way, so the first that blocked is the first to be served when there is more data pushed by another client into the list. The previous implementation of blocking operations was conceived to serve clients in the context of push operations. For for instance: 1) There is a client "A" blocked on list "foo". 2) The client "B" performs `LPUSH foo somevalue`. 3) The client "A" is served in the context of the "B" LPUSH, synchronously. Processing things in a synchronous way was useful as if "A" pushes a value that is served by "B", from the point of view of the database is a NOP (no operation) thing, that is, nothing is replicated, nothing is written in the AOF file, and so forth. However later we implemented two things: 1) Variadic LPUSH that could add multiple values to a list in the context of a single call. 2) BRPOPLPUSH that was a version of BRPOP that also provided a "PUSH" side effect when receiving data. This forced us to make the synchronous implementation more complex. If client "B" is waiting for data, and "A" pushes three elemnents in a single call, we needed to propagate an LPUSH with a missing argument in the AOF and replication link. We also needed to make sure to replicate the LPUSH side of BRPOPLPUSH, but only if in turn did not happened to serve another blocking client into another list ;) This were complex but with a few of mutually recursive functions everything worked as expected... until one day we introduced scripting in Redis. Scripting + synchronous blocking operations = Issue #614. Basically you can't "rewrite" a script to have just a partial effect on the replicas and AOF file if the script happened to serve a few blocked clients. The solution to all this problems, implemented by this commit, is to change the way we serve blocked clients. Instead of serving the blocked clients synchronously, in the context of the command performing the PUSH operation, it is now an asynchronous and iterative process: 1) If a key that has clients blocked waiting for data is the subject of a list push operation, We simply mark keys as "ready" and put it into a queue. 2) Every command pushing stuff on lists, as a variadic LPUSH, a script, or whatever it is, is replicated verbatim without any rewriting. 3) Every time a Redis command, a MULTI/EXEC block, or a script, completed its execution, we run the list of keys ready to serve blocked clients (as more data arrived), and process this list serving the blocked clients. 4) As a result of "3" maybe more keys are ready again for other clients (as a result of BRPOPLPUSH we may have push operations), so we iterate back to step "3" if it's needed. The new code has a much simpler semantics, and a simpler to understand implementation, with the disadvantage of not being able to "optmize out" a PUSH+BPOP as a No OP. This commit will be tested with care before the final merge, more tests will be added likely. |
||
---|---|---|
deps | ||
src | ||
tests | ||
utils | ||
.gitignore | ||
00-RELEASENOTES | ||
BUGS | ||
Changelog | ||
CONTRIBUTING | ||
COPYING | ||
INSTALL | ||
Makefile | ||
MANIFESTO | ||
README | ||
redis.conf | ||
runtest | ||
sentinel.conf |
Where to find complete Redis documentation? ------------------------------------------- This README is just a fast "quick start" document. You can find more detailed documentation at http://redis.io Building Redis -------------- Redis can be compiled and used on Linux, OSX, OpenBSD, NetBSD, FreeBSD. We support big endian and little endian architectures. It may compile on Solaris derived systems (for instance SmartOS) but our support for this platform is "best effort" and Redis is not guaranteed to work as well as in Linux, OSX, and *BSD there. It is as simple as: % make You can run a 32 bit Redis binary using: % make 32bit After building Redis is a good idea to test it, using: % make test NOTE: if after building Redis with a 32 bit target you need to rebuild it with a 64 bit target you need to perform a "make clean" in the root directory of the Redis distribution. Allocator --------- Selecting a non-default memory allocator when building Redis is done by setting the `MALLOC` environment variable. Redis is compiled and linked against libc malloc by default, with the exception of jemalloc being the default on Linux systems. This default was picked because jemalloc has proven to have fewer fragmentation problems than libc malloc. To force compiling against libc malloc, use: % make MALLOC=libc To compile against jemalloc on Mac OS X systems, use: % make MALLOC=jemalloc Verbose build ------------- Redis will build with a user friendly colorized output by default. If you want to see a more verbose output use the following: % make V=1 Running Redis ------------- To run Redis with the default configuration just type: % cd src % ./redis-server If you want to provide your redis.conf, you have to run it using an additional parameter (the path of the configuration file): % cd src % ./redis-server /path/to/redis.conf It is possible to alter the Redis configuration passing parameters directly as options using the command line. Examples: % ./redis-server --port 9999 --slaveof 127.0.0.1 6379 % ./redis-server /etc/redis/6379.conf --loglevel debug All the options in redis.conf are also supported as options using the command line, with exactly the same name. Playing with Redis ------------------ You can use redis-cli to play with Redis. Start a redis-server instance, then in another terminal try the following: % cd src % ./redis-cli redis> ping PONG redis> set foo bar OK redis> get foo "bar" redis> incr mycounter (integer) 1 redis> incr mycounter (integer) 2 redis> You can find the list of all the available commands here: http://redis.io/commands Installing Redis ----------------- In order to install Redis binaries into /usr/local/bin just use: % make install You can use "make PREFIX=/some/other/directory install" if you wish to use a different destination. Make install will just install binaries in your system, but will not configure init scripts and configuration files in the appropriate place. This is not needed if you want just to play a bit with Redis, but if you are installing it the proper way for a production system, we have a script doing this for Ubuntu and Debian systems: % cd utils % ./install_server The script will ask you a few questions and will setup everything you need to run Redis properly as a background daemon that will start again on system reboots. You'll be able to stop and start Redis using the script named /etc/init.d/redis_<portnumber>, for instance /etc/init.d/redis_6379. Enjoy!