Help Center/ MapReduce Service/ User Guide (Ankara Region)/ Overview/ Components/ Redis/ Redis Basic Principles
Updated on 2024-11-29 GMT+08:00
View PDF
Share

Redis Basic Principles

Introduction to Redis

Redis is an open-source, network-based, and high-performance key-value database. It makes up for the shortage of memcached key-value storage. In some scenarios, Redis can be used as a supplement to relational databases to meet real-time and high-concurrency requirements.

Redis is similar to Memcached. Besides, it supports data persistence and diverse data types. Redis also supports the calculation of the union, intersection, and complement of sets on the server as well as multiple sorting functions.

The network data transmission between the Redis client and server is not encrypted, which brings security risks. Therefore, It is advised not to use Redis to store sensitive data.

Architecture

Redis consists of Redis Server and Redis-WS, as shown in Figure 1.

Figure 1 Redis logical architecture
  • Redis Server: core module of the Redis. It is responsible for data read and write of the Redis protocol, active/standby replication, and maintain the data persistence and cluster functions.
  • Redis-WS: Redis WebService management module. It implements operations such as cluster creation/deletion, scaling-out/scaling-in, and cluster querying, and stores cluster management information in the DB.

Principle

Redis Persistence

Redis supports the following types of persistence:

  • Redis Database File (RDB) persistence

    Point-in-time snapshots are generated for data sets in specified intervals.

  • Append Only File (AOF) persistence

    All write operation commands executed by a server are recorded. When the server starts, the recorded commands will be executed to restore data sets. All commands in the AOF file are saved in the Redis protocol format. New commands are added to the end of the file. Redis allows the AOF file to be rewritten in the background, preventing the file size from exceeding the actual size required for storing data set status.

Redis supports AOF and RDB persistence at the same time. When Redis restarts, it preferentially uses AOF to restore data sets because the AOF contains more complete data sets than the RDB. The data persistence function can also be disabled. When it is disabled, data exists only when the server is running.

Redis Running Mode

Redis instances can be deployed on one or more nodes, and one or more Redis instances can be deployed on one node. (On the MRS platform, the number of Redis instances on each node is calculated by software based on the node hardware resources.)

The latest Redis supports clusters. That is, multiple Redis instances constitute a Redis cluster to provide a distributed key-value database. Clusters share data through sharding and provide replication and failover functions.

  • Single instance mode

    Figure 2 shows the logical deployment of the single-instance mode.

    Figure 2 Single instance mode

    Note:

    • A master instance has multiple slave instances. A slave instance can have slave instances as well.
    • Command requests sent to the master instance are synchronized to the slave instance in real time.
    • If the master instance is faulty, the slave instance will not be automatically promoted to the master one.
    • By default, the slave instance is read-only. If slave-read-only is set to no, the slave instance can be written. But if the slave instance is restarted, it will synchronize the data from the master instance, and the data written to the slave instance earlier will be lost.
    • The layered structure of slave instances reduces the number of instances directly connected to the master instance. This structure improves service processing performance of the master instance because the number of slave instances that need to synchronize data from the master instance is reduced.
  • Cluster mode

    Figure 3 shows the logical deployment mode of the cluster mode.

    Figure 3 Cluster mode

    Note:

    • Multiple Redis instances constitute a Redis cluster, in which 16,384 slots are evenly distributed to master instances.
    • Every instance in the cluster record the mapping between slots and instances, so do the clients. The client performs hash calculation based on the key and performs modulo operation with 16384 to obtain the slot ID. The message is directly sent to the corresponding instance for processing based on the slot-instance mapping.
    • By default, slave instances cannot read or write data. Running the readonly command can enable a slave instance to read data only.
    • If a master instance is faulty, the remaining master instances in the cluster will select a slave one to serve as a new master instance. The selection can be performed only when more than half of the master instances in the cluster are normal.
    • If cluster-require-full-coverage is set to yes, the cluster status is FAIL when a group of master and slave instances is faulty. If this occurs, the cluster cannot process commands. If cluster-require-full-coverage is set to no, the cluster status is normal as long as more than half of the master instances are normal.
    • You can scale out or scale in a Redis cluster (by adding a new instance to the cluster or removing an existing Redis instance from the cluster) and migrate slots.
    • At present, each Redis cluster in MRS supports only one-to-one mapping between active and slave instances.
Parent topic: Redis