Caching:

Caching is the process of storing some data in Cache. Cache is a temporary storage component area where the data is stored so that in future, Data can be served faster instead of hitting database servers all the time.

We have different cache tools which include Redis, Memcache, Ncache etc.,

Redis Cache

Redis stands for Remote Dictionary Server, it is an open source (BSD Licensed) in-memory key value data store. It can be used as a Database, Cache or as a message broker. It is written in C language and it supports various data structures such as Strings, Hashes, Lists, sets etc.

What Is In-Memory, Key-Value Store:

Key-Value store is a storage system where data is stored in form of key and value pairs. When we say in-memory key-value store, by that we mean that the key-value pairs are stored in primary memory (RAM). In Redis, key has to be a string but value can be a string, list, set, sorted set or hash.

Redis Architecture:

Redis architecture contains two main processes: Redis client and Redis Server. Redis client and server can be in the same computer or in two different computers.

Redis server is responsible for storing data in memory. It handles all kinds of management and forms the major part of architecture. Redis client can be Redis console client or any other programming language’s Redis API.As we saw that Redis stores everything in primary memory. Primary memory is volatile and therefore we will lose all stored data once we restart our Redis server or computer. So, we need a way for data store persistence.

Redis has two persistence options that may be used together, individually or not at all: snapshot backups and change logs. 

Snapshot (with RDB file) 

Redis database backups (RDB files) are hot snapshots that are taken periodically and are meant for point-in-time recovery. An RDB file is literally a dump of all user data stored in an internal, compressed serialization format. Redis can be configured to take automatic snapshots based on time transpired or the number of changes, as well as generate them on demand. While a backup is generated, it consists of all data since the process was started and includes the changes to the dataset until it has finished  

Change Logs (with AOF) 

Redis can also persist the dataset by taking a snapshot and appending it with changes as they arrive. This mode of data persistence, known as Append Only File (AOF), provides the ability to recover a data set up to and including the last known state. Redis can be configured to flush changes to the AOF file every second or with every change. Recovering from an AOF file requires loading its snapshot preamble, and then executing every logged change. As a result, as an AOF grows in size due to changes, so does the time it takes to use it for recovering the dataset. Redis can be set up to rewrite the AOF file based on configurable thresholds or perform this operation on demand.

Replication in Redis 

A single server is a single point of failure in every system, and in order to ensure the high availability of the service, that server needs to be made redundant. Making a server redundant typically consists of maintaining multiple instances of that server and switching between them as needed. 

A Redis instance is a server process that acts as the in-memory data store. By default, it takes the role of a single primary source of the data, and serves all read and write requests for it. To protect against the primary process’ failure, whether due to software or hardware issues, Redis can replicate the dataset, as well as the stream of changes it undergoes, to one or more secondary instances or replicas. 

Redis uses unidirectional asynchronous replication from the primary instance (also referred to as “master”) to secondary replicas (or “slaves”). A primary instance may have any number of replicas, and any of the replicas may have additional replicas of themselves. To ensure minimal latencies of all operations, replication is non-blocking and is performed after a given operation has been executed by the primary instance. In the event that the primary instance has failed post-execution but pre-replication, data may be lost. In order to ensure data consistency, it is possible for the client to block until any number of replicas have been updated. 

Redis replica can be added and configured at runtime, and the replication protocol supports both a full and partial synchronization for optimizing the network bandwidth consumption. Replicas can be set up to act solely as hot standbys, serve only read requests and even allow write operations (although the latter are not sent back to the master and may be overwritten by the replication stream). 

 

A Redis replica by itself isn’t enough to maintain the availability of the service, as it needs to be promoted to the role of primary instance in the event of failure. For failover and full promotion to happen, the replica must have its role switched, have all other replicas replicate off of it and have all clients reconnect to it for accessing the data.