PLEASE DO NOT POST GENERAL QUESTIONS that are not about bugs or suspected
PLEASE DO NOT POST GENERAL QUESTIONS that are not about bugs or suspected
bugs in the Github issues system. We'll be very happy to help you and provide
bugs in the Github issues system. We'll be very happy to help you and provide
all the support at the Reddit sub:
all the support in the mailing list.
http://reddit.com/r/redis
There is also an active community of Redis users at Stack Overflow:
There is also an active community of Redis users at Stack Overflow:
...
@@ -22,7 +22,12 @@ each source file that you contribute.
...
@@ -22,7 +22,12 @@ each source file that you contribute.
# How to provide a patch for a new feature
# How to provide a patch for a new feature
1. If it is a major feature or a semantical change, please post it as a new submission in r/redis on Reddit at http://reddit.com/r/redis. Try to be passionate about why the feature is needed, make users upvote your proposal to gain traction and so forth. Read feedbacks about the community. But in this first step **please don't write code yet**.
1. If it is a major feature or a semantical change, please don't start coding
straight away: if your feature is not a conceptual fit you'll lose a lot of
time writing the code without any reason. Start by posting in the mailing list
and creating an issue at Github with the description of, exactly, what you want
to accomplish and why. Use cases are important for features to be accepted.
Here you'll see if there is consensus about your idea.
2. If in step 1 you get an acknowledgment from the project leaders, use the
2. If in step 1 you get an acknowledgment from the project leaders, use the
following procedure to submit a patch:
following procedure to submit a patch:
...
@@ -30,9 +35,16 @@ each source file that you contribute.
...
@@ -30,9 +35,16 @@ each source file that you contribute.
a. Fork Redis on github ( http://help.github.com/fork-a-repo/ )
a. Fork Redis on github ( http://help.github.com/fork-a-repo/ )
b. Create a topic branch (git checkout -b my_branch)
b. Create a topic branch (git checkout -b my_branch)
c. Push to your branch (git push origin my_branch)
c. Push to your branch (git push origin my_branch)
d. Initiate a pull request on github ( http://help.github.com/send-pull-requests/ )
d. Initiate a pull request on github ( https://help.github.com/articles/creating-a-pull-request/ )
e. Done :)
e. Done :)
For minor fixes just open a pull request on Github.
3. Keep in mind that we are very overloaded, so issues and PRs sometimes wait
for a *very* long time. However this is not lack of interest, as the project
gets more and more users, we find ourselves in a constant need to prioritize
certain issues/PRs over others. If you think your issue/PR is very important
try to popularize it, have other users commenting and sharing their point of
view and so forth. This helps.
4. For minor fixes just open a pull request on Github.
All the options in redis.conf are also supported as options using the command
All the options in redis.conf are also supported as options using the command
...
@@ -166,6 +166,8 @@ for Ubuntu and Debian systems:
...
@@ -166,6 +166,8 @@ for Ubuntu and Debian systems:
% cd utils
% cd utils
% ./install_server.sh
% ./install_server.sh
_Note_: `install_server.sh` will not work on Mac OSX; it is built for Linux only.
The script will ask you a few questions and will setup everything you need
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
to run Redis properly as a background daemon that will start again on
system reboots.
system reboots.
...
@@ -216,7 +218,7 @@ Inside the root are the following important directories:
...
@@ -216,7 +218,7 @@ Inside the root are the following important directories:
*`src`: contains the Redis implementation, written in C.
*`src`: contains the Redis implementation, written in C.
*`tests`: contains the unit tests, implemented in Tcl.
*`tests`: contains the unit tests, implemented in Tcl.
*`deps`: contains libraries Redis uses. Everything needed to compile Redis is inside this directory; your system just needs to provide `libc`, a POSIX compatible interface and a C compiler. Notably `deps` contains a copy of `jemalloc`, which is the default allocator of Redis under Linux. Note that under `deps` there are also things which started with the Redis project, but for which the main repository is not `anitrez/redis`. An exception to this rule is `deps/geohash-int` which is the low level geocoding library used by Redis: it originated from a different project, but at this point it diverged so much that it is developed as a separated entity directly inside the Redis repository.
*`deps`: contains libraries Redis uses. Everything needed to compile Redis is inside this directory; your system just needs to provide `libc`, a POSIX compatible interface and a C compiler. Notably `deps` contains a copy of `jemalloc`, which is the default allocator of Redis under Linux. Note that under `deps` there are also things which started with the Redis project, but for which the main repository is not `antirez/redis`.
There are a few more directories but they are not very important for our goals
There are a few more directories but they are not very important for our goals
here. We'll focus mostly on `src`, where the Redis implementation is contained,
here. We'll focus mostly on `src`, where the Redis implementation is contained,
...
@@ -227,7 +229,7 @@ of complexity incrementally.
...
@@ -227,7 +229,7 @@ of complexity incrementally.
Note: lately Redis was refactored quite a bit. Function names and file
Note: lately Redis was refactored quite a bit. Function names and file
names have been changed, so you may find that this documentation reflects the
names have been changed, so you may find that this documentation reflects the
`unstable` branch more closely. For instance in Redis 3.0 the `server.c`
`unstable` branch more closely. For instance in Redis 3.0 the `server.c`
and `server.h` files were named to `redis.c` and `redis.h`. However the overall
and `server.h` files were named `redis.c` and `redis.h`. However the overall
structure is the same. Keep in mind that all the new developments and pull
structure is the same. Keep in mind that all the new developments and pull
requests should be performed against the `unstable` branch.
requests should be performed against the `unstable` branch.
...
@@ -245,7 +247,7 @@ A few important fields in this structure are:
...
@@ -245,7 +247,7 @@ A few important fields in this structure are:
*`server.db` is an array of Redis databases, where data is stored.
*`server.db` is an array of Redis databases, where data is stored.
*`server.commands` is the command table.
*`server.commands` is the command table.
*`server.clients` is a linked list of clients connected to the server.
*`server.clients` is a linked list of clients connected to the server.
*`server.master` is a special client, the master, if the instance is a slave.
*`server.master` is a special client, the master, if the instance is a replica.
There are tons of other fields. Most fields are commented directly inside
There are tons of other fields. Most fields are commented directly inside
the structure definition.
the structure definition.
...
@@ -323,7 +325,7 @@ Inside server.c you can find code that handles other vital things of the Redis s
...
@@ -323,7 +325,7 @@ Inside server.c you can find code that handles other vital things of the Redis s
networking.c
networking.c
---
---
This file defines all the I/O functions with clients, masters and slaves
This file defines all the I/O functions with clients, masters and replicas
(which in Redis are just special clients):
(which in Redis are just special clients):
*`createClient()` allocates and initializes a new client.
*`createClient()` allocates and initializes a new client.
...
@@ -390,21 +392,21 @@ replication.c
...
@@ -390,21 +392,21 @@ replication.c
This is one of the most complex files inside Redis, it is recommended to
This is one of the most complex files inside Redis, it is recommended to
approach it only after getting a bit familiar with the rest of the code base.
approach it only after getting a bit familiar with the rest of the code base.
In this file there is the implementation of both the master and slave role
In this file there is the implementation of both the master and replica role
of Redis.
of Redis.
One of the most important functions inside this file is `replicationFeedSlaves()` that writes commands to the clients representing slave instances connected
One of the most important functions inside this file is `replicationFeedSlaves()` that writes commands to the clients representing replica instances connected
to our master, so that the slaves can get the writes performed by the clients:
to our master, so that the replicas can get the writes performed by the clients:
this way their data set will remain synchronized with the one in the master.
this way their data set will remain synchronized with the one in the master.
This file also implements both the `SYNC` and `PSYNC` commands that are
This file also implements both the `SYNC` and `PSYNC` commands that are
used in order to perform the first synchronization between masters and
used in order to perform the first synchronization between masters and
slaves, or to continue the replication after a disconnection.
replicas, or to continue the replication after a disconnection.
Other C files
Other C files
---
---
*`t_hash.c`, `t_list.c`, `t_set.c`, `t_string.c` and `t_zset.c` contains the implementation of the Redis data types. They implement both an API to access a given data type, and the client commands implementations for these data types.
*`t_hash.c`, `t_list.c`, `t_set.c`, `t_string.c`, `t_zset.c` and `t_stream.c` contains the implementation of the Redis data types. They implement both an API to access a given data type, and the client commands implementations for these data types.
*`ae.c` implements the Redis event loop, it's a self contained library which is simple to read and understand.
*`ae.c` implements the Redis event loop, it's a self contained library which is simple to read and understand.
*`sds.c` is the Redis string library, check http://github.com/antirez/sds for more information.
*`sds.c` is the Redis string library, check http://github.com/antirez/sds for more information.
*`anet.c` is a library to use POSIX networking in a simpler way compared to the raw interface exposed by the kernel.
*`anet.c` is a library to use POSIX networking in a simpler way compared to the raw interface exposed by the kernel.
@@ -2,7 +2,6 @@ This directory contains all Redis dependencies, except for the libc that
...
@@ -2,7 +2,6 @@ This directory contains all Redis dependencies, except for the libc that
should be provided by the operating system.
should be provided by the operating system.
***Jemalloc** is our memory allocator, used as replacement for libc malloc on Linux by default. It has good performances and excellent fragmentation behavior. This component is upgraded from time to time.
***Jemalloc** is our memory allocator, used as replacement for libc malloc on Linux by default. It has good performances and excellent fragmentation behavior. This component is upgraded from time to time.
***geohash-int** is inside the dependencies directory but is actually part of the Redis project, since it is our private fork (heavily modified) of a library initially developed for Ardb, which is in turn a fork of Redis.
***hiredis** is the official C client library for Redis. It is used by redis-cli, redis-benchmark and Redis Sentinel. It is part of the Redis official ecosystem but is developed externally from the Redis repository, so we just upgrade it as needed.
***hiredis** is the official C client library for Redis. It is used by redis-cli, redis-benchmark and Redis Sentinel. It is part of the Redis official ecosystem but is developed externally from the Redis repository, so we just upgrade it as needed.
***linenoise** is a readline replacement. It is developed by the same authors of Redis but is managed as a separated project and updated as needed.
***linenoise** is a readline replacement. It is developed by the same authors of Redis but is managed as a separated project and updated as needed.
***lua** is Lua 5.1 with minor changes for security and additional libraries.
***lua** is Lua 5.1 with minor changes for security and additional libraries.
...
@@ -22,7 +21,7 @@ just following tose steps:
...
@@ -22,7 +21,7 @@ just following tose steps:
1. Remove the jemalloc directory.
1. Remove the jemalloc directory.
2. Substitute it with the new jemalloc source tree.
2. Substitute it with the new jemalloc source tree.
3. Edit the Makefile localted in the same directoy as the README you are
3. Edit the Makefile localted in the same directory as the README you are
reading, and change the --with-version in the Jemalloc configure script
reading, and change the --with-version in the Jemalloc configure script
options with the version you are using. This is required because otherwise
options with the version you are using. This is required because otherwise
Jemalloc configuration script is broken and will not work nested in another
Jemalloc configuration script is broken and will not work nested in another
...
@@ -42,15 +41,10 @@ the following additional steps:
...
@@ -42,15 +41,10 @@ the following additional steps:
changed, otherwise you could just copy the old implementation if you are
changed, otherwise you could just copy the old implementation if you are
upgrading just to a similar version of Jemalloc.
upgrading just to a similar version of Jemalloc.
Geohash
---
This is never upgraded since it's part of the Redis project. If there are changes to merge from Ardb there is the need to manually check differences, but at this point the source code is pretty different.
Hiredis
Hiredis
---
---
Hiredis uses the SDS string library, that must be the same version used inside Redis itself. Hiredis is also very critical for Sentinel. Historically Redis often used forked versions of hiredis in a way or the other. In order to upgrade it is adviced to take a lot of care:
Hiredis uses the SDS string library, that must be the same version used inside Redis itself. Hiredis is also very critical for Sentinel. Historically Redis often used forked versions of hiredis in a way or the other. In order to upgrade it is advised to take a lot of care:
1. Check with diff if hiredis API changed and what impact it could have in Redis.
1. Check with diff if hiredis API changed and what impact it could have in Redis.
2. Make sure thet the SDS library inside Hiredis and inside Redis are compatible.
2. Make sure thet the SDS library inside Hiredis and inside Redis are compatible.
...
@@ -83,6 +77,6 @@ and our version:
...
@@ -83,6 +77,6 @@ and our version:
1. Makefile is modified to allow a different compiler than GCC.
1. Makefile is modified to allow a different compiler than GCC.
2. We have the implementation source code, and directly link to the following external libraries: `lua_cjson.o`, `lua_struct.o`, `lua_cmsgpack.o` and `lua_bit.o`.
2. We have the implementation source code, and directly link to the following external libraries: `lua_cjson.o`, `lua_struct.o`, `lua_cmsgpack.o` and `lua_bit.o`.
3. There is a security fix in `ldo.c`, line 498: The check for `LUA_SIGNATURE[0]` is removed in order toa void direct bytecode exectuion.
3. There is a security fix in `ldo.c`, line 498: The check for `LUA_SIGNATURE[0]` is removed in order toa void direct bytecode execution.