What should I do if redis is down?

We all know that all Redis data is in memory. If there is a sudden downtime, all data will be lost. So how should we solve it?

#There must be a mechanism to ensure that Redis data will not be lost due to failures. This mechanism is the persistence mechanism of Redis. (Recommended learning: Redis video tutorial)

Redis has two persistence mechanisms, the first is snapshot, and the second is AOF log. A snapshot is a full backup, and an AOF log is a continuous incremental backup. Snapshots are binary serialized forms of memory data and are very compact in storage, while AOF logs record the instruction record text of memory data modifications. AOF logs will become extremely large during long-term operation. When the database is restarted, the AOF logs need to be loaded for command replay, which will take an extremely long time. Therefore, AOF logs need to be rewritten regularly to slim down the AOF logs.

Snapshot Principle

We know that Redis is a single-threaded program. This thread is responsible for concurrent read and write operations of multiple client sockets and memory data structures at the same time. Logical reading and writing.

While making requests on the service line, Redis also needs to perform memory snapshots. Memory snapshots require Redis to perform file IO operations, but file IO operations cannot use the multiplexing API.
This means that while a single thread is requesting on the service line, it must also perform file IO operations, and file IO operations will seriously drag down the performance of server requests.

There is another important issue. In order not to block online business, Redis needs to persist while responding to client requests. While persisting, the memory data structure is still changing. For example, a large hash dictionary is being persisted, but a request comes and deletes it, but it has not been persisted yet. What should I do?

Redis uses the multi-process COW (Copy On Write) mechanism of the operating system to achieve snapshot persistence. This mechanism is very interesting and few people know it.

AOF principle

The AOF log stores the sequential command sequence of the Redis server. The AOF log only records the command records that modify the memory.

Assuming that the AOF log records all modified instruction sequences since the creation of the Redis instance, then Redis can be restored by sequentially executing all instructions on an empty Redis instance - that is, "replaying" The state of the current instance's in-memory data structures.

Redis will perform parameter verification and logic processing after receiving the client modification instruction. If there is no problem, the instruction text will be immediately stored in the AOF log. In other words, the instruction will be executed first before Log save. This is different from storage engines such as leveldb and hbase, which store logs first and then perform logical processing.

During the long-term operation of Redis, the AOF log will become longer and longer. If the instance crashes and is restarted, replaying the entire AOF log will be very time-consuming, resulting in Redis being unable to provide external services for a long time. Therefore, the AOF log needs to be slimmed down.

For more Redis-related technical articles, please visit the Introduction to Using Redis Database Tutorial column to learn!

The above is the detailed content of What should I do if redis is down?. For more information, please follow other related articles on the PHP Chinese website!