Redis is an open-source, advanced key-value data store. It is also referred as a data structure server which keys not only contains strings, but also hashes, sets, lists, and sorted sets. Redis mostly used for cache solutions and session management. In this article, I record down some of the important points about Redis for the further review.

Basic Features

Following are the main features of Redis:

• What is Redis: “Redis” stands for “REmote DIctionary Server”, and it is written in ANSI C. It is extremely fast, persistent, portable and supports many languages such as C++, Java, PHP, etc.
• The data structures: The data structures it supports include string, list, hash, set and sorted set.
• Redis is very fast: It is an in-memory key-value data store that can execute 10,0000 queries per second. Redis is very fast because it loads the whole dataset in primary memory.
• Replication feature: Redis supports simple master to slave replication. When a relationship is established, data from the master is transferred to the slave.
• The main limitation for Redis: is the size of the physical memory. therefore, it can’t be used for data storing and searching at a very large scale.

Redis vs. Memcached

Below are the main differences between Redis and Memcached:

The Eviction Strategy

What happens if Redis runs out of memory?

You can use the “maxmemory” option in the config file to put a limit to the memory Redis can use. If this limit is reached Redis will start to reply with an error to write commands (but will continue to accept read-only commands), or you can configure it to evict keys when the max memory limit is reached.

The following lists the details of Redis’ eviction policies:

• allkeys-lru: the service evicts the least recently used keys out of all keys.
• allkeys-random: the service randomly evicts keys out of all keys.
• volatile-lru: the service evicts the least recently used keys out of all keys with an “expire” field set.
• volatile-random: the service randomly evicts keys with an “expire” field set.
• volatile-ttl: the service evicts the shortest time to live keys (out of all keys with an “expire” field set).
• no-eviction: the service will not evict any keys and no writes will be possible until more memory is freed.

Redis Persistence

Redis provides a different range of persistence options:

• The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
• The AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset.

Snapshotting: By default Redis saves snapshots of the dataset on disk, in a binary file called dump.rdb. You can configure Redis to have it save the dataset every N seconds if there are at least M changes in the dataset, or you can manually call the SAVE or BGSAVE commands. It works like this:

• Redis forks a child process.
• The child starts to write the dataset to a temporary RDB file.
• When the child is done writing the new RDB file, it replaces the old one.

Append-only file: Snapshotting is not very durable. If your computer running Redis stops, your power line fails, or you accidentally kill -9 your instance, the latest data written on Redis will get lost. The append-only file is an alternative, fully-durable strategy for Redis.

Once you turn on the AOF, every time Redis receives a command that changes the dataset (e.g. SET) it will append it to the AOF. When you restart Redis it will re-play the AOF to rebuild the state.

Single Threaded

Redis is single threaded, it serializes the concurrent requests to a queue by NIO (epoll) techniques. Thus it avoids the switches between multiple threads, as a result, it gains a better performance.

Redis Replication

Once we configured “slave of master”, the slave will automatically reconnect to the master every time the link breaks, and will attempt to be an exact copy of it regardless of what happens to the master.

This system works using three main mechanisms:

1. When a master and a slave instances are well-connected, the master keeps the slave updated by sending a stream of commands to the slave, in order to replicate the effects on the dataset happening in the master side due to: client writes, keys expired or evicted, any other action changing the master dataset.
2. When the link between the master and the slave breaks, for network issues or because a timeout is sensed in the master or the slave, the slave reconnects and attempts to proceed with a partial resynchronization: it means that it will try to just obtain the part of the stream of commands it missed during the disconnection.
3. When a partial resynchronization is not possible, the slave will ask for a full resynchronization. This will involve a more complex process in which the master needs to create a snapshot of all its data, send it to the slave, and then continue sending the stream of commands as the dataset changes.

Sentinel: Redis Sentinel can be used to manage replicated servers. Clients connect to a Sentinel and request a master or slave to communicate with, the sentinels handle health checks of the masters/slaves, and will automatically promote a slave if a master is unreachable. You need to have at least 3 sentinels running so that they can agree on reachability of nodes, and to ensure the sentinels aren’t a single point of failure.

References

[1] Top 10 Redis interview questions: https://career.guru99.com/top-10-redis-interview-questions

[2] Redis持久化详解: https://segmentfault.com/a/1190000012908434

[3] Redis Persistence: https://redis.io/topics/persistence

[4] 关于redis的主从、哨兵、集群: https://blog.csdn.net/c295477887/article/details/52487621

[5] Redis Replication: https://redis.io/topics/replication