Redis is a NoSQL in-memory key-value repository. It allows you to create atomic operations over built-in data types. It isn’t a cache tool, but a complex repository which can be used simultaneously as a queue, stack or message broker. Regarding the fact, that Redis is available as the Azure service, it can be used as a distributed cache with low latency, high permeability and availability.
Redis has popularized the idea that the system can be considered both as a both storage and cache, using design where the data is constantly edited and read from the computer’s main memory, but also stored on a disk in a format that is not suitable for random access to data, but only for reconstructing data from the memory after the system restart.
At the same time, Redis provides a data model that is very atypical, compared to other RDBM systems, where user commands don’t describe a query to the database, but they describe specific operations that are triggered on specified abstract data types. Data must therefore be stored in a manner that is suitable for quick subsequent call up without the assistance of the database system in a form of secondary indexes, aggregates or other normal RDBM functions.
Redis implementation frequently uses Fork to duplicate data retention processes, so the parent process continues to serve clients, while the subsidiary process creates a copy of data to disk.
Redis usually keeps the entire data set in its memory. Some versions can be configured to what Redis refers to as a virtual memory. In that case, the data set is stored on disk. The persistence is thus achieved in two ways. One way is a so-called snaphotting and has a semi-persistent durability mode, where the data set is asynchronously transmitted from memory to disk in RDB format. Since version 1.1, a safer AOF variant is implemented. This method works as an operation modifying the data set in memory. Redis can rewrite AOF files in the background to avoid the continuous growth of the captured capacity.
In default, Redit writes data into the filesystem at least every two seconds, with more or less robust options that can be set as needed. In a case of complete system failure, with default settings applied, only data from last few seconds are lost.