[Redis-interview questions and persistence schemes] Redis-related interview questions (cache penetration, cache breakdown, cache avalanche) & detailed comparison of two Redis persistence schemes (RDB, AOF)

1) Redis interview questions

1.1. High-frequency interview questions: cache penetration, cache breakdown, cache avalanche

1.2. Low-frequency interview questions: interview questions about redis clusters

Since Redis 3.0 was released to provide Redis Cluster, after a series of versions of Redis 4.x, Redis5.x and Redis 6.x, Redis Cluster has become more mature and stable. It is recommended that enterprises use this architecture, and usually companies also use this architecture. If you use the Redis Cluster cluster, there are some pitfalls in the questions encountered in the interview, so please pay attention.

• Question 1: How much do you know about the multi-database mechanism of Redis?

  

• Question 2: Do you understand the batch operation of Redis?

  

• Question 3: Do you think there are any deficiencies in the Redis cluster mechanism?

  

• Question 4: How to perform batch operations in Redis cluster mode?

  

• Question 5: Do you understand Redis transactions?

  

2) Persistence of Redis

2.1. RDB persistence scheme

2.1.1. Introduction

Redis will periodically save data snapshots to an rbd file, and automatically load the rdb file at startup to restore the previously saved data. You can configure the timing of Redis snapshot saving in the configuration file:

save [seconds] [changes]

It means that if there are changes times of data modification within seconds seconds, an RDB snapshot will be saved.For example：

save 60 100

It will make Redis check the data changes every 60 seconds. If there are 100 or more data changes, RDB snapshots will be saved. Multiple save commands can be configured to allow Redis to implement a multi-level snapshot saving strategy. Redis enables RDB snapshots by default. RDB snapshot saving can also be manually triggered by the SAVE or BGSAVE command. Both the SAVE and BGSAVE commands call the rdbSave function, but they do so in different ways:

• SAVE calls rdbSave directly, blocking the Redis main process until the save is complete. While the main process is blocked, the server cannot process any requests from clients.

• BGSAVE forks a child process, and the child process is responsible for calling rdbSave, and sends a signal to the main process after the save is completed, notifying that the save has been completed. The Redis server can still continue to process client requests during BGSAVE execution.

2.1.2. Advantages of RDB scheme

1. Minimal impact on performance. As mentioned above, when Redis saves RDB snapshots, it will fork out of child processes, which hardly affects the efficiency of Redis in processing client requests.

2. Each snapshot will generate a complete data snapshot file, so it can be supplemented by other means to save snapshots at multiple time points (for example, backup the snapshot at 0:00 every day to other storage media), as a very reliable means of disaster recovery .

3. Using RDB files for data recovery is much faster than using AOF.

2.1.3. Disadvantages of RDB scheme

1. Snapshots are generated periodically, so some data will be lost more or less when Redis crashes.

2. If the data set is very large and the CPU is not strong enough (such as a single-core CPU), Redis may consume a relatively long time when forking the child process, which will affect Redis' ability to provide external services.

2.1.4. RDB configuration

(1) Modify the configuration file of redis

cd /export/server/redis-3.2.8/conf
vim redis.conf
# 第202行
save 900 1
save 300 10
save 60 10000
save 5 1

These three options are the default storage mechanism of the redis configuration file. Indicates how many seconds and how many keys change to generate a dump.rdb file as a snapshot file of redis.

For example：

save 60 10000 means that within 60 seconds, if 10,000 keys change, a redis snapshot will be generated.

(2) Restart the redis service

Every time a new dump.rdb is generated, the old snapshot will be overwritten

ps -ef | grep redis
bin/redis-cli -h node1.itcast.cn shutdown
bin/redis-server redis.conf

2.2. AOF persistence scheme

1.1.1. Introduction

When using the AOF persistence method, Redis will record each write request in a log file. When Redis restarts, all write operations recorded in the AOF file will be executed sequentially to ensure that the data is restored to the latest.

1.1.2. Enable AOF

AOF is disabled by default. If you want to enable it, configure it as follows:

# 第594行
appendonly yes

1.1.3. Configure AOF

AOF provides three fsync configurations:

always/everysec/no(Specified by the configuration item [appendfsync])

• appendfsync no: Do not perform fsync, leave the timing of the flush file to the OS decision, the fastest

• appendfsync always: An fsync operation is performed every time a log is written, the data security is the highest, but the speed is the slowest

• appendfsync everysec: A compromise, let the background thread fsync once per second

1.1.4.AOF rewrite

As AOF continuously logs write operations, since all write operations are logged, there are bound to be some useless logs. A large number of useless logs will make the AOF file too large and the data recovery time will be too long. However, Redis provides the AOF rewrite function, which can rewrite the AOF file and only retain the minimum set of write operations that can restore the data to the latest state.

AOF rewrite can be triggered by the BGREWRITEAOF command, or you can configure Redis to perform it automatically on a regular basis:

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• Redis will record the AOF log size after rewrite every time AOF rewrite is completed. When the AOF log size increases by 100% on this basis, AOF rewrite will be performed automatically

• auto-aof-rewrite-min-size The initial AOF file must trigger this file to be triggered, and each subsequent rewrite will not be based on this variable. This variable is valid only for initializing and starting Redis

1.1.5. Advantages of AOF

1. It is safest. When appendfsync is enabled as always, any written data will not be lost. When appendfsync everysec is enabled, data will only be lost for at most 1 second.

2. The AOF file will not be damaged in the event of power failure and other problems. Even if a log is only half written, it can be easily repaired with the redis-check-aof tool.

3. The AOF file is easy to read and can be modified. After some erroneous data clearing operations, as long as the AOF file has no rewrite, you can back up the AOF file, delete the erroneous command, and then restore the data.

1.1.6. Disadvantages of AOF

1. AOF files are usually larger than RDB files.

2. The performance consumption is higher than that of RDB.

3. Data recovery speed is slower than RDB.

The data persistence work of Redis itself will bring delay, and it is necessary to formulate a reasonable persistence strategy according to the security level and performance requirements of the data:

• Although the setting of AOF + fsync always can absolutely ensure data security, each operation will trigger fsync once, which will have a more obvious impact on the performance of Redis

• AOF + fsync every second is a better compromise, fsync once per second

• AOF + fsync never will provide the best performance under the AOF persistence scheme

Using RDB for persistence usually provides higher performance than using AOF, but you need to pay attention to the RDB policy configuration.

2.3.RDB or AOF

Every RDB snapshot and AOF Rewrite requires the Redis master process to perform a fork operation. The fork operation itself may have a high time consumption, which is related to the CPU and the memory size occupied by Redis. Reasonably configure the RDB snapshot and AOF Rewrite timing according to the specific situation to avoid the delay caused by too frequent fork.