Redis is a very popular in-memory database when it comes to caching. This post covers the basic configurations for setting up a Redis instance in docker.
Create a directory named
redisdb and ensure the following file structure.
data directory will contain the snapshots taken over time (as
redis.conf file will contain the instance configurations.
The below configurations are what seems important in general. Rest can be left to defaults.
bind 0.0.0.0 # bind to all available interfaces
protectedmode no # since we're not serving over localhost
port 6379 # default porttcp-backlog 511 # high backlog value helps avoid slow client
connection issues, helpful in
high-request-per-second environmentstimeout 0 # disable idle connection timeout
Since we’re going to run it inside a container, no background process of service is required.
databases # valid between 1-16. Indexed with 0
These settings will generate snapshots of the data from memory and save them with
.rdb file extension under the
data/ directory that we created above based on the specified policies.
save 900 1 # save <seconds> <writes>
save 300 10
save 60 10000stop-writes-on-bgsave-error yes # stop accepting writes if
snapshotting fails. This limits
the risk of losing data.
The basic security involves setting a server password.
requirepass PASSWORD # set the server password
However, if the data is sensitive, it is risky to just authenticate using a server password. Because a single
FLUSHALL command can delete everything. It can be mitigated with an Access Control List (ACL) which is a list containing username/passwords with the allowed list of commands.
Memory Management (IMPORTANT)
Since Redis is an in-memory database, you don’t want it to flood the node it is running on thereby compromising all other services. A suitable memory management policy saves the day.
noeviction: return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used.
allkeys-lru: evict keys by trying to remove the less recently used (LRU) keys first, in order to make space for the new data added.
volatile-lru: evict keys by trying to remove the less recently used (LRU) keys first, but only among keys that have an expiry set, in order to make space for the new data added.
allkeys-random: evict keys randomly in order to make space for the new data added.
volatile-random: evict keys randomly in order to make space for the new data added, but only evict keys with an expire set.
volatile-ttl: evict keys with an expire set, and try to evict keys with a shorter time to live (TTL) first.
The list of available eviction policies can be found here.
Append Only File (
aof) is an alternative persistence mode that provides much better durability compared to
rdb since it creates something similar to a point in time snapshot.
Some problems associated with
aof files are,
- The AOF file size is proportional to the number of writes. It will get bigger and bigger.
- The bigger the AOF file is, the longer the server will take to restart.
- So we need a way to compact the AOF from time to time. Again in a non-blocking way, while the server is running receiving read and write queries.
Hence, consider this option only when you have very sensitive data and can not afford to lose.
Here is the link to a detailed comparison between
Start the instance
Run the following command under the
redisdb/ directory since the local path must be absolute in the